tsleep_nsec(9) for ehci(4)

I converted the 'hz / 2' idiom into MSEC_TO_NSEC(500), the rest is obvious. ok? Index: ehci.c === RCS file: /cvs/src/sys/dev/usb/ehci.c,v retrieving revision 1.204 diff -u -p -r1.204 ehci.c --- ehci.c 31 Mar 2019 06:16:38 -

tsleep_nsec(9) for uvideo(4) + utvfu(4)

The code is identical 8) ok? Index: uvideo.c === RCS file: /cvs/src/sys/dev/usb/uvideo.c,v retrieving revision 1.203 diff -u -p -r1.203 uvideo.c --- uvideo.c7 Aug 2019 11:16:02 - 1.203 +++ uvideo.c7 Oct 2019 07:36:3

Re: tsleep_nsec(9) for ehci(4)

On Mon, Oct 07, 2019 at 09:51:02AM +0200, Martin Pieuchot wrote: > I converted the 'hz / 2' idiom into MSEC_TO_NSEC(500), the rest is > obvious. OK kn

Re: tsleep_nsec(9) for uvideo(4) + utvfu(4)

On Mon, Oct 07, 2019 at 09:53:01AM +0200, Martin Pieuchot wrote: > The code is identical 8) ok? OK kn

macppc: tsleep(9) -> tsleep_nsec(9)

ok? Index: mediabay.c === RCS file: /cvs/src/sys/arch/macppc/dev/mediabay.c,v retrieving revision 1.6 diff -u -p -r1.6 mediabay.c --- mediabay.c 18 Nov 2013 20:21:51 - 1.6 +++ mediabay.c 7 Oct 2019 13:33:54 - @@ -235,10

octmmc(4): msleep(9) -> msleep_nsec(9)

ok? Index: octmmc.c === RCS file: /cvs/src/sys/arch/octeon/dev/octmmc.c,v retrieving revision 1.13 diff -u -p -r1.13 octmmc.c --- octmmc.c13 Jan 2019 16:45:44 - 1.13 +++ octmmc.c7 Oct 2019 13:37:16 - @@ -965,7 +96

luna88k: pcexmem(4): tsleep(9) -> tsleep_nsec(9)

ok? Index: pcex.c === RCS file: /cvs/src/sys/arch/luna88k/cbus/pcex.c,v retrieving revision 1.3 diff -u -p -r1.3 pcex.c --- pcex.c 18 Feb 2015 22:42:04 - 1.3 +++ pcex.c 7 Oct 2019 13:45:48 - @@ -194,12 +194,12 @

Re: macppc: tsleep(9) -> tsleep_nsec(9)

On Mon, Oct 07, 2019 at 08:35:23AM -0500, Scott Cheloha wrote: > ok? OK kn > -smu_do_cmd(struct smu_softc *sc, int timo) > +smu_do_cmd(struct smu_softc *sc, int msecs) thanks

Re: octmmc(4): msleep(9) -> msleep_nsec(9)

On Mon, Oct 07, 2019 at 08:38:06AM -0500, Scott Cheloha wrote: > ok? OK kn

etc.arm64/login.conf, sync pbuild class with amd64

Attempting to build Firefox on aarch64 needs at least 4.5GB but I think it would be better to just sync with amd64. OK? Index: login.conf === RCS file: /cvs/src/etc/etc.arm64/login.conf,v retrieving revision 1.5 diff -u -p -r1.5 login

net80211: increase background scan backoff timer

Frequent background scans are known to cause packet loss with some types of APs (e.g. old Apple APs and some Android phones). There is already a heuristic to make bgscans less frequent if we keep choosing the same AP. However, the current backoff interval keeps increasing in tiny steps of 500ms,

net80211: provide a flag to turn roaming off

This adds a new nwflag which can be used to disable roaming between APs (i.e. disable background scanning) with ifconfig. Currently, the only way to disable background scans is to hard-code the BSSID of an access point. We can provide a more obvious toggle for rare situations where APs are known t

Re: Attach Hyper-V guest services to VMBus 4.0

On Sat, Oct 05, 2019 at 03:19:08PM +0200, Mike Belopuhov wrote: > > Remi Locherer writes: > > > On Tue, Oct 01, 2019 at 12:25:35AM +0200, Mike Belopuhov wrote: > >> > >> > >> Hi, > >> > >> I've got a verbal report that Hyper-V guest services aren't attached > >> on modern Windows 10 systems so

Re: etc.arm64/login.conf, sync pbuild class with amd64

On Mon, 07 Oct 2019 15:25:13 +0100, Stuart Henderson wrote: > Attempting to build Firefox on aarch64 needs at least 4.5GB but I think > it would be better to just sync with amd64. OK? Makes sense. OK millert@ - todd

Re: sxipwm, pwmbl - work in progress, simplefb integration?

> Date: Sun, 6 Oct 2019 23:32:07 +0200 > From: Krystian Lewandowski > > Good evening Mark, tech@, > I was trying to enable brightness control on Pinebook, so it could be set via: > wsconsctl display.brightness=N%. > > I added sxipwm and pwmbl drivers. First relies on "pwm" bindings, > 2nd - on "

Re: more grep options (for zstdgrep)

While I'm looking at the man page, a minor clarification. "All long options are provided" can be read to mean that every gnu option is provided. This is not intended, and a simple reordering makes things clearer imo. Index: grep.1 =

Re: more grep options (for zstdgrep)

On Mon, Oct 07, 2019 at 04:55:07PM -0400, Ted Unangst wrote: > "All long options are provided" can be read to mean that every gnu option is > provided. This is not intended, and a simple reordering makes things clearer > imo. OK kn

Re: more grep options (for zstdgrep)

On Sun, Oct 06, 2019 at 02:28:09PM -0400, Ted Unangst wrote: > The zstd package includes a zstdgrep script, which should behave like zgrep, > however it assumes a few gnu grep behaviors we don't support. > > 1. --label=name prints a custom label, so you can get file.txt, not > file.txt.zst in the

Re: more grep options (for zstdgrep)

On Mon, Oct 07, 2019 at 04:55:07PM -0400, Ted Unangst wrote: > While I'm looking at the man page, a minor clarification. > > "All long options are provided" can be read to mean that every gnu option is > provided. This is not intended, and a simple reordering makes things clearer > imo. > it is