Description of problem: Originally booted with kernel 2307, yum installed kernel 2336, decided to kexec into new kernel instead of reboot (simply because grub defaults to XP and I wanted to let machine reboot unattended) Old kernel shut down ok, new kernel started up ok, logged on then realised but NetworkManager hadn't detected ipw2200 which was working under previous FC6T1 and rawhide kernels, I thought that maybe an uodated driver required newer firmware, so checked dmesg, and found following message extracts related to ipw2200 ieee80211_crypt: registered algorithm 'NULL' ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno.com> ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.1.2kmprq ipw2200: Copyright(c) 2003-2006 Intel Corporation ipw2200: Detected Intel PRO/Wireless 2915ABG Network Connection irq 5: nobody cared (try booting with the "irqpoll" option) <c04050e1> show_trace_log_lvl+0x65/0x184 <c04057b6> show_trace+0xf/0x11 <c04058b9> dump_stack+0x15/0x17 <c0451c72> __report_bad_irq+0x36/0x7d <c0451e4c> note_interrupt+0x193/0x1cb <c045152a> __do_IRQ+0xaf/0xe0 <c040678a> do_IRQ+0xb9/0xca <c040491e> common_interrupt+0x1a/0x20 handlers: [<f89e2573>] (ipw_isr+0x0/0xa1 [ipw2200]) Disabling IRQ #5 ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Unable to initialize device after 5 attempts. ipw2200: failed to register network device ACPI: PCI interrupt for device 0000:02:03.0 disabled ipw2200: probe of 0000:02:03.0 failed with error -5 initially just thought ipw2200 must be broken in this kernel, then remembered that I had kexeced the kernel, so rebooted without using kexec and ipw2200 loaded and operates ok as before. Version-Release number of selected component (if applicable): Linux version 2.6.17-1.2336.fc6 (brewbuilder.redhat.com) (gcc v ersion 4.1.1 20060629 (Red Hat 4.1.1-6)) #1 SMP Thu Jun 29 17:29:15 EDT 2006 How reproducible: ?
Wow, sorry this report went unnoticed for so long! I hate to ask, but have you tried recent kernels? If it is still a problem, we'll help sort it out.
I assume this is kdump, you are using, right? Not just a plain kexec? Can you attach the full serial console log during the kexec kernel boot please? My first guess is that while re-inserting the module we callout to look for ipw firmware, and can't load it because its not included in the initramfs
(In reply to comment #2) > I assume this is kdump, you are using, right? Not just a plain kexec? Not kdump: "Originally booted with kernel 2307, yum installed kernel 2336, decided to kexec into new kernel instead of reboot (simply because grub defaults to XP and I wanted to let machine reboot unattended)"
Heh, I'd forgotten I even logged this :-) I haven't tried it on any recent kernels, I do have F8 on the same laptop now, and it will require a kernel update so I'll try to reproduce it ...
hmm, looking at the stack trace above, I'm wondering if we're generating an interrupt on the wireless interface before we re-register the driver. Booting with irqpoll would fix that, although thats not something you want to do if you're not doing something like kdump. We may need to forcibly re-enable the irq that we register for on bootup again. Test with the latest kernel, just as you suggest, and see ifyou get the same error. We can figure out how best to fix it from there. Thanks!
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The information we've requested above is required in order to review this problem report further and diagnose or fix the issue if it is still present. Since it has been thirty days or more since we first requested additional information, we're assuming the problem is either no longer present in the current Fedora release, or that there is no longer any interest in tracking the problem. Setting status to "CLOSED INSUFFICIENT_DATA". If you still experience this problem after updating to our latest Fedora release and can provide the information previously requested, please feel free to reopen the bug report. Thank you in advance.