Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 161009 - prism54/ipv6 network deadlock
Summary: prism54/ipv6 network deadlock
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-19 18:48 UTC by David Woodhouse
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-09-16 18:36:32 UTC

Attachments (Terms of Use)

Description David Woodhouse 2005-06-19 18:48:15 UTC
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 15:10:45 UTC
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 15:29:48 UTC
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 21:43:12 UTC
[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 18:36:32 UTC
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.