committer filter by committer.
@path/to/ filter by path in repository.
committer@path/to/ filter by committer AND path in repository.
NNN or rNNN filter by revision.
NNN-MMM or rNNN-rMMM filter by revisions range (inclusive).
Multiple filters can be specified separated by spaces or comas in which case they'll be combined using OR operator.
|r343376||kevans||Jan. 24, 2019, 3:42 a.m.||if_iwm - Check sc->sc_attached flag in suspend/resume callbacks.
* There is (almost) nothing to do in suspend/resume if if_iwm has failed during initialization (e.g. because of firmware load failure) and was already uninitialized by iwm_detach_local(). Submitted by: Augustin Cavalier <firstname.lastname@example.org> (Haiku) Obtained from: DragonFlyBSD (67b5e090efb225654815fed91020db6cfc16bb19)ViewVC
|r343375||kevans||Jan. 24, 2019, 3:42 a.m.||if_iwm - Move iwm_read_firmware() call into iwm_attach().
* We should load the firmware exactly once before the driver really initializes the hardware the first time, and unload it at detach time. There is no need to retrieve the firmware during execution of iwm_mvm_load_ucode_wait_alive(), we should make sure we already have the firmware data at hand before that. * The existing sc_preinit_hook code fails to deal with the case where if_iwm is loaded by the loader (or is statically linked) and the firmware needs to be loaded from disk. So we can just call iwm_read_firmware() from iwm_attach() directly. * A separate solution will have to be added to properly defer the firmware loading during bootup, until the necessary filesystem is mounted. Submitted by: Augustin Cavalier <email@example.com> (Haiku) Obtained from: DragonFlyBSD (0104ee1f4cb6a2313c00c2526c6ae98d42e5041d)ViewVC
|r343374||kevans||Jan. 24, 2019, 3:41 a.m.||if_iwm - The iwm_prepare_card_hw() in iwm_attach() is only needed on 8K hw.
* Doing the iwm_prepare_card_hw() call in iwm_attach() only on Family 8000 hardware matches the code in Linux iwlwifi. * While there remove DEFAULT_MAX_TX_POWER definition which is unused, and has a value different from IWL_DEFAULT_MAX_TX_POWER in iwlwifi. Submitted by: Augustin Cavalier <firstname.lastname@example.org> (Haiku) Obtained from: DragonFlyBSD (e8560f8dc58df12a7c79a6bb4e6ccb156e001085)ViewVC
|r343373||kevans||Jan. 24, 2019, 3:41 a.m.||if_iwm - Update firmware rs table, instead of indexing the table in tx cmds.
* Rather than providing a non-zero index into the firmware RS table, we should always use index 0 and update the firmware RS table whenever our chosen tx rate for data-frames changes. * Send IWM_LQ_CMD updates when the tx rate gets updated by the net80211 rate control (which is after we tell the tx status to the net80211 rate-control in iwm_mvm_rx_tx_cmd_single()). * Disregard frames transferred with a different tx rate than the currently selected rate for the rate-control calculations. This way we avoid counting management frames (which are sent at a slow, and fixed rate), as well as frames we added to the tx queue just before a new IWM_LQ_CMD update took effect. Submitted by: Augustin Cavalier <email@example.com> (Haiku) Obtained from: DragonFlyBSD (5d6b465e288ac5b52d7115688d4e6516acbbea1c)ViewVC
|r343372||erj||Jan. 24, 2019, 1:08 a.m.||ixl(4): Fix handling data passed with ioctl from NVM update tool
From Krzysztof: Ensure that the entire data buffer passed from the NVM update tool is copied in to kernel space and copied back out to user space using copyin() and copyout(). PR: 234104 Submitted by: Krzysztof Galazka <firstname.lastname@example.org> Reported by: Finn <email@example.com> MFC after: 5 days Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D18817ViewVC
|r343369||erj||Jan. 24, 2019, 1:03 a.m.||intel iflib drivers: correct initialization of tx_cidx_processed
From Jake: In r341156 ("Fix first-packet completion", 2018-11-28) a hack to work around a delta calculation determining how many descriptors were used was added to ixl_isc_tx_credits_update_dwb. The same fix was also applied to the em and igb drivers in r340310, and to ix in r341156. The hack checked the case where prev and cur were equal, and then added one. This works, because by the time we do the delta check, we already know there is at least one packet available, so the delta should be at least one. However, it's not a complete fix, and as indicated by the comment is really a hack to work around the real bug. The real problem is that the first time that we transmit a packet, tx_cidx_processed will be set to point to the start of the ring. Ultimately, the credits_update function expects it to point to the *last* descriptor that was processed. Since we haven't yet processed any descriptors, pointing it to 0 results in this incorrect calculation. Fix the initialization code to have it point to the end of the ring instead. One way to think about this, is that we are setting the value to be one prior to the first available descriptor. Doing so, corrects the delta calculation in all cases. The original fix only works if the first packet has exactly one descriptor. Otherwise, we will report 1 less than the correct value. As part of this fix, also update the MPASS assertions to match the real expectations. First, ensure that prev is not equal to cur, since this should never happen. Second, remove the assertion about prev==0 || delta != 0. It looks like that originated from when the em driver was converted to iflib. It seems like it was supposed to ensure that delta was non-zero. However, because we originally returned 0 delta for the first calculation, the "prev == 0" was tacked on. Instead, replace this with a check that delta is greater than zero, after the correction necessary when the ring pointers wrap around. This new solution should fix the same bug as r341156 did, but in a more robust way. Submitted by: Jacob Keller <firstname.lastname@example.org> Reviewed by: shurd@ Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D18545ViewVC
|r343368||ngie||Jan. 23, 2019, 11:48 p.m.||Fix up r343367
I should have only changed the format qualifier with the `size_t` value, `length`, not the other [`off_t`] value, `dest_file_size`. MFC after: 1 month MFC with: r343362, r343365, r343367 Approved by: emaste (mentor; implicit) Reported by: gcc 8.xViewVC
|r343367||ngie||Jan. 23, 2019, 11:30 p.m.||Unbreak the build on architectures where size_t isn't synonymous with uintmax_t|
|r343366||brooks||Jan. 23, 2019, 11:25 p.m.||Remove documentation for the nonexistant cred_update_thread(9).|
|r343365||ngie||Jan. 23, 2019, 11:06 p.m.||Unbreak the gcc build with sendfile_test after r343362
gcc 8.x is more pedantic than clang 7.x with format strings and the tests passed `void*` variables while supplying `%s` (which is technically incorrect). Make the affected `void*` variables use `char*` storage instead to address this issue, as the compiler will upcast the values to `char*`. MFC after: 1 month MFC with: r343362 Approved by: emaste (mentor; implicit) Reviewed by: asomers Differential Revision: https://reviews.freebsd.org/D18934ViewVC
|r343364||markj||Jan. 23, 2019, 10:19 p.m.||Style.
Reviewed by: bz MFC after: 3 days Sponsored by: The FreeBSD FoundationViewVC
|r343363||markj||Jan. 23, 2019, 10:18 p.m.||Fix an LLE lookup race.
After the afdata read lock was converted to epoch(9), readers could observe a linked LLE and block on the LLE while a thread was unlinking the LLE. The writer would then release the lock and schedule the LLE for deferred free, allowing readers to continue and potentially schedule the LLE timer. By the point the timer fires, the structure is freed, typically resulting in a crash in the callout subsystem. Fix the problem by modifying the lookup path to check for the LLE_LINKED flag upon acquiring the LLE lock. If it's not set, the lookup fails. PR: 234296 Reviewed by: bz Tested by: sbruno, Victor <email@example.com>, Mike Andrews <firstname.lastname@example.org> MFC after: 3 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D18906ViewVC
|r343362||ngie||Jan. 23, 2019, 10 p.m.||Add [initial] functional tests for sendfile(2) as lib/libc/sys/sendfile
These testcases exercise a number of functional requirements for sendfile(2). The testcases use IPv4 and IPv6 domain sockets with TCP, and were confirmed functional on UFS and ZFS. UDP address family sockets cannot be used per the sendfile(2) contract, thus using UDP sockets is outside the scope of testing the syscall in positive cases. As seen in `:s_negative_udp_socket_test`, UDP is used to test the sendfile(2) contract to ensure that EINVAL is returned by sendfile(2). The testcases added explicitly avoid testing out `SF_SYNC` due to the complexity of verifying that support. However, this is a good next logical item to verify. The `hdtr_positive*` testcases work to a certain degree (the header testcases pass), but the trailer testcases do not work (it is an expected failure). In particular, the value received by the mock server doesn't match the expected value, and instead looks something like the following (using python array notation): `trailer[:]message[1:]` instead of: `message[:]trailer[:]` This makes me think there's a buffer overrun issue or problem with the offset somewhere in the sendfile(2) system call, but I need to do some other testing first to verify that the code is indeed sane, and my assumptions/code isn't buggy. The `sbytes_negative` testcases that check `sbytes` being set to an invalid value resulting in `EFAULT` fails today as the other change (which checks `copyout(9)`) has not been committed . Thus, it should remain an expected failure (see bug 232210 for more details on this item). Next steps for testing sendfile(2): 1. Fix the header/trailer testcases so that they pass. 2. Setup if_tap interface and test with it, instead of using "localhost", per @asomers's suggestion. 3. Handle short recv(2)'s in `server_cat(..)`. 4. Add `SF_SYNC` support. 5. Add some more negative tests outside the scope of the functional contract. MFC after: 1 month Reviewed by: asomers Approved by: emaste (mentor) PR: 232210 Sponsored by: Netflix, Inc Differential Revision: https://reviews.freebsd.org/D18625ViewVC
|r343354||markj||Jan. 23, 2019, 8:02 p.m.||Remove extraneous setutxent() calls in write(1).|
|r343353||markj||Jan. 23, 2019, 6:58 p.m.||Correct uma_prealloc()'s use of domainset iterators after r339925.
The iterator should be reinitialized after every successful slab allocation. A request to advance the iterator is interpreted as an allocation failure, so a sufficiently large preallocation would cause the iterator to believe that all domains were exhausted, resulting in a sleep with the keg lock held.  Also, keg_alloc_slab() should pass the unmodified wait flag to the item initialization routine, which may use it to perform allocations from other zones. Reported and tested by: slavah Diagnosed by: kib  Reviewed by: kib MFC after: 1 week Sponsored by: The FreeBSD FoundationViewVC