OpenBSD cvs log

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

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@