Hide Forgot
Description of problem: When I suspend my laptop and resume, my iwl4965 doesn't resume operation. If I rmmod iwl4965 then modprobe iwl4965 it immediately resumes operation and works fine with NetworkManager again. Version-Release number of selected component (if applicable): Driver built into the kernel. My uname -a is "Linux dv2727ca 2.6.24.3-12.fc8 #1 SMP Tue Feb 26 14:58:29 EST 2008 i686 i686 i386 GNU/Linux". DV2727CA is my laptop model and hostname How reproducible: 100% Steps to Reproduce: 1.suspend laptop 2.resume laptop 3.notice lack of network 4.rmmod iwl4965 then modprobe it 5.notice fully working network Actual results: Network doesn't work Expected results: Network works Additional info:
As well, when the network is in a non working state, NetworkManager shows other SSIDs, but they are all secured and not mine, so i can't check if they are connectable. I tried manually adding my network, which didn't work. It is also now happening when i log out then log back in. Basically, any time i leave my desktop, the driver dies
I just updated to a new kernel "Linux dv2727ca 2.6.24.3-34.fc8 #1 SMP Wed Mar 12 18:17:20 EDT 2008 i686 i686 i386 GNU/Linux" and it seems to fix my problem. It takes about 30 seconds, but my network comes back. I have only tested it once though
Issue still seems to be present when I logout and login.
Can you attach some logs from /var/log/messages from the period of time during a connection attempt?
Same issue here, once you've been successfully connected to a (in my case WPA2-PSK) network it doesn't work automatically anymore after disconnecting (restarting NetworkManager is enough). My own network doesn't show up in NM-applet anymore while others (but not all that were available before...) do. I can however reconnect by providing the essid and psk manually using "connect to other network". "iwlist wlan0 scan" also doesn't show the network anymore, also not after a successful manual reconnect with nm-applet. It looks like scanning is broken somehow after a disassociation from an AP. But not for all networks, maybe just for the same channel / frequency? Kernel: kernel-2.6.24.4-64.fc8.x86_64 I restarted NetworkManager -> sudo /etc/init.d/NetworkManager restart -> My own network is not there anymore... -> connect by using "connect to other network". wlan0: switched to short barker preamble (BSSID=00:14:bf:a5:05:78) b44: eth0: powering down PHY wlan0: disassociate(reason=3) wlan0: disassociate(reason=3) ACPI: PCI interrupt for device 0000:0c:00.0 disabled ADDRCONF(NETDEV_UP): eth0: link is not ready ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17 Registered led device: iwl-phy0:radio Registered led device: iwl-phy0:assoc Registered led device: iwl-phy0:RX Registered led device: iwl-phy0:TX ADDRCONF(NETDEV_UP): wlan0: link is not ready wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:bf:a5:05:78 wlan0: RX authentication from 00:14:bf:a5:05:78 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:14:bf:a5:05:78 wlan0: RX AssocResp from 00:14:bf:a5:05:78 (capab=0x411 status=0 aid=1) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: no IPv6 routers present [fkooman@dilithium ~]$ nm-tool dump - Device: wlan0 ---------------------------------------------------------------- Type: 802.11 Wireless Driver: iwl4965 Active: yes HW Address: 00:1F:3B:07:91:91 Capabilities: Supported: yes Speed: 54 Mb/s Wireless Settings WEP Encryption: yes WPA Encryption: yes WPA2 Encryption: yes Wireless Access Points(* = Current AP) WLAN VDV: Infra, 00:14:BF:48:80:6A, Freq 2462 MHz, Rate 54 Mb/s, Strength 49 WPA WPA2 WLAN MKOX: Infra, 00:1D:7E:4B:3F:F4, Freq 2412 MHz, Rate 54 Mb/s, Strength 37 WPA2 Linnie: Infra, 00:18:39:33:AF:24, Freq 2462 MHz, Rate 54 Mb/s, Strength 38 WEP *pltln: Infra, 00:14:BF:A5:05:78, Freq 2432 MHz, Rate 54 Mb/s, Strength 100 WPA2 Greatfield: Infra, 00:17:3F:46:FA:4A, Freq 2462 MHz, Rate 54 Mb/s, Strength 77 WEP lievejoost: Infra, 00:06:25:F9:D4:FA, Freq 2462 MHz, Rate 11 Mb/s, Strength 33 WEP springbokken: Infra, 00:50:18:54:54:E8, Freq 2462 MHz, Rate 54 Mb/s, Strength 28 WPA IP Settings: IP Address: 192.168.1.50 Subnet Mask: 255.255.255.0 Broadcast: 192.168.1.255 Gateway: 192.168.1.1 DNS: 192.168.1.1 Not sure what else I can report. When the network is not found it doesn't try to connect, so no failed connection attempts in my case...
Also interesting, when I'm reconnected to my own network (manually) all networks are found again after a short time. After disassociation it doesn't scan anymore? or not completely at least... ?
the switch to turn off the wifi card also does the same thing to my card, except that it forces me to reboot to get internet back
Could be the hardware scanning bug that's been going around; does it seem like that john? Comment 1 seems to indicate the hw_scan bug.
I see this as well. Extract from dmesg: iwl4965: Wait for START_ALIVE timeout after 2000ms. ACPI: PCI interrupt for device 0000:02:00.0 disabled ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 17 iwl4965: Wait for START_ALIVE timeout after 2000ms. ACPI: PCI interrupt for device 0000:02:00.0 disabled and then I have to reload the module.
I have this problem too, it all started after an update sometime in March. I have a Dell XPS m1330 laptop with the iwl4965 Here's /var/log/messages from a resume from suspend where the card failed to reconnect to my WPA wifi network: Mar 29 18:43:25 ratbook kernel: ALSA sound/pci/hda/patch_sigmatel.c:1241: hda_codec: pin nid 22 pin config 40000100 Mar 29 18:43:25 ratbook kernel: ALSA sound/pci/hda/patch_sigmatel.c:1241: hda_codec: pin nid 23 pin config 00000000 Mar 29 18:43:25 ratbook NetworkManager: <info> Waking up from sleep. Mar 29 18:43:25 ratbook NetworkManager: <info> eth0: Device is fully-supported using driver 'tg3'. Mar 29 18:43:25 ratbook NetworkManager: <info> Now managing wired Ethernet (802.3) device 'eth0'. Mar 29 18:43:25 ratbook NetworkManager: <info> Bringing up device eth0 Mar 29 18:43:25 ratbook kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Mar 29 18:43:25 ratbook NetworkManager: <info> Deactivating device eth0. Mar 29 18:43:25 ratbook acpid: client connected from 2635[0:0] Mar 29 18:43:25 ratbook NetworkManager: <info> (eth0): exporting device as /org/freedesktop/Hal/devices/net_00_15_c5_81_35_00 Mar 29 18:43:25 ratbook NetworkManager: <info> wlan0: Device is fully-supported using driver 'iwl4965'. Mar 29 18:43:25 ratbook NetworkManager: <info> wlan0: driver supports SSID scans (scan_capa 0x01). Mar 29 18:43:25 ratbook NetworkManager: <info> Now managing wireless (802.11) device 'wlan0'. Mar 29 18:43:25 ratbook NetworkManager: <info> Bringing up device wlan0 Mar 29 18:43:25 ratbook kernel: PCI: Enabling device 0000:0c:00.0 (0000 -> 0002) Mar 29 18:43:25 ratbook kernel: ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17 Mar 29 18:43:25 ratbook kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready Mar 29 18:43:25 ratbook NetworkManager: <info> Deactivating device wlan0. Mar 29 18:43:25 ratbook NetworkManager: <WARN> nm_device_802_11_wireless_disable_encryption(): error setting key for device wlan0: No such file or directory Mar 29 18:43:25 ratbook NetworkManager: <info> (wlan0): exporting device as /org/freedesktop/Hal/devices/net_00_1d_e0_28_bd_cd Mar 29 18:43:25 ratbook NetworkManager: <info> (eth0) supplicant interface is now in state 2 (from 1). Mar 29 18:43:25 ratbook NetworkManager: <info> (wlan0) supplicant interface is now in state 2 (from 1). Mar 29 18:43:25 ratbook kernel: uvcvideo: Failed to query (135) UVC control 1 (unit 0) : -110 (exp. 26). Mar 29 18:43:25 ratbook kernel: usb 7-1: USB disconnect, address 2 Mar 29 18:43:26 ratbook kernel: usb 7-1: new full speed USB device using uhci_hcd and address 3 Mar 29 18:43:26 ratbook kernel: usb 7-1: configuration #1 chosen from 1 choice Mar 29 18:43:45 ratbook ntpd[6391]: ntpd 4.2.4p2@1.1495-o Mon Sep 24 14:40:07 UTC 2007 (1)
I should add that, as the original bug report states, the wireless starts working on my laptop if I execute: $ sudo /sbin/modprobe --remove iwl4965 $ sudo /sbin/modprobe iwl4965 Another observation, every time I have to use the above commands, the Network Manager prompts me for the WPA passphrase again. Normally, this passphrase is remembered by NM and I don't have to enter it (upon bootup or when resume from suspend works properly). I have the following versions: NetworkManager-0.7.0-0.6.7.svn3235.fc8 Kernel 2.6.24.4-64.fc8
I think this may relate to bug 438613 (or vice versa).
It seems fixed now for me, although reconnecting after suspend is still a bit slow (15 seconds after unlocking by typing password). kernel-2.6.25-14.fc9.x86_64 * Fri Apr 25 2008 John W. Linville <linville@redhat.com> 2.6.25-10 - mac80211: Fix n-band association problem ^^^ This fixed it? I have a Intel 4965 btw.
Do you find that it works after a hibernate (aka suspend-to-disk) as well? Or does it still fail then?
That also works here... how about the bug reporter?
Still present in kernel-2.6.24.7-92.fc8. Any plans to backport the fix? ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 17 iwl4965: Microcode HW error detected. Restarting. iwl4965: Microcode HW error detected. Restarting. iwl4965: Wait for START_ALIVE timeout after 2000ms. iwl4965: Microcode HW error detected. Restarting. ACPI: PCI interrupt for device 0000:02:00.0 disabled
F8 kernels currently have later wireless code than the F9 kernels have, so I'm not sure there is a fix to backport... :-(
Are current F9 kernels exhibiting this behavior? http://koji.fedoraproject.org/koji/buildinfo?buildID=50712
Still no luck with kernel-2.6.25.4-14.fc8.
Ditto kernel-2.6.25.4-16.fc8.
And kernel-2.6.25.6-24.fc8, interrupt disabled. Might add in a pm hook to reload the module...
this seems to work for me in fedora 9 (2.6.25-14.fc9.x86_64)
Seems fixed in kernel-2.6.25.6-27.fc8...
It still doesn't work for me in kernel 2.6.25.6-55.fc9.x86_64 Thinkpad R61, Intel 4965. Fedora 9 x86_64. All packages up to date.
I think my Comment #23 was a fluke. I see some major unhappiness with kernel-2.6.25.8-35.fc8. Got this on resume --- although this was with ieee80211_regdom="EU" for cfg80211 (which has other problems). I'll test again later with the default regdom. PCI: Enabling device 0000:02:00.0 (0000 -> 0002) ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16 iwl4965: Microcode HW error detected. Restarting. iwl4965: Microcode HW error detected. Restarting. iwl4965: START_ALIVE timeout after 2000ms. irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.25.8-35.fc8 #1 [<c045b7e0>] __report_bad_irq+0x2e/0x6f [<c045ba01>] note_interrupt+0x1e0/0x217 [<c045aef3>] ? handle_IRQ_event+0x2a/0x5a [<c045c12f>] handle_fasteoi_irq+0x8b/0xac [<c045c0a4>] ? handle_fasteoi_irq+0x0/0xac [<c0407ea7>] do_IRQ+0x8c/0xb9 [<c0406563>] common_interrupt+0x23/0x28 [<c062a890>] ? _spin_unlock_irqrestore+0xa/0x14 [<c043ab73>] pm_qos_requirement+0x26/0x2b [<c05a0fd8>] menu_select+0x55/0x79 [<c05a058d>] ? cpuidle_idle_call+0x0/0x8b [<c05a05ce>] cpuidle_idle_call+0x41/0x8b [<c05a058d>] ? cpuidle_idle_call+0x0/0x8b [<c04046d6>] cpu_idle+0xa4/0xc4 [<c061bc85>] rest_init+0x49/0x4b ======================= handlers: [<c05791d4>] (usb_hcd_irq+0x0/0x51) [<f8ae08e4>] (sdhci_irq+0x0/0x4dd [sdhci]) [<f8ae08e4>] (sdhci_irq+0x0/0x4dd [sdhci]) Disabling IRQ #16
That trace doesn't look to be related to iwl4965. Also FWIW the kernel in question doesn't support the "EU" regdom. You might try "JP" for now.
Re: comment #26: this was a deduction based on the observations that iwl4965 was on IRQ 16 before the suspend/resume, and immediately afterwards was the only module that had disappeared from IRQ 16 in /proc/interrupts. Could be an ACPI bug. Either way, I've not seen it in kernel-2.6.25.9-37.fc8, in which the connection simply doesn't come back.
Still no luck with kernel-2.6.25.9-38.fc8, I see a "iwl4965: START_ALIVE timeout after 2000ms." and then the interrupt is disabled. Normal service after reload.
I'm gradually coming to the conclusion that NetworkManager *does* work - if i'm patient enough. It can take quite a while, after resuming from a suspend to RAM, for it to come back to life again - and i've been giving up on it before that point. Now i switch it on and just ignore it for several minutes and it seems it will snap out of its slumber and connect ok. The first time after a reboot it seems to wake up much faster - but gets slower after that. I haven't timed it, that's just the way it seems. I'm not 100% certain that this is what the problem has been, but i've resumed several times over the last few days and it connects every time - eventually. I'm running 2.6.25.6-55.fc9.x86_64 kernel. I'm not sure if it worked this way before the update to that kernel version or not - as i probably never gave it long enough to find out.
I've now seen an Oops in iwl4965 following suspend/resume with kernel-2.6.25.9-42.fc8. Again, I see the "irq 16: nobody cared" message followed by the same trace (I stand by comment #27). I then tried modprobe -r to try and reload it and got an oops: iwl4965: Can't stop Rx DMA. BUG: unable to handle kernel paging request at 768d6cac IP: [<f8bc2fe1>] :iwl4965:iwl4965_pci_remove+0x27d/0x34f *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: cpufreq_stats i915 drm coretemp hwmon rfcomm l2cap bluetooth autofs4 fuse nf_conntrack_ipv4 ipt_REJECT iptable_filter ip_tables nf_conntrack_ftp nf_conntrack_ipv6 xt_state nf_conntrack xt_tcpudp ip6t_ipv6header ip6t_REJECT ip6table_filter ip6_tables x_tables ipv6 cpufreq_ondemand acpi_cpufreq loop dm_multipath snd_hda_intel snd_seq_dummy arc4 snd_seq_oss snd_seq_midi_event snd_seq ecb crypto_blkcipher snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm iwl4965(-) iwlcore firewire_ohci snd_timer firewire_core video snd_page_alloc rfkill uvcvideo compat_ioctl32 snd_hwdep sdhci crc_itu_t output snd mac80211 mmc_core i2c_i801 battery soundcore videodev wmi ac r8169 button v4l1_compat pcspkr joydev i2c_core iTCO_wdt cfg80211 serio_raw iTCO_vendor_support sr_mod sg cdrom dm_snapshot dm_zero dm_mirror dm_mod ata_generic ata_piix pata_acpi libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode] Pid: 15062, comm: modprobe Not tainted (2.6.25.9-42.fc8 #1) EIP: 0060:[<f8bc2fe1>] EFLAGS: 00210247 CPU: 0 EIP is at iwl4965_pci_remove+0x27d/0x34f [iwl4965] EAX: 00000000 EBX: 768d6cac ECX: 00200246 EDX: 00200246 ESI: f8bd0110 EDI: f68d0e60 EBP: f6f81ee4 ESP: f6f81ec4 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process modprobe (pid: 15062, ti=f6f81000 task=f6896000 task.ti=f6f81000) Stack: f68d6cac f78ef800 f68d1448 00000000 00200246 f78ef800 f8bd0110 f8bd0110 f6f81ef0 c0501c45 f78ef854 f6f81f00 c056652b f78ef854 f78ec054 f6f81f14 c0566997 f8bd0110 00000000 c07260c0 f6f81f28 c0565f58 00000000 f8bd0110 Call Trace: [<c0501c45>] ? pci_device_remove+0x19/0x39 [<c056652b>] ? __device_release_driver+0x5b/0x78 [<c0566997>] ? driver_detach+0xa3/0xe0 [<c0565f58>] ? bus_remove_driver+0x63/0x7f [<c0566a1d>] ? driver_unregister+0x2a/0x2e [<c0501df2>] ? pci_unregister_driver+0x1e/0x4f [<f8bc2d5d>] ? iwl4965_exit+0xd/0x14 [iwl4965] [<c044563c>] ? sys_delete_module+0x172/0x1aa [<c0455ffb>] ? audit_syscall_entry+0x101/0x12b [<c0405b7e>] ? syscall_call+0x7/0xb ======================= Code: 00 e8 84 82 89 c7 8d 87 b4 60 00 00 e8 ee 77 86 c7 8d 87 4c 5e 00 00 c7 45 ec 00 00 00 00 89 45 e0 8b 45 ec 8b 9c c7 4c 5e 00 00 <8b> 33 eb 13 89 d8 e8 54 84 93 c7 8d 43 f0 89 f3 e8 70 a1 8b c7 EIP: [<f8bc2fe1>] iwl4965_pci_remove+0x27d/0x34f [iwl4965] SS:ESP 0068:f6f81ec4 ---[ end trace 4710fb3b54aa1c01 ]---
I've had the same problems, with a HP 8510W notebook, but the latest updates (Linux version 2.6.25.10-86.fc9.x86_64) seems to have fixed this particular problem. The wireless connection comes back up both after a suspend/resume, as well as a hibernate/restore. I've still got IRQ 19: nobody cared, and swapper tainted after resume, and hibernate/resume makes X (nvidia binary) eat CPU, but the wifi does comes back.
Can anyone else confirm comment 31 with -86 or -97?
I can neither really confirm nor deny, but i'm running 2.6.25.11-97.fc9.x86_64 and NetworkManager has come back ok from suspend twice now. Its behaviour is a bit inconsistent so far though. Yesterday morning it just came back up and connected to the wireless network. This morning, though, it asked for the network password - and then connected ok. That's not a very representative sample, i know. But i'll post again here if anything worth mentioning happens.
I should have mentioned it's a Thinkpad R61.
On my T61 I was able to suspend/resume (and hibertnate/resume) multiple times on F9 and it always came back, albeit with occasionaly NM delays. Anyone still having problems needs to speak-up quickly.
Ditto, it seems to be working without any error messages for me with kernel 2.6.25.13-65.fc8 (modulo NM timeouts).
Well, i'm very sorry to have to report that this issue appears to have come back! Yesterday, i updated to the 2.6.26.5-45.fc9.x86_64 and this morning, when i woke my laptop up from suspend, the wireless network didn't come back. I had to stop NetworkManager, unload and reload the modules, and restart NetworkManager, and then it worked ok. I'll let yous know if it's any different tomorrow morning.
this is back for me as well. I am experiencing it on the latest kernel and using x86-64 and i386