Bug 161009 - prism54/ipv6 network deadlock
prism54/ipv6 network deadlock
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: John W. Linville
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-06-19 14:48 EDT by David Woodhouse
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-16 14:36:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2005-06-19 14:48:15 EDT
After a period of use, my normally reliable prism54 card locked up:

Jun 19 19:31:37 shinybook kernel: eth1: timeout waiting for mgmt response
Jun 19 19:31:40 shinybook last message repeated 3 times
Jun 19 19:31:40 shinybook kernel: eth1: mgmt tx queue is still full
Jun 19 19:31:57 shinybook last message repeated 403 times
Jun 19 19:31:57 shinybook NetworkManager: <WARNING>       ():
nm_device_get_frequency(): error getting frequency for device eth1.  errno = 5
Jun 19 19:31:57 shinybook NetworkManager: <WARNING>       ():
nm_device_get_essid(): error getting ESSID for device eth1.  errno = 5
Jun 19 19:31:57 shinybook kernel: eth1: mgmt tx queue is still full

I removed it and plugged it back in again to reset it, and this started...

Jun 19 19:36:06 shinybook kernel: unregister_netdevice: waiting for eth1 to
become free. Usage count = 4
Jun 19 19:36:37 shinybook last message repeated 3 times

It's probably an IPv6-related bug.
Comment 1 John W. Linville 2005-07-08 11:10:45 EDT
The hardware might be locking-up...? 
How long is "a period"?  More importantly, how much traffic occurred during 
that time?  The code looks like it _might_ be susceptible to a roll-over, but 
the values are 32-bits so it would take a lot of mgmt frames... 
Comment 2 David Woodhouse 2005-07-08 11:29:48 EDT
Yeah, the hardware probably was locking up. It was a period of hours. 

The machine is perfectly reliable in the office, but at home where the prism54
gets plugged in, it tends to do this and also to just be entirely dead when I
try to use it in the morning. Must leave it switched to vt1 overnight and see if
there's anything useful on the screen.

In fact this doesn't seem to be happening as much with the latest FC4 kernel --
I don't think I've seen it happen in the few days since I updated, and it was
happening quite a lot for a while beforehand, on an intermediate kernel. The FC4
release kernel was OK too.

The IPv6 thing is almost certainly a separate bug.
Comment 3 Dave Jones 2005-07-15 17:43:12 EDT
[This comment has been added as a mass update for all FC4 kernel bugs.
 If you have migrated this bug from an FC3 bug today, ignore this comment.]

Please retest your problem with todays 2.6.12-1.1398_FC4 update.

If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..

mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak

Thank you.
Comment 4 John W. Linville 2005-09-16 14:36:32 EDT
David, I'm going to close this as part of the bug scrub.  Please reopen if you 
think this is still an issue...thanks! 

Note You need to log in before you can comment on or make changes to this bug.