[patch] Skip background scan if bssid is set

2018-04-28 Thread Jesper Wallin
Hi all, I recently learned that my AP behaves badly and I have packet loss when the background scan is running. I had a small chat with stsp@ about it, asking if there is a way to disable it. He kindly explained that if I'm connected to an AP with a weak signal, it will try to find another AP

typo in pms.c

2018-04-28 Thread Ryan Lennox
Hi, caught a typo while digging around in here: Index: src/sys/dev/pckbc/pms.c === RCS file: /cvs/src/sys/dev/pckbc/pms.c,v retrieving revision 1.85 diff -u -p -u -r1.85 pms.c --- src/sys/dev/pckbc/pms.c 29 Jan 2018 21:54:11

Re: hashinit(): power of 2 fast path

2018-04-28 Thread Mathieu -
Anton Lindqvist wrote: > Hi, > If the elements argument passed to hashinit() is a power of 2 there's no > need to find the closest power of 2 that can fit all elements since > elements == hashsize will always be true. During boot of a stock amd64 > kernel running inside vmd 80% of the calls to

hashinit(): power of 2 fast path

2018-04-28 Thread Anton Lindqvist
Hi, If the elements argument passed to hashinit() is a power of 2 there's no need to find the closest power of 2 that can fit all elements since elements == hashsize will always be true. During boot of a stock amd64 kernel running inside vmd 80% of the calls to hashinit() includes a power of 2

Re: [PATCH] mv -P

2018-04-28 Thread Jesper Wallin
Hi, Adding a -P to your command might of course be easier, but since you have -P in rm(1) and -v was added recently, won't this do: mv newfile "$(rm -Pv oldfile)" Regards Jesper Wallin

Re: [PATCH] mv -P

2018-04-28 Thread Theo de Raadt
attila wrote: > Hi tech@, > > I frequently want to move a file from one place to another and shred > the original via the rm(1) -P option. On several occasions I have > forgotten about wanting to shred the original file when using mv(1) > instead (out of habit) and ended

switchd(8): ignore packet_out with dstport = OFP_PORT_ANY

2018-04-28 Thread Ayaka Koshibe
On Fri, Apr 20, 2018 at 10:18:34AM -0700, Ayaka Koshibe wrote: > Hi, > > switchd(8) sends packet_outs with OFP_PORT_ANY as the dstport, causing > switches receiving them to disconnect due to validation failure of the said > message. The comments indicate that looping packets should be ignored,

remove 2 obsolete libraries from Xenocara

2018-04-28 Thread Matthieu Herrb
Hi, libXfontcache and libXxf86misc are implementing the client part of X extensions that have been disabled/removed for a while in the X server. So builing them or linking to them is useless. The patch below stops building them in xenocara. A few ports where using libXxf86misc. Rebuilding them

Re: [PATCH] mv -P

2018-04-28 Thread Ingo Schwarze
Hi, attila wrote on Sat, Apr 28, 2018 at 11:50:17AM -0500: > I frequently want to move a file from one place to another and shred > the original via the rm(1) -P option. I strongly object to adding another turd on top of the useless rm(1) -P option; it was recently discussed how useless it is,

[PATCH] mv -P

2018-04-28 Thread attila
Hi tech@, I frequently want to move a file from one place to another and shred the original via the rm(1) -P option. On several occasions I have forgotten about wanting to shred the original file when using mv(1) instead (out of habit) and ended up losing the ability to do so easily because

Re: new semapahore implementation using atomics and futexes

2018-04-28 Thread Paul Irofti
On Sun, Apr 22, 2018 at 03:34:45PM +0300, Paul Irofti wrote: > Hi, > > Here is a new semaphore implementation that uses atomic operations, > where available, and futexes for locking. > > The reason we need this is to make semaphores safe for asynchronous > signals. > > > All posixsuite tests

Re: free all nodes and set linkstate to down when entering the SCAN state for all drivers

2018-04-28 Thread Paul Irofti
On Sat, Apr 28, 2018 at 05:26:19PM +0200, Peter Hessler wrote: > Some drivers use their own functions to change the link state for a > non-background scan, so ensure that they set the link state to down, and > free all nodes. This is a follow up to stsp@'s ieee80211.c:r1.68. > > (N.B. the atu

Re: free all nodes and set linkstate to down when entering the SCAN state for all drivers

2018-04-28 Thread Stefan Sperling
On Sat, Apr 28, 2018 at 05:26:19PM +0200, Peter Hessler wrote: > Some drivers use their own functions to change the link state for a > non-background scan, so ensure that they set the link state to down, and > free all nodes. This is a follow up to stsp@'s ieee80211.c:r1.68. > > (N.B. the atu

Re: fix scan on run(4)

2018-04-28 Thread Paul Irofti
> I cannot reproduce the problem; run(4) scans fine on my -current machine. Yes. Sorry about the noise. I was running an older kernel that did not include yesterday's diff.

free all nodes and set linkstate to down when entering the SCAN state for all drivers

2018-04-28 Thread Peter Hessler
Some drivers use their own functions to change the link state for a non-background scan, so ensure that they set the link state to down, and free all nodes. This is a follow up to stsp@'s ieee80211.c:r1.68. (N.B. the atu driver already calls ieee80211_free_allnodes in this case statement, but

Re: Faster msdosfs read

2018-04-28 Thread Martin Pieuchot
On 26/04/18(Thu) 23:06, Landry Breuil wrote: > On Thu, Apr 26, 2018 at 10:01:25PM +0200, Martin Pieuchot wrote: > > This is the 4th attempt to implement clustering for msdosfs. See [0] > > for the previous story. > > > > This version implements the strict necessary to read a maximum of 64k > >

Re: interface queue transmit mitigation (again)

2018-04-28 Thread Hrvoje Popovski
On 28.3.2018. 11:42, Hrvoje Popovski wrote: > On 28.3.2018. 3:28, David Gwynne wrote: >> On Thu, Mar 15, 2018 at 03:25:46PM +0100, Martin Pieuchot wrote: >>> On 14/03/18(Wed) 13:00, David Gwynne wrote: this adds transmit mitigation back to the tree. it is basically the same diff as

Re: fix scan on run(4)

2018-04-28 Thread Stefan Sperling
On Sat, Apr 28, 2018 at 02:38:43PM +0300, Paul Irofti wrote: > Hi, > > Apparently we need to increase the scan count everytime, else we get no > nodes in the list. > > Found the hardway on mpi's run(4). > > Is there any device that still needs that check? > > Paul This diff cannot be right

fix scan on run(4)

2018-04-28 Thread Paul Irofti
Hi, Apparently we need to increase the scan count everytime, else we get no nodes in the list. Found the hardway on mpi's run(4). Is there any device that still needs that check? Paul diff --git sys/net80211/ieee80211_node.c sys/net80211/ieee80211_node.c index 70d6419e619..e10d1cab81d 100644

Re: Fail early in USB

2018-04-28 Thread Paul Irofti
On Sat, Apr 28, 2018 at 10:33:55AM +0200, Martin Pieuchot wrote: > If USB transfers aren't completed in order, the stack cannot recover. > > So don't try to continue when this happen and make it clear what the > problem is. Currently the kernel panic in many different ways or > worse enters an

Fail early in USB

2018-04-28 Thread Martin Pieuchot
If USB transfers aren't completed in order, the stack cannot recover. So don't try to continue when this happen and make it clear what the problem is. Currently the kernel panic in many different ways or worse enters an infinite loop sometimes after that happened. ok? Index: usbdi.c