Herbert Xu wrote:
On Thu, May 24, 2007 at 08:47:13PM +1000, Herbert Xu wrote:
On Thu, May 24, 2007 at 11:36:22AM +0100, Jeremy Fitzhardinge wrote:
I got a hang while rmmodding e1000. sysrq-t shows:
rmmod D 003FFAFC 6616 15923 15911 (NOTLB)
e9341e44 00000092 82318c15 003ffafc e9341e2c 00000000 e9341e14 823187a1
003ffafc 00000000 c0123862 d3dbab80 d3dbad1c c2c08a40 77a67d01 000001ca
00000292 e9341e24 c03799cd e9341e54 c0540840 e9341e44 00223389 000000ff
Call Trace:
[<c03777b1>] schedule_timeout+0x70/0x8e
[<c03777e4>] schedule_timeout_uninterruptible+0x15/0x17
[<c0133d04>] msleep+0x10/0x16
[<c030d5e0>] dev_close+0x39/0x6b
Looks like we're spinning on __LINK_STATE_RX_SCHED. This means that
someone called netif_poll_disable() without re-enabling it again.
Perhaps e1000_io_error_detected? Auke?
Should not be, e1000_io_error_detected will call e1000_down which does the
netif_poll_disable, but e1000_io_resume nicely calls e1000_up again which does
the netif_poll_enable again, unless io_resume somehow failed
I think the dual meaning of __LINK_STATE_RX_SCHED is seriously broken.
In dev_close we are waiting for any outstanding poll to terminate but
the same bit can either mean an outstanding poll or that poll has
been disabled.
that seems more likely
It's a surprise that it has taken so many years for someone to report
a bug on it. I'll try to get this fixed up, probably by adding a bit.
I get the feeling that a recent change exposed us to this, our lab has been
seeing similar OOPS's yesterday out of nothing.
Auke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
