Bug 642966 - iwlagn wireless disappears
Summary: iwlagn wireless disappears
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-14 10:33 UTC by David Woodhouse
Modified: 2012-08-16 18:41 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-08-16 18:41:33 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
all syslog messages containing "iwlagn" (127.10 KB, text/plain)
2011-02-03 23:46 UTC, Stephan Dühr
no flags Details

Description David Woodhouse 2010-10-14 10:33:34 UTC
[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.

Comment 1 John W. Linville 2010-10-14 13:05:11 UTC
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?

Comment 2 Stanislaw Gruszka 2010-10-14 13:30:29 UTC
Maybe this is not not iwlwifi bug but rather a pciehp issue. I saw similar problem in bug 637466 for different card.

Comment 3 David Woodhouse 2010-10-14 21:11:36 UTC
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...

Comment 4 wey-yi.w.guy 2010-10-14 23:26:39 UTC
David, it will be great if I can access the box since I do work for Intel.

Wey

Comment 5 Stephan Dühr 2011-02-03 23:45:16 UTC
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".

Comment 6 Stephan Dühr 2011-02-03 23:46:42 UTC
Created attachment 476915 [details]
all syslog messages containing "iwlagn"

Comment 7 Stanislaw Gruszka 2011-02-04 07:38:00 UTC
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.

Comment 8 Tomasz Kepczynski 2011-03-10 12:25:30 UTC
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.

Comment 9 Dave Jones 2011-10-11 17:54:40 UTC
is this still affecting f15/f16 beta ?
It's unlikely we'll fix this in f14 given where it is in its lifecycle.

Comment 10 Fedora End Of Life 2012-08-16 18:41:36 UTC
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


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