[174689.991525] pciehp 0000:00:1c.4:pcie04: Card not present on Slot(4) [174689.996420] pciehp 0000:00:1c.4:pcie04: Card present on Slot(4) [174690.032615] pciehp 0000:00:1c.4:pcie04: Card not present on Slot(4) [174690.036828] pciehp 0000:00:1c.4:pcie04: Card present on Slot(4) [174690.491175] iwlagn 0000:0b:00.0: Error sending REPLY_RXON: time out after 500ms. [174690.491187] iwlagn 0000:0b:00.0: Error setting new RXON (-110) [174690.492416] mac80211-phy0: failed to remove key (0, 00:06:25:4b:55:f8) from hardware (-16) [174690.492732] wlan0: deauthenticating from 00:06:25:4b:55:f8 by local choice (reason=3) [174690.994155] iwlagn 0000:0b:00.0: Error sending REPLY_RXON: time out after 500ms. [174690.994167] iwlagn 0000:0b:00.0: Error setting new RXON (-110) [174690.994729] mac80211-phy0: failed to remove key (2, ff:ff:ff:ff:ff:ff) from hardware (-16) [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174690.995614] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174691.350197] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174691.369500] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174691.390278] iwlagn 0000:0b:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF [174691.429075] cfg80211: Calling CRDA to update world regulatory domain [174691.429110] cfg80211: Calling CRDA for country: GB [174691.435597] iwlagn 0000:0b:00.0: HARDWARE GONE?? INTA == 0xffffffff [174691.435639] iwlagn 0000:0b:00.0: PCI INT A disabled The hardware seems to have gone. Only a reboot recovers.
David, how often does this happen? Is it easily recreatable? Any chance you can get that box to Wey-Yi for some testing and observation?
Maybe this is not not iwlwifi bug but rather a pciehp issue. I saw similar problem in bug 637466 for different card.
This kind of thing was happening a lot a year or two ago, but then went away. And now it's happening every day or two. It's an Intel-owned box, so I can't really give access to any non-Intel employee. But for Intel folks I can make it available over a wired network...
David, it will be great if I can access the box since I do work for Intel. Wey
Is there any news on this? I have a similar problem ("HARDWARE GONE") on a ThinkPad T61 using F13. When I use wireless frequently this happens at least once a day sporadically, I can't reproduce it. I'll attach all syslog messages containing "iwlagn".
Created attachment 476915 [details] all syslog messages containing "iwlagn"
Stephan, your issue have similar symptoms but is different problem. In your logs there are "Microcode error detect" messages, what in general is iwl firmware error. In the past adding swcrypto=1 option helps wit that errors on 4965, but I'm not sure if that still helps, anyway please try. If that not helps, try drivers from http://people.redhat.com/sgruszka/compact_wireless.html , perhaps updated driver will not crash the firmware. If that fail, you fill bug on http://bugzilla.intellinuxwireless.org/ as described in http://intellinuxwireless.org/?n=fw_error_report . Since this is f/w problem only Intel can help with that. Please let me know results of swcrypto=1 option, if it helps, we may wish to use that option as default.
Same here, lots of: kernel: iwlagn 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x080003D8 which change after a while to: iwlagn 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x080003DC and then some kernel BUGs: Mar 9 17:02:14 tkepczyn-linux kernel: BUG: soft lockup - CPU#0 stuck for 61s! [iwlagn:892] Mar 9 17:02:14 tkepczyn-linux kernel: Modules linked in: fuse rfcomm sco bridge stp llc bnep l2cap btusb bluetooth autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 dm_mirror dm_region_hash dm_log uinput ppdev parport_pc parp ort tpm_infineon hp_accel lis3lv02d input_polldev wmi sg serio_raw iTCO_wdt iTCO_vendor_support arc4 ecb iwlagn iwlcore mac80211 cfg80211 rfkill snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm sn d_timer snd soundcore snd_page_alloc e1000e ext4 mbcache jbd2 pata_pcmcia yenta_socket rsrc_nonstatic sdhci_pci sdhci mmc_core firewire_ohci firewire_core crc_itu_t sd_mod crc_t10dif sr_mod cdrom pata_acpi ata_generic ahci nouveau ttm dr m_kms_helper drm i2c_algo_bit video output i2c_core dm_mod [last unloaded: microcode] Mar 9 17:02:14 tkepczyn-linux kernel: CPU 0: Mar 9 17:02:14 tkepczyn-linux kernel: Modules linked in: fuse rfcomm sco bridge stp llc bnep l2cap btusb bluetooth autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 dm_mirror dm_region_hash dm_log uinput ppdev parport_pc parp ort tpm_infineon hp_accel lis3lv02d input_polldev wmi sg serio_raw iTCO_wdt iTCO_vendor_support arc4 ecb iwlagn iwlcore mac80211 cfg80211 rfkill snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm sn d_timer snd soundcore snd_page_alloc e1000e ext4 mbcache jbd2 pata_pcmcia yenta_socket rsrc_nonstatic sdhci_pci sdhci mmc_core firewire_ohci firewire_core crc_itu_t sd_mod crc_t10dif sr_mod cdrom pata_acpi ata_generic ahci nouveau ttm dr m_kms_helper drm i2c_algo_bit video output i2c_core dm_mod [last unloaded: microcode] Mar 9 17:02:14 tkepczyn-linux kernel: Pid: 892, comm: iwlagn Not tainted 2.6.32-71.18.1.el6.x86_64 #1 HP EliteBook 8530w Mar 9 17:02:14 tkepczyn-linux kernel: RIP: 0010:[<ffffffff814cb7b7>] [<ffffffff814cb7b7>] _spin_unlock_irqrestore+0x17/0x20 Mar 9 17:02:14 tkepczyn-linux kernel: RSP: 0018:ffff880135f6bd40 EFLAGS: 00000287 Mar 9 17:02:14 tkepczyn-linux kernel: RAX: 00000000080003d4 RBX: ffff880135f6bd40 RCX: 0000000000002138 Mar 9 17:02:14 tkepczyn-linux kernel: RDX: ffff8801303f1c1c RSI: 0000000000000287 RDI: 0000000000000287 Mar 9 17:02:14 tkepczyn-linux kernel: RBP: ffffffff81013c8e R08: 000000000002c7ab R09: 0000000000000001 Mar 9 17:02:14 tkepczyn-linux kernel: R10: 0000000000000006 R11: 0000000000000000 R12: 00000000476e5248 Mar 9 17:02:14 tkepczyn-linux kernel: R13: 000000005fcc6f61 R14: 000000000002bb3d R15: 0000000000000001 Mar 9 17:02:14 tkepczyn-linux kernel: FS: 0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000 Mar 9 17:02:14 tkepczyn-linux kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Mar 9 17:02:14 tkepczyn-linux kernel: CR2: 00007f232088a000 CR3: 0000000001001000 CR4: 00000000000406f0 Mar 9 17:02:14 tkepczyn-linux kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Mar 9 17:02:14 tkepczyn-linux kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Mar 9 17:02:14 tkepczyn-linux kernel: Call Trace: Mar 9 17:02:14 tkepczyn-linux kernel: [<ffffffffa0379885>] ? iwl5000_apm_reset+0x155/0x4d0 [iwlagn] Mar 9 17:02:14 tkepczyn-linux kernel: [<ffffffffa0368b1d>] ? __iwl_down+0x3ed/0x490 [iwlagn] Mar 9 17:02:14 tkepczyn-linux kernel: [<ffffffffa0368be6>] ? iwl_down+0x26/0xd0 [iwlagn] Mar 9 17:02:14 tkepczyn-linux kernel: [<ffffffffa0368dfa>] ? iwl_bg_restart+0x9a/0xc0 [iwlagn] Mar 9 17:02:14 tkepczyn-linux kernel: [<ffffffffa0368d60>] ? iwl_bg_restart+0x0/0xc0 [iwlagn] Mar 9 17:02:14 tkepczyn-linux kernel: [<ffffffff8108c720>] ? worker_thread+0x170/0x2a0 Mar 9 17:02:14 tkepczyn-linux kernel: [<ffffffff81091df0>] ? autoremove_wake_function+0x0/0x40 Mar 9 17:02:14 tkepczyn-linux kernel: [<ffffffff8108c5b0>] ? worker_thread+0x0/0x2a0 Mar 9 17:02:14 tkepczyn-linux kernel: [<ffffffff81091a86>] ? kthread+0x96/0xa0 Mar 9 17:02:14 tkepczyn-linux kernel: [<ffffffff810141ca>] ? child_rip+0xa/0x20 Mar 9 17:02:14 tkepczyn-linux kernel: [<ffffffff810919f0>] ? kthread+0x0/0xa0 Mar 9 17:02:14 tkepczyn-linux kernel: [<ffffffff810141c0>] ? child_rip+0x0/0x20 Please note: the above comes from Scientificlinux 6 kernel-2.6.32-71.18.1.el6.x86_64, so you may consider cloning for RHEL6 as well.
is this still affecting f15/f16 beta ? It's unlikely we'll fix this in f14 given where it is in its lifecycle.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping