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
===
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 in
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
-
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 sin
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 l
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
> > pe
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 out
> 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.
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 dri
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 dri
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 (
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 mv(1)
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,
s
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 wi
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, whi
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 up losing the ability to
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
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 size
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 hash
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 -000
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
wi
Don't use attr uninitialised. Avoids glitches seen when using
scrollback with radeondrm.
Index: rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.53
diff -u -p -r1.53 rasops.c
--- rasops.c27 Apr 2018
22 matches
Mail list logo
