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.
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...
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.
[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 kudzu Thank you.
David, I'm going to close this as part of the bug scrub. Please reopen if you think this is still an issue...thanks!