On 27/09/15(Sun) 15:51, David Gwynne wrote:
> this uses the refcnt api to do the heavy lifting.
>
> i think we have all the if_get/if_put calls we need, so this should
> be safe at this point.
>
> if anyone wants to test, can you try detaching or destroying
> interfaces and check that the ifconfi
It seems to me that the recent iwm(4)/if_setlladdr() fix applies to
more (if not all) wireless drivers since the stack keeps its own
copy of the lladdr. Does the diff below make sense?
I'd also suggest to stop abusing "ac_enaddr" or "ic_myaddr" and use
if_sadl instead. Having 3 copies of the sam
On Mon, Sep 28, 2015 at 01:02:24PM +0200, Martin Pieuchot wrote:
> It seems to me that the recent iwm(4)/if_setlladdr() fix applies to
> more (if not all) wireless drivers since the stack keeps its own
> copy of the lladdr. Does the diff below make sense?
>
> I'd also suggest to stop abusing "ac_
This diff makes the tx completion path run without the kernel lock
held. With this change, the interrupt handler will not grab the
kernel lock under normal circumstances. The diff follows the same
approach as dlg@ took with vmx(4).
The diff removes the code that tries to reclaim tx descriptors i
Earlier this month, kettenis identified a bug in uvm from an incompletely
reverted change. Clearing the wrong bit on a page would sometimes result in
the page queues being corrupted, and then eventually the system would crash or
panic.
This issue affects 5.7 and the forthcoming 5.8 release.
Patch
On 28.9.2015. 23:53, Mark Kettenis wrote:
> This diff makes the tx completion path run without the kernel lock
> held. With this change, the interrupt handler will not grab the
> kernel lock under normal circumstances. The diff follows the same
> approach as dlg@ took with vmx(4).
>
> The diff r
there's nothing random about this file, and it upsets me whenever i see it's
name go by, because i panic thinking mg has some stupid random number
generator that hasn't been fixed yet. util.c is a better name.
(and cvs rm/add)
Index: Makefile
==
