| created | 2021-10-20T09:35:55Z |
|---|---|
| begin | 2021-05-31T00:00:00Z |
| end | 2021-06-01T00:00:00Z |
| path | src/sys |
| commits | 7 |
| date | 2021-05-31T04:13:42Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/arch/arm64/dev/aplns.c | log | diff | annotate |
| src/sys/dev/ic/nvme.c | log | diff | annotate | |
| src/sys/dev/pci/nvme_pci.c | log | diff | annotate | |
| message |
try to get rid of a weird comma on the alpns attach line. "makes sense" jmatthew@ |
|||
| date | 2021-05-31T04:48:35Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/dev/ic/nvme.c | log | diff | annotate |
| message |
make nvme_read8 and write8 less clever. hopefully big endian still works. |
|||
| date | 2021-05-31T08:40:41Z | |||
|---|---|---|---|---|
| author | stsp | |||
| files | src/sys/dev/pci/if_iwm.c | log | diff | annotate |
| message |
Avoid "mac clock not ready" panic in iwm(4). The point of iwm_nic_assert_locked() is to verify that iwm_nic_lock() has been called somewhere up in the call stack. Checking our own lock counter is sufficient for this purpose. If locking the device worked then these registers had the expected state at that time and our lock counter was incremented. Apparently if the device runs into some issue later the state of these registers may change and trigger these panics. Instead we want to handle such failures gracefully and reset the device. problem reported by steven@ ok kettenis@ |
|||
| date | 2021-05-31T08:43:07Z | |||
|---|---|---|---|---|
| author | stsp | |||
| files | src/sys/dev/pci/if_iwx.c | log | diff | annotate |
| message |
Avoid "mac clock not ready" panic in iwx(4). The same change was just made in iwm(4): The point of iwm_nic_assert_locked() is to verify that iwm_nic_lock() has been called somewhere up in the call stack. Checking our own lock counter is sufficient for this purpose. If locking the device worked then these registers had the expected state at that time and our lock counter was incremented. Apparently if the device runs into some issue later the state of these registers may change and trigger these panics. Instead we want to handle such failures gracefully and reset the device. problem reported by steven@ ok kettenis@ |
|||
| date | 2021-05-31T12:45:33Z | |||
|---|---|---|---|---|
| author | visa | |||
| files | src/sys/kern/kern_time.c | log | diff | annotate |
| message |
Redefine ADJFREQ_MIN to avoid undefined behaviour (when not using -fwrapv) Change the definition of ADJFREQ_MIN so that it does not shift a negative value. Such shifting is undefined in standard C. This came up when cross-compiling the kernel using ports clang. The shifting becomes defined when compiling with option -fwrapv. Base clang enables this option by default. OK naddy@ cheloha@ |
|||
| date | 2021-05-31T13:44:04Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/uvm/uvm_pdaemon.c | log | diff | annotate |
| message |
call drmbackoff() on powerpc64 as well ok kettenis@ |
|||
| date | 2021-05-31T21:06:48Z | |||
|---|---|---|---|---|
| author | mglocker | |||
| files | src/sys/dev/usb/uvideo.c | log | diff | annotate |
| message |
Change the behavior of the UVIDEO_FLAG_REATTACH flag to attach an unsupported device to uvideo(4), but not to video(1), instead of just keeping it unmatched. Also uvideo(4) will print a message about the device not being supported. ok mpi@ |
|||