Post by Jeff Garzik Post by Kok, Auke Post by David Miller
Date: Fri, 07 Sep 2007 09:19:30 +0200
Post by Jiri Slaby
I found a regression in 2.6.23-rc4-mm1 (since -rc3-mm1) in e1000e driver.
napi_disable(&adapter->napi) in e1000_probe freezes the kernel on boot.
Yes, the semantics changed slightly in the net-2.6.24 tree the
other week and someone needs to fix it up.
The netif_napi_add() implicitly does a napi_disable() call. Device
open must explicitly napi_enable() and device close must explicitly
napi_disable(), and if done elsewhere these calls must be strictly
I'll fix it... it's my patch that adds the new napi code to it and I
need to get it ready for the merge window anyway.
well.... since its close to the merge window opening, we could see what
happens if DaveM pulls branch 'upstream' of
That should make this class of pre-merge-window annoyance go away.
If I do that now I get a big merge conflict:
$ git-pull . net-2.6.24
100% (22583/22583) done
CONFLICT (content): Merge conflict in drivers/net/8139too.c
CONFLICT (content): Merge conflict in drivers/net/ibmveth.c
CONFLICT (content): Merge conflict in drivers/net/pasemi_mac.c
CONFLICT (content): Merge conflict in drivers/net/s2io.c
Automatic merge failed; fix conflicts and then commit the result.
for e1000e the fixup is just a 1-line change from the previous -mm napi fixup
patch, so I don't really care (it's peanuts), but people might want to start
looking into the above conflicts ;)
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.