| created | 2019-12-04T07:10:56Z |
|---|---|
| begin | 2019-12-02T00:00:00Z |
| end | 2019-12-03T00:00:00Z |
| path | src/sys |
| commits | 10 |
| date | 2019-12-02T01:38:06Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/stand/boot/cmd.c | log | diff | annotate |
| message |
For 32 bit systems, cast the long long used by strtoll() to unsigned long and then a void * for calling the hexdump() operator with bluhm |
|||
| date | 2019-12-02T02:24:29Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/kern/kern_tc.c | log | diff | annotate |
| message |
tc_windup: separate timecounter.tc_freq_adj from timehands.th_adjustment We currently mix timecounter.tc_freq_adj and timehands.th_adjtimedelta in ntp_update_second() to produce timehands.th_adjustment, our net skew. But if you set a low enough adjfreq(2) adjustment you can freeze time. This prevents ntp_update_second() from running again. So even if you then set a sane adjfreq(2) you cannot unfreeze time without rebooting. If we just reread timecounter.tc_freq_adj every time we recompute timehands.th_scale we avoid this trap. visa@ notes that this is more costly than what we currently do but that the cost itself is negligible. Intuitively, timecounter.tc_freq_adj is a constant skew and should be handled separately from timehands.th_adjtimedelta, an adjustment that we chip away at very slowly. tedu@ notes that this problem is sort-of an argument for imposing range limits on adjfreq(2) inputs. He's right, but I think we should still separate the counter adjustment from the adjtime(2) adjustment, with or without range limits. ok visa@ |
|||
| date | 2019-12-02T03:38:13Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | log | diff | annotate |
| message |
drm/amd/powerplay: issue no PPSMC_MSG_GetCurrPkgPwr on unsupported ASICs From Evan Quan 8a67fbf6597122c4a5e2c48716bc441364357eef in linux 4.19.y/4.19.87 355d991cb6ff6ae76b5e28b8edae144124c730e4 in mainline linux |
|||
| date | 2019-12-02T03:41:12Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/i915/i915_gem_userptr.c | log | diff | annotate |
| message |
drm/i915/userptr: Try to acquire the page lock around set_page_dirty() From Chris Wilson e80e88ef6057c7947409bda9898387d25e54aaa9 in linux 4.19.y/4.19.87 2d691aeca4aecbb8d0414a777a46981a8e142b05 in mainline linux |
|||
| date | 2019-12-02T14:01:26Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/uvm/uvm_map.c | log | diff | annotate |
| message |
Stop supporting UVM_FLAG_TRYLOCK in uvm_mapanon(), it is not used. ok tedu@, visa@ |
|||
| date | 2019-12-02T15:01:18Z | |||
|---|---|---|---|---|
| author | visa | |||
| files | src/sys/kern/vfs_lockf.c | log | diff | annotate |
| message |
Remove now unneeded kernel locking from vfs_lockf.c. OK mpi@ anton@ |
|||
| date | 2019-12-02T15:02:32Z | |||
|---|---|---|---|---|
| author | visa | |||
| files | src/sys/kern/vfs_lockf.c | log | diff | annotate |
| message |
Replace rwsleep(9) with rwsleep_nsec(9) in vfs_lockf.c. Prompted by and OK cheloha@ OK mpi@ anton@ |
|||
| date | 2019-12-02T15:10:27Z | |||
|---|---|---|---|---|
| author | krw | |||
| files | src/sys/scsi/scsi_base.c | log | diff | annotate |
| message |
Don't forget the scsi_vpd_header when calculating the number of bytes obtained by scsi_inquire_vpd(). |
|||
| date | 2019-12-02T17:53:05Z | |||
|---|---|---|---|---|
| author | krw | |||
| files | src/sys/scsi/scsi_base.c | log | diff | annotate |
| message |
Have SCSIDEBUG show the number of bytes of VPD inquiry data received, not the number of bytes that were available in the buffer. |
|||
| date | 2019-12-02T21:47:54Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/kern/kern_tc.c | log | diff | annotate |
| src/sys/kern/kern_timeout.c | log | diff | annotate | |
| src/sys/kern/uipc_socket.c | log | diff | annotate | |
| src/sys/sys/timeout.h | log | diff | annotate | |
| message |
Revert "timeout(9): switch to tickless backend" It appears to have caused major performance regressions all over the network stack. Reported by bluhm@ ok deraadt@ |
|||