| created | 2020-08-16T08:56:53Z |
|---|---|
| begin | 2020-08-12T00:00:00Z |
| end | 2020-08-13T00:00:00Z |
| path | src/sys |
| commits | 6 |
| date | 2020-08-12T03:48:22Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/drm_fb_helper.c | log | diff | annotate |
| src/sys/dev/pci/drm/include/drm/drm_mode_config.h | log | diff | annotate | |
| message |
drm/drm_fb_helper: fix fbdev with sparc64 From Sam Ravnborg cea0a7943a30a6d0320c8558a844dd27e8f0aa8b in linux 5.7.y/5.7.15 2a1658bf922ffd9b7907e270a7d9cdc9643fc45d in mainline linux |
|||
| date | 2020-08-12T04:58:49Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/radeon/radeon_bios.c | log | diff | annotate |
| message |
skip trying to read disabled bios on RV610 Reading the disabled bios on two Dell machines with RV610 passes initial checks but later fails atombios specific checks. This occurs when running amd64 but not i386. Returning early when reading the disabled bios will result in calling radeon_read_platform_bios() and using the bios at 0xc0000 which works for both systems this was reported for semarie@ on Dell OptiPlex 755 RV610 0x1002:0x94C3 0x1028:0x0402 0x00 Andy Bradford on Dell DXP051 RV610 0x1002:0x94C1 0x1028:0x0D02 0x00 |
|||
| date | 2020-08-12T08:41:39Z | |||
|---|---|---|---|---|
| author | mvs | |||
| files | src/sys/net/if_pppx.c | log | diff | annotate |
| src/sys/net/pipex.c | log | diff | annotate | |
| message |
Remove interface statistics update for outgoing packets. We shouldn't count them because `if_snd' does this. ok yasuoka@ |
|||
| date | 2020-08-12T13:49:24Z | |||
|---|---|---|---|---|
| author | visa | |||
| files | src/sys/kern/kern_event.c | log | diff | annotate |
| message |
Reduce stack usage of kqueue_scan() Reuse the kev[] array of sys_kevent() in kqueue_scan() to lower stack usage. The code has reset kevp, but not nkev, whenever the retry branch is taken. However, the resetting is unnecessary because retry should be taken only if no events have been collected. Make this clearer by adding KASSERTs. OK mpi@ |
|||
| date | 2020-08-12T14:41:09Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/kern/kern_time.c | log | diff | annotate |
| message |
setitimer(2): ITIMER_REAL: don't call timeout_del(9) before timeout_add(9) If we're replacing the current ITIMER_REAL timer with a new one we don't need to call timeout_del(9) before calling timeout_add(9). timeout_add(9) does the work of timeout_del(9) implicitly if the timeout in question is already pending. This saves us an extra trip through the timeout_mutex. |
|||
| date | 2020-08-12T15:31:27Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/kern/kern_time.c | log | diff | annotate |
| message |
getitimer(2): delay TIMESPEC_TO_TIMEVAL(9) conversion until copyout(9) setitimer(2) works with timespecs in its critical section. It will be easier to merge the two critical sections if getitimer(2) also works with timespecs. In particular, we currently read the uptime clock *twice* during a setitimer(2) swap: we call getmicrouptime(9) in sys_getitimer() and then call getnanouptime(9) in sys_setitimer(). This means that swapping one timer in for another is not atomic with respect to the uptime clock. It also means the two operations are working with different time structures and resolutions, which is potentially confusing. If both critical sections work with timespecs we can combine the two getnanouptime(9) calls into a single call at the start of the combined critical section in a future patch, making the swap atomic with respect to the clock. So, in preparation, move the TIMESPEC_TO_TIMEVAL conversions in getitimer(2) after the ITIMER_REAL conversion from absolute to relative time, just before copyout(9). The ITIMER_REAL conversion must then be done with timespec macros and getnanouptime(9), just like in setitimer(2). |
|||