Bugzilla – Bug 2054
iwlwifi sends only small packets after wake-up from suspend to ram
Last modified: 2010-01-31 17:04:24
You need to log in before you can comment on or make changes to this bug.
This is a problem related to the iwlagn/WiFi Link 5300 on a thinkpad X301. I am using the latest 2.6.31-rc3 Kernel. To me it looks very much like some kind of data corruption. ifconfig shows a configured interface after wake-up from suspend to RAM and iwconfig shows that we are still associated to the AP. Small packets sent with an existing rsh connections to other hosts are OK. Large IP packets are not being sent out. I use WEP encryption. I have not checked if this is a requirement to reproduce the problem. To reproduce this problem you have to do the following: 1) Establish the network connection ifconfig wlan0 up iwconfig wlan0 essid ... ... 2) Start firefox and open a web page. Start ssh or rsh and login somewhere. 3) put the laptop to sleep: echo mem > /sys/power/state 4) wake it up and check with iwconfig and ifconfig that the network is still up. On the rsh connection type a command (e.g ls) and check that it works. 5) Start wireshark locally and on the web-server computer. Try to open a web page using the already open firefox browser. You will see that small packets such as tcp syn, and syn ack are being sent. It appears in the local wireshark that the http get is being sent. This is however not true. It will never arrive on the other end (web sever side). 6) Wait until the browser times out (the other side sends eventually an tcp rst). Now type: ifconfig wlan0 up iwconfig wlan0 essid TheEssID You will see that you can send now large packets. The web browser works again. Note that this workaround can not be not be added to any acpid scripts because you have to wait about 30sec after wake-up from suspend to ram before those commands can be used to remedy the problem.
Some new facts about this problem: This problem goes away if I use firmware iwlwifi-5000-ucode-5.4.A.11.tar.gz To reproduce the fault you need the latest firmware: iwlwifi-5000-ucode-8.24.2.12.tgz
I am using now kernel 2.6.31-rc6 and there are rare cases (about out out of 30) where it does actually work after wakeup from suspend. In those case one can see in the dmesg the following messages. [ 2598.248123] wlan0: direct probe to AP 00:0f:b5:17:42:ea try 1 [ 2598.250275] wlan0 direct probe responded [ 2598.250283] wlan0: authenticate with AP 00:0f:b5:17:42:ea [ 2598.253327] wlan0: authenticated [ 2598.253334] wlan0: associate with AP 00:0f:b5:17:42:ea [ 2598.256478] wlan0: RX ReassocResp from 00:0f:b5:17:42:ea (capab=0x431 status=0 aid=3) [ 2598.256486] wlan0: associated
I am not able to reproduce the issue on my 5100. I followed your instructions, all but the web testing part, I just used "ping -s 5000 <dest>" to test large frames. That should be fine right? With it being so easy to reproduce, could you please provide more debugging? This debugging will generate a lot of data, so only activate it _just_ before you try to send a large frame and try to capture all debug output. If your dmesg shows the buffer cannot hold all data, please modify your syslog.conf to redirect kernel messages to a file. Could you please obtain more debugging as follows: * follow all your original steps up to the point where you test large frames $ echo 0x41800000 > /sys/class/net/wlan0/device/debug_level * now test sending of large frames Thank you
This is incredible. Switching on the debug makes the problem disappear! One thing that I have noticed about the fault is this: normally when wifi is on then the wifi-led is constantly on. However when the problem is there then is flashes slowly. I don't know if that could be of any help. ecopad ~ # echo 0x41800000 > /sys/class/net/wlan0/device/debug_level ecopad ~ # dmesg | tail;date [ 1013.032230] ieee80211 phy0: I iwl_rx_handle r = 121, i = 120, REPLY_RX_MPDU_CMD, 0xc1 [ 1013.032243] ieee80211 phy0: I iwl_dbg_report_frame Beacon: 0x0080, dst=0xff, src=0xea, len=81, rssi=-39, tim=4111644745 usec, phy=0x73, chnl=13 [ 1013.032253] iwl data: 00000000: 80 00 00 00 ff ff ff ff ff ff 00 0f b5 17 42 ea ..............B. [ 1013.032260] iwl data: 00000010: 00 0f b5 17 42 ea c0 5c 7f d1 52 f5 b4 00 00 00 ....B..\..R..... [ 1013.032267] iwl data: 00000020: 64 00 31 04 00 07 73 61 6e 73 66 69 6c 01 04 82 d.1...sansfil... [ 1013.032274] iwl data: 00000030: 84 8b 96 03 01 0d 04 06 01 02 00 00 00 00 05 04 ................ [ 1013.032280] iwl data: 00000040: 00 01 00 00 2a 01 00 32 08 0c 12 18 24 30 48 60 ....*..2....$0H` [ 1013.032287] iwl data: 00000050: 6c l [ 1013.032339] ieee80211 phy0: I iwl_rx_handle r = 122, i = 121, STATISTICS_NOTIFICATION, 0x9d [ 1013.032346] ieee80211 phy0: I iwl_rx_statistics Statistics notification received (480 vs -1367342620). Fri Sep 18 21:39:49 EDT 2009 ecopad ~ # dmesg | tail;date [ 1020.507540] ieee80211 phy0: I iwl_dbg_report_frame Beacon: 0x0080, dst=0xff, src=0xea, len=81, rssi=-38, tim=4119119944 usec, phy=0x73, chnl=13 [ 1020.507549] iwl data: 00000000: 80 00 00 00 ff ff ff ff ff ff 00 0f b5 17 42 ea ..............B. [ 1020.507557] iwl data: 00000010: 00 0f b5 17 42 ea 60 62 7f e1 c4 f5 b4 00 00 00 ....B.`b........ [ 1020.507564] iwl data: 00000020: 64 00 31 04 00 07 73 61 6e 73 66 69 6c 01 04 82 d.1...sansfil... [ 1020.507571] iwl data: 00000030: 84 8b 96 03 01 0d 04 06 00 02 00 00 00 00 05 04 ................ [ 1020.507578] iwl data: 00000040: 00 01 00 00 2a 01 00 32 08 0c 12 18 24 30 48 60 ....*..2....$0H` [ 1020.507584] iwl data: 00000050: 6c l [ 1020.507594] ieee80211 phy0: I iwl_rx_handle r = 129, i = 128, STATISTICS_NOTIFICATION, 0x9d [ 1020.507601] ieee80211 phy0: I iwl_rx_statistics Statistics notification received (480 vs -1367342620). [ 1020.517505] ieee80211 phy0: I iwl_rx_handle r = 129, i = 129 Fri Sep 18 21:39:56 EDT 2009 ecopad ~ # dmesg | tail;date [ 1167.144730] ieee80211 phy0: I iwl_dbg_report_frame Beacon: 0x0080, dst=0xff, src=0xea, len=81, rssi=-38, tim=4265756744 usec, phy=0x73, chnl=13 [ 1167.144740] iwl data: 00000000: 80 00 00 00 ff ff ff ff ff ff 00 0f b5 17 42 ea ..............B. [ 1167.144747] iwl data: 00000010: 00 0f b5 17 42 ea 10 e3 7f 61 82 fe b4 00 00 00 ....B....a...... [ 1167.144754] iwl data: 00000020: 64 00 31 04 00 07 73 61 6e 73 66 69 6c 01 04 82 d.1...sansfil... [ 1167.144761] iwl data: 00000030: 84 8b 96 03 01 0d 04 06 00 02 00 00 00 00 05 04 ................ [ 1167.144768] iwl data: 00000040: 00 01 00 00 2a 01 00 32 08 0c 12 18 24 30 48 60 ....*..2....$0H` [ 1167.144775] iwl data: 00000050: 6c l [ 1167.144784] ieee80211 phy0: I iwl_rx_handle r = 56, i = 55, STATISTICS_NOTIFICATION, 0x9d [ 1167.144792] ieee80211 phy0: I iwl_rx_statistics Statistics notification received (480 vs -1367342620). [ 1167.154694] ieee80211 phy0: I iwl_rx_handle r = 56, i = 56 Fri Sep 18 21:42:23 EDT 2009 ecopad ~ # w3m -dump http://flocke.lnx/~guido/t.html Hello world, this is a very nice page for testing if the web works correctly. ecopad ~ # echo "now go to sleep" now go to sleep ecopad ~ # echo "back from suspend to ram"; date back from suspend to ram Fri Sep 18 21:43:32 EDT 2009 ecopad ~ # ping flocke.lnx PING flocke.lnx (10.0.0.1) 56(84) bytes of data. 64 bytes from flocke.lnx (10.0.0.1): icmp_seq=1 ttl=64 time=1.11 ms 64 bytes from flocke.lnx (10.0.0.1): icmp_seq=2 ttl=64 time=1.33 ms ^C --- flocke.lnx ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 1.115/1.226/1.338/0.116 ms ecopad ~ # w3m -dump http://flocke.lnx/~guido/t.html Hello world, this is a very nice page for testing if the web works correctly. guido@ecopad ~ $ uname -a Linux ecopad 2.6.31-1 #2 SMP PREEMPT Sun Sep 13 07:23:27 EDT 2009 i686 Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz GenuineIntel GNU/Linux
Created an attachment (id=2175) [details] tar file with wireshark capture and dmesg output while debug is on System: uname -a Linux ecopad 2.6.31-1 #2 SMP PREEMPT Sun Sep 13 07:23:27 EDT 2009 i686 Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz GenuineIntel GNU/Linux and Intel Wireless WiFi Link 5300AGN Description of the problem: After wake-up from suspend to ram it is possible to send small packets such as syn or ping... but big packets do not go through. It is possible to see them in wireshark but they never arrive at the other end. After I switched on the following debug the problem seemed to have disappeared: echo 0x41800000 > /sys/class/net/wlan0/device/debug_level but it works now only for newly established connections. An existing firefox application will still have the problem. Included files: Output of dmesg: -rw-r--r-- 1 root root 255812 Sep 20 10:05 wlanproblem-dmesg-forcap2.txt Screen shot of wireshark (corresponding to what you see in demsg): -rw-r--r-- 1 root root 261295 Sep 20 10:08 wlanproblemcap2.jpg Full wireshark capture (corresponding to what you see in demsg): -rw------- 1 root root 4695 Sep 20 10:01 wlanproblemcap2.pcap
Created an attachment (id=2176) [details] screen shot of wireshark Here is a wireshark screen shot you can clearly see that syn made it to the other end but http get did not arrive.
I got to know that nobody involved in the development of this has himself a WiFi Link 5300AGN card but everybody uses just a WiFi Link 5100AGN and assumes that it is the same card. With this knowledge in mind I decided to invest 100 $ and I bought a WiFi Link 5100AGN. The result: The problem is gone. This problem as described here is really specific to the 5300AGN.
Jeff or reinette: I can send you my 5300AGN card to reproduce the fault at your end. Let me know if you would like to have that card
(In reply to comment #8) > Jeff or reinette: > I can send you my 5300AGN card to reproduce the fault at your end. > Let me know if you would like to have that card I have 5300 card.
Jiajia, since you are running test on 5300, could you please help to try this issue? Thanks!
I can not reproduce this issue in the below testing environment: Platform : Intel SDV M3M41 Wireless Card : Intel(R) WiFi Link 5300 OS : Redhat Fedora release 10 (Cambridge) 64bit AP : Cisco 1250 uCode : iwlwifi-5000-2.ucode 8.24.2.12 Source : commit 8bbb594cf1bacb5ba805680b98ad144356e0f502 (Mon Nov 9 03:04:20 2009) After system waking up, I can "ping -s 5000 <dest>" and "scp 300Mfile <dest>".
Hi Jeff, ping has always worked for me. It might have something to do with the options used when a network socket is opened. I am not sure if scp is really doing the same as firefox. This fault happens only on WiFi Link 5300 and I have not seen any dependency on the access point. I had the problem at home and in various internet cafes. Try this: Start mozilla firefox Go to some web page. Now put the laptop to sleep (suspend to ram). Wake up the laptop. Use the same firefox you have already open and go to some web page. You can also start wireshark and see that there are packets sent out by firefox. You will see sys and syn ack but never any actual data packet.
I have some new insight about this problem: I can now re-produce it with the 5100. What I did is this: I connected via wifi to the network and changed in the router the channel from 13 to 8. re-associate to the access point after the change and browse the internet. Now put the laptop to sleep. After wake-up from sleep you have the problem. ... and this problem seems to survive a reboot ;%$!* There must be some kind of eeprom in the wifi card. I must say that I did right after buying the new laptop change frequently the channel settings in the router to minimize interference. I would have never thought that this could damage the wifi card permanently and that's why I did not mention it. After I bought the 5100 card I did for several weeks not play with the channel settings on the router. That's why this problem appeared to be gone.
I am not 100% certain that this is the scenario: Modifying the wifi router frequency channel settings damages some information inside the eeprom of the wifi card. This is a permanent damage and rebooting the computer does not fix it. As with most wifi routers my netgear router has web pages to change the settings. When one changes the channel the connection with the wifi router is of course lost in the middle of the communication as the router re-initializes and comes up with the same essid on a different channel. This procedure seems to permanently damage the wifi card on the laptop. The card still works but it looses the association after wake-up from suspend to ram.
Can I understand it as two issues? 1. After the card associates to AP and the system suspend to me, changing AP channel might destroy card eeprom 2. After issue 1, the card cannot resume the association after system resume.
They are two issues but they are linked. 1) changing the AP channel causes corruption of data in the eeprom of the wifi card 2) after the data has been corrupted the card does not properly work anymore after resume. One has to run iwconfig wlan1 essid "TheESSid" ifconfig wlan1 up to get the wifi working again. Without that there is packet loss as described earlier on. Without 1) fault symptom 2) would not appear.
> 2) after the data has been corrupted the card does not properly work anymore > after resume. One has to run > iwconfig wlan1 essid "TheESSid" > ifconfig wlan1 up > to get the wifi working again. Without that there is > packet loss as described earlier on. > Without 1) fault symptom 2) would not appear. Reinette, is it expected behavior? As I understand, driver will not make sure the association after resume. Upper level application (like wpa_supplicant) will do this task.
(In reply to comment #17) > > 2) after the data has been corrupted the card does not properly work anymore > > after resume. One has to run > > iwconfig wlan1 essid "TheESSid" > > ifconfig wlan1 up > > to get the wifi working again. Without that there is > > packet loss as described earlier on. > > Without 1) fault symptom 2) would not appear. > > Reinette, is it expected behavior? > > As I understand, driver will not make sure the association after resume. Upper > level application (like wpa_supplicant) will do this task. Correct. The driver does not initiate any association. The driver may try to reuse the association from before the resume, but at this point it is expected that the AP disassociated the station. Like you say, an upper level application like wpa_supplicant is required to restore the association.
OK, so your point is. After wake-up from suspend to ram the wifi connection must never work and it is the application that has to restore it. In other words your are saying: it is not the wifi card with the damaged eeprom data that is broken but all the new ones which come fresh from the intel factory. Note that we are not talking here about complicated encryption added on top (like wpa). If I take a plain new wifi card then it works: After wake-up from suspend to ram the wifi connection is up. If I take my laptop with the ipw2200 card then after wake-up the wifi connection is up. ... and on none of those I use wpa_supplicant or alike. It is all plain unencrypted or it is wep that I use. In all case the wifi connection works right away after wake-up. Even with the damaged eeprom it appears associated. You can see it with the printout iwconfig. The problem is the packet loss that happens. To get rid of the packet loss I have to run iwconfig wlan1 essid "TheESSid" ifconfig wlan1 up This is not needed to re-associate. It is needed to get rid of a data corruption that seem to happen inside the wifi card.
(Add Ben Cahill for firmware) Hi Guido, Here is my understand: 1. iwlagn driver does not do reassocation after resume. The previous wifi connection (before suspend) might/might not be there. To make sure the connection, user space application is responsible for the reassociation, like your iwconfig wlan1 essid "TheESSid" ifconfig wlan1 up So I think your issue 2 is expected behavior. 2. Given issue 2 is expected behavior, I wonder if the eeprom was destroyed. But if the eeprom is destroyed, this is a serious issue that should be fixed! Maybe you can try: 1. Associate to AP 2. suspend to mem 3. resume immediately 4. Check the association is there (basically I think it's there) For ipw2200, it uses old mac layer driver and driver is responsible for re-assication. Please correct me if I'm wrong.
Hello Jeff and Reinette, OK let's do an experiment: Take your laptops and connect to a non encrypted access point. Uninstall all things like networkmanager, wap_supplicant etc. We just use the commands iwconfig and ifconfig nothing else. Once you are connected check that your network connection works by using a firefox web browser. Now close the lid (or whatever you have to do to make the laptop suspend to ram). Wait 5min. Wake the laptop up. Now what does ifconfig show and what does iwconfig show? In my case it shows IP address as still configured and associated to access point. Interface is up. Note that we did not give any command nor was there any application level software involved. In other words even with iwlagn there is no need to do anything after wake-up from suspend to ram. The wifi connection still works without any daemon or application layer process. Do you agree that it is supposed to be like that? Now surf the internet and check that everything is ok. Navigate with your web browser to the web-server that is integrated into your access point. Open the page where you can change the wifi channel. Change it. The moment you do this the connection will go down but you can simply re-associate by using. iwconfig wlan1 essid "TheESSid" Verify that your network connection works again but on a different channel. Now close the lid (or whatever you have to do to make the laptop suspend to ram). Wake it up form suspend to ram. Type: iwconfig You see that you are still associated. Type: ifconfig You see the interface up and with an IP address Everything looks like it should work. Take your web browser (the one you still have open) and go to some web page. You will see it hangs. Start wireshark and look what is going-on on the interface that corresponds to your wifi connection. Reload the web page and you will see that the TCP syn is sent and a syn ACK is received from the web server (network works a bit) but that's it. No actual web page is loaded. The reason is that the "http get" packet never makes it out of your laptop despite the fact that you see it in wireshark. Now type iwconfig wlan1 essid "TheESSid" ifconfig wlan1 up Those commands should not be needed because we are still associated! ... but after giving those commands the web browsers starts to work again and the packet loss goes away. Now reboot your PC. Bring the wifi connection up, surf the web. Suspend it to ram and wake it up. You will see that it is again in this hung state where the association and interface seems up but browsing the web does not work. Now get a brand new wifi card and you will see that everything starts to work again. You can suspend to ram and wake it up as often as you like and it works always immediately.
(In reply to comment #21) > Hello Jeff and Reinette, > OK let's do an experiment: > Take your laptops and connect to a non encrypted access point. > Uninstall all things like networkmanager, wap_supplicant etc. > We just use the commands iwconfig and ifconfig nothing else. > Once you are connected check that your network connection works > by using a firefox web browser. > Now close the lid (or whatever you have to do to make the laptop > suspend to ram). > Wait 5min. > Wake the laptop up. > Now what does ifconfig show and what does iwconfig show? > In my case it shows IP address as still configured and > associated to access point. Interface is up. Note that we did > not give any command nor was there any application level software > involved. > In other words even with iwlagn there is no need to do anything > after wake-up from suspend to ram. The wifi connection still works > without any daemon or application layer process. > Do you agree that it is supposed to be like that? No, my card does not work after long suspend. See below. If I suspend for short time, like 2 seconds, the association is there and I can ping/scp. > Now surf the internet and check that everything is ok. > Navigate with your web browser to the web-server that is integrated > into your access point. Open the page where you can change the wifi > channel. Change it. > The moment you do this the connection will go down but you can simply > re-associate by using. iwconfig wlan1 essid "TheESSid" > Verify that your network connection works again but on a different > channel. > Now close the lid (or whatever you have to do to make the laptop > suspend to ram). > Wake it up form suspend to ram. > Type: iwconfig > You see that you are still associated. > Type: ifconfig > You see the interface up and with an IP address > Everything looks like it should work. > Take your web browser (the one you still have open) and go to some web page. > You will see it hangs. On my side, at the very begining of the resuming, iwconfig shows the association is there, and then will show disassociated soon without any operation (except iwconfig). > Start wireshark and look what is going-on on the interface that corresponds > to your wifi connection. Reload the web page and you will see that > the TCP syn is sent and a syn ACK is received from the web server (network > works > a bit) but that's it. No actual web page is loaded. The reason is that > the "http get" packet never makes it out of your laptop despite the fact > that you see it in wireshark. > Now type > iwconfig wlan1 essid "TheESSid" > ifconfig wlan1 up > Those commands should not be needed because we are still associated! > ... but after giving those commands the web browsers starts to work again > and the packet loss goes away. > Now reboot your PC. > Bring the wifi connection up, surf the web. > Suspend it to ram and wake it up. You will see that it is again in > this hung state where the association and interface seems up but > browsing the web does not work. > Now get a brand new wifi card and you will see that everything starts > to work again. You can suspend to ram and wake it up as often as you > like and it works always immediately. My card looks like "wrong" card as you said, so I cannot reproduce it. Do you have brand new card and it still associates to AP, ping/scp after 1 hour suspend?
Now this is truly amazing. Your laptop does not automatically re-associate. Mine does. I have now card number 3 (it is brand new and I have not changed the wifi channel since I bought it). Here is how it works. 17min suspend to ram and everything is still working. In-fact I can put it to sleep for a whole day and it will come back after suspend to ram without any application involved. Just plain driver kernel functionality. .... and you are telling me that it is not supposed to be that way. Can you get a brand new card? I have the feeling that it would work the same way for you. Here is the proof: guido@ecopad ~ $ dmesg| tail ;date;/sbin/iwconfig wlan1 [ 15.391064] usb 2-1.1: link qh8-0601/f7207200 start 2 [1/2 us] [ 68.395160] i2c-adapter i2c-2: unable to read EDID block. [ 68.395169] i915 0000:00:02.0: DVI-D-1: no EDID data [ 68.399851] i2c-adapter i2c-2: unable to read EDID block. [ 68.399859] i915 0000:00:02.0: DVI-D-1: no EDID data [ 68.530465] i2c-adapter i2c-2: unable to read EDID block. [ 68.530473] i915 0000:00:02.0: DVI-D-1: no EDID data [ 68.535134] i2c-adapter i2c-2: unable to read EDID block. [ 68.535142] i915 0000:00:02.0: DVI-D-1: no EDID data [ 180.454116] CE: hpet increasing min_delta_ns to 15000 nsec Thu Dec 3 09:18:47 EST 2009 wlan1 IEEE 802.11abgn ESSID:"sansfil" Mode:Managed Frequency:2.472 GHz Access Point: 00:0F:B5:17:42:EA Bit Rate=54 Mb/s Tx-Power=15 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=68/70 Signal level=-42 dBm Noise level=-87 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 guido@ecopad ~ $ dmesg| tail ;date;/sbin/iwconfig wlan1 [ 3547.019253] wlan1: direct probe to AP 00:0f:b5:17:42:ea try 1 [ 3547.021604] wlan1 direct probe responded [ 3547.021613] wlan1: authenticate with AP 00:0f:b5:17:42:ea [ 3547.024483] wlan1: authenticated [ 3547.024490] wlan1: associate with AP 00:0f:b5:17:42:ea [ 3547.027058] wlan1: RX ReassocResp from 00:0f:b5:17:42:ea (capab=0x431 status=0 aid=1) [ 3547.027067] wlan1: associated [ 3548.000143] hub 4-0:1.0: hub_suspend [ 3548.000160] usb usb4: bus auto-suspend [ 3548.000166] usb usb4: suspend_rh Thu Dec 3 09:35:07 EST 2009 wlan1 IEEE 802.11abgn ESSID:"sansfil" Mode:Managed Frequency:2.472 GHz Access Point: 00:0F:B5:17:42:EA Bit Rate=54 Mb/s Tx-Power=15 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=67/70 Signal level=-43 dBm Noise level=-86 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 guido@ecopad ~ $ echo "you see, we were 17min suspended to ram and after wake-up it just works. No manual interaction. No application to re-associate" you see, we were 17min suspended to ram and after wake-up it just works. No manual interaction. No application to re-associate guido@ecopad ~ $ ps auxw USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 1660 564 ? Ss 08:20 0:01 init [3] root 2 0.0 0.0 0 0 ? S< 08:20 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S< 08:20 0:00 [migration/0] root 4 0.0 0.0 0 0 ? S< 08:20 0:00 [ksoftirqd/0] root 7 0.0 0.0 0 0 ? S< 08:20 0:00 [events/0] root 9 0.0 0.0 0 0 ? S< 08:20 0:00 [khelper] root 12 0.0 0.0 0 0 ? S< 08:20 0:00 [netns] root 15 0.0 0.0 0 0 ? S< 08:20 0:00 [async/mgr] root 174 0.0 0.0 0 0 ? S< 08:20 0:00 [kblockd/0] root 177 0.0 0.0 0 0 ? S< 08:20 0:00 [kacpid] root 178 0.0 0.0 0 0 ? S< 08:20 0:00 [kacpi_notify] root 179 0.0 0.0 0 0 ? S< 08:20 0:00 [kacpi_hotplug] root 258 0.0 0.0 0 0 ? S< 08:20 0:00 [ata/0] root 260 0.0 0.0 0 0 ? S< 08:20 0:00 [ata_aux] root 261 0.0 0.0 0 0 ? S< 08:20 0:00 [ksuspend_usbd] root 266 0.0 0.0 0 0 ? S< 08:20 0:00 [khubd] root 269 0.0 0.0 0 0 ? S< 08:20 0:00 [kseriod] root 334 0.0 0.0 0 0 ? S 08:20 0:00 [pdflush] root 335 0.0 0.0 0 0 ? S 08:20 0:00 [pdflush] root 336 0.0 0.0 0 0 ? S< 08:20 0:00 [kswapd0] root 387 0.0 0.0 0 0 ? S< 08:20 0:00 [aio/0] root 403 0.0 0.0 0 0 ? S< 08:20 0:00 [nfsiod] root 407 0.0 0.0 0 0 ? S< 08:20 0:00 [crypto/0] root 429 0.0 0.0 0 0 ? S< 08:20 0:00 [pciehpd] root 1057 0.0 0.0 0 0 ? S< 08:20 0:00 [i915/0] root 1096 0.0 0.0 0 0 ? S< 08:20 0:00 [scsi_eh_0] root 1098 0.0 0.0 0 0 ? S< 08:20 0:00 [scsi_eh_1] root 1100 0.0 0.0 0 0 ? S< 08:20 0:00 [scsi_eh_2] root 1102 0.0 0.0 0 0 ? S< 08:20 0:00 [scsi_eh_3] root 1155 0.0 0.0 0 0 ? S< 08:20 0:00 [kpsmoused] root 1160 0.0 0.0 0 0 ? S< 08:20 0:00 [kondemand/0] root 1162 0.0 0.0 0 0 ? S< 08:20 0:00 [kconservative/0] root 1216 0.0 0.0 0 0 ? S< 08:20 0:00 [usbhid_resumer] root 1223 0.0 0.0 0 0 ? S< 08:20 0:00 [rpciod/0] root 1251 0.0 0.0 0 0 ? S< 08:20 0:00 [kjournald] root 1341 0.0 0.0 2132 928 ? S<s 08:20 0:00 /sbin/udevd --daemon root 2191 0.0 0.0 0 0 ? S< 08:20 0:00 [ktpacpid] root 2221 0.0 0.0 0 0 ? S< 08:20 0:00 [hd-audio0] root 2409 0.0 0.0 0 0 ? S< 08:20 0:00 [iwlagn] root 2410 0.0 0.0 0 0 ? S< 08:20 0:00 [phy0] root 4076 0.0 0.0 1876 548 ? Ss 08:20 0:00 metalog [MASTER] root 4077 0.0 0.0 1860 212 ? S 08:20 0:00 metalog [KERNEL] root 4136 0.0 0.0 1668 592 ? Ss 08:20 0:00 /usr/sbin/acpid 101 4196 0.0 0.0 2332 860 ? Ss 08:20 0:00 /usr/bin/dbus-daemon --system root 4416 0.0 0.0 3324 1620 ? Ss 08:20 0:00 /usr/bin/esound-esd -nobeeps -as 2 -tcp -public root 4475 0.0 0.0 1872 488 ? Ss 08:20 0:00 /usr/sbin/gpm -m /dev/psaux -t ps2 root 4603 0.0 0.0 4328 912 ? Ss 08:20 0:00 /usr/sbin/sshd root 4665 0.0 0.0 2372 964 ? Ss 08:20 0:00 /usr/sbin/xinetd -pidfile /var/run/xinetd.pid -stayalive -reuse root 4736 0.0 0.0 2644 1292 tty1 Ss 08:20 0:00 /bin/login -- root 4737 0.0 0.0 1704 696 tty2 Ss+ 08:20 0:00 /sbin/agetty 38400 tty2 linux root 4738 0.0 0.0 1704 700 tty3 Ss+ 08:20 0:00 /sbin/agetty 38400 tty3 linux root 4739 0.0 0.0 1704 696 tty4 Ss+ 08:20 0:00 /sbin/agetty 38400 tty4 linux root 4740 0.0 0.0 1704 692 tty5 Ss+ 08:20 0:00 /sbin/agetty 38400 tty5 linux root 4741 0.0 0.0 1704 696 tty6 Ss+ 08:20 0:00 /sbin/agetty 38400 tty6 linux guido 4754 0.0 0.0 3240 1640 tty1 S 08:21 0:00 -bash guido 4761 0.0 0.2 9760 4920 tty1 S 08:21 0:00 /usr/GNUstep/System/Tools/gdnc --daemon guido 4764 0.0 0.0 2888 1176 tty1 S+ 08:21 0:00 /bin/sh /usr/bin/startx guido 4780 0.0 0.0 3016 1092 tty1 S+ 08:21 0:00 xinit /etc/X11/xinit/xinitrc -- -auth /home/guido/.serverauth.4764 root 4781 2.3 1.6 85924 32816 tty7 Ss+ 08:21 1:47 X :0 -auth /home/guido/.serverauth.4764 -deferglyphs 16 guido 4787 0.0 0.0 2888 1124 tty1 S 08:21 0:00 /bin/sh /etc/X11/xinit/xinitrc guido 4815 0.0 0.0 2892 1184 tty1 S 08:21 0:00 /bin/sh /etc/xdg/xfce4/xinitrc guido 4823 0.0 0.0 3152 768 tty1 S 08:21 0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session guido 4824 0.0 0.0 2464 848 ? Ss 08:21 0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --sessi guido 4826 0.0 0.3 23292 6176 tty1 Sl 08:21 0:00 /usr/bin/xfce4-session guido 4828 0.0 0.0 3408 1748 ? S 08:21 0:00 /usr/libexec/xfconfd guido 4835 0.0 0.1 13276 3376 tty1 S 08:21 0:00 xfsettingsd guido 4836 0.0 0.2 24824 5848 ? Ss 08:21 0:00 kdein guido 4840 0.0 0.1 24232 2616 ? S 08:21 0:00 dcops guido 4842 0.0 0.2 26036 5216 ? S 08:21 0:00 klaun guido 4844 0.0 0.4 27564 7932 ? S 08:21 0:01 kded guido 4851 0.0 0.2 5784 3948 ? S 08:21 0:00 /usr/libexec/gconfd-2 guido 4853 0.0 0.4 16868 9656 tty1 S 08:21 0:01 xfwm4 --sm-client-id 237912b55-bb8c-4321-a81f-0e621867092f --displa guido 4855 0.1 0.6 46216 12572 tty1 S 08:21 0:06 xfce4-panel -r --sm-client-id 2b338d269-a68b-411a-a6db-573c454fa687 guido 4856 0.0 0.9 73868 19096 tty1 S 08:21 0:01 xfdesktop --sm-client-id 2c75af5cd-9d63-4978-aa94-283aba927428 --di guido 4857 0.0 0.2 15888 4252 tty1 S 08:21 0:00 xfce4-settings-helper --display :0.0 --sm-client-id 229f7b4a8-d692- guido 4859 0.0 0.0 2784 1156 ? S 08:21 0:00 /usr/libexec/gam_server guido 4863 0.0 0.2 7720 5328 tty1 R 08:21 0:00 mrxvt -xftfn Bitstream Vera Sans Mono -xft -xftsz 10 guido 4864 0.0 0.6 42552 13300 tty1 S 08:21 0:00 /usr/libexec/xfce4/panel-plugins/xfce4-menu-plugin socket_id 209715 guido 4867 0.0 0.0 3240 1668 pts/0 Ss+ 08:21 0:00 bash guido 4869 0.0 0.0 3240 1632 pts/1 Ss+ 08:21 0:00 bash guido 4871 0.0 0.0 3240 1644 pts/2 Ss+ 08:21 0:00 bash guido 4877 0.0 0.0 3240 1676 pts/3 Ss 08:21 0:00 bash guido 4879 0.0 0.0 3240 1644 pts/4 Ss 08:21 0:00 bash guido 4892 0.0 0.0 3748 1652 ? S 08:21 0:00 /usr/libexec/gvfsd guido 4899 0.0 0.5 54600 10848 tty1 Sl 08:21 0:00 /usr/libexec/xfce4/panel-plugins/xfce4-mixer-plugin socket_id 20971 guido 4900 0.4 0.4 42508 9336 tty1 S 08:21 0:18 /usr/libexec/xfce4/panel-plugins/xfce4-cpu-freq-plugin socket_id 20 guido 4901 0.0 0.4 42128 9292 tty1 S 08:21 0:00 /usr/libexec/xfce4/panel-plugins/xfce4-battery-plugin socket_id 209 guido 4908 0.0 0.2 14512 4976 ? S 08:21 0:00 /usr/bin/Thunar --daemon guido 4910 0.0 0.0 2628 1140 tty1 S 08:21 0:00 /bin/sh /opt/firefox-3.5.5/firefox guido 4913 0.0 0.0 2628 1196 tty1 S 08:21 0:00 /bin/sh /opt/firefox-3.5.5/run-mozilla.sh /opt/firefox-3.5.5/firefo guido 4917 2.7 5.7 337072 113992 tty1 Sl 08:21 2:03 /opt/firefox-3.5.5/firefox-bin guido 4958 1.2 4.8 171924 94888 tty1 S 08:22 0:53 /opt/acroread-7.0.8-1/Reader/intellinux/bin/acroread /tmp/doc2586.p guido 5133 0.0 0.0 2080 764 pts/4 S+ 09:15 0:00 rlogin flocke guido 5134 0.0 0.0 2080 280 pts/4 S+ 09:15 0:00 rlogin flocke root 5162 0.0 0.0 0 0 ? S< 09:34 0:00 [migration/1] root 5163 0.0 0.0 0 0 ? S< 09:34 0:00 [ksoftirqd/1] root 5164 0.0 0.0 0 0 ? S< 09:34 0:00 [rpciod/1] root 5165 0.0 0.0 0 0 ? S< 09:34 0:00 [kconservative/1] root 5166 0.0 0.0 0 0 ? S< 09:34 0:00 [kondemand/1] root 5167 0.0 0.0 0 0 ? S< 09:34 0:00 [i915/1] root 5168 0.0 0.0 0 0 ? S< 09:34 0:00 [crypto/1] root 5169 0.0 0.0 0 0 ? S< 09:34 0:00 [aio/1] root 5170 0.0 0.0 0 0 ? S< 09:34 0:00 [ata/1] root 5171 0.0 0.0 0 0 ? S< 09:34 0:00 [kblockd/1] root 5172 0.0 0.0 0 0 ? S< 09:34 0:00 [events/1] guido 5244 0.0 0.0 2308 908 pts/3 R+ 09:36 0:00 ps auxw guido@ecopad ~ $ dmesg| tail ;date;/sbin/iwconfig wlan1 [ 3547.019253] wlan1: direct probe to AP 00:0f:b5:17:42:ea try 1 [ 3547.021604] wlan1 direct probe responded [ 3547.021613] wlan1: authenticate with AP 00:0f:b5:17:42:ea [ 3547.024483] wlan1: authenticated [ 3547.024490] wlan1: associate with AP 00:0f:b5:17:42:ea [ 3547.027058] wlan1: RX ReassocResp from 00:0f:b5:17:42:ea (capab=0x431 status=0 aid=1) [ 3547.027067] wlan1: associated [ 3548.000143] hub 4-0:1.0: hub_suspend [ 3548.000160] usb usb4: bus auto-suspend [ 3548.000166] usb usb4: suspend_rh Thu Dec 3 09:36:43 EST 2009 wlan1 IEEE 802.11abgn ESSID:"sansfil" Mode:Managed Frequency:2.472 GHz Access Point: 00:0F:B5:17:42:EA Bit Rate=54 Mb/s Tx-Power=15 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=67/70 Signal level=-43 dBm Noise level=-88 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 guido@ecopad ~ $ ping www.google.com PING www.l.google.com (64.233.169.106) 56(84) bytes of data. 64 bytes from yo-in-f106.1e100.net (64.233.169.106): icmp_seq=1 ttl=247 time=38.5 ms 64 bytes from yo-in-f106.1e100.net (64.233.169.106): icmp_seq=2 ttl=247 time=40.1 ms 64 bytes from yo-in-f106.1e100.net (64.233.169.106): icmp_seq=3 ttl=247 time=37.7 ms ^C --- www.l.google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 37.780/38.841/40.186/1.015 ms guido@ecopad ~ $
Yes. It's amazing. Reinette/Ben, any comments?
We advocate that users rely on userspace applications (wpa_supplicant etc) for management of their associations. Since you seem to be interested in the operations without this, we can look into the details. In order to do this, could you please run with the latest code (from wireless-testing)? If you do not wish to change your kernel you can run with compat-wireless. Some more questions: - could you please provide the initialization information of both the 5300 and 5100 cards? Please do as follows: $ modprobe iwlagn debug=0x43fff $ ip link set wlanX up Please send output of dmesg for both cards. - what AP are you using? - could you please compile with CONFIG_MAC80211_VERBOSE_DEBUG When you have latest driver code we can look into the details of the associations. Load your driver with debug=0x43fff before your suspend to ram, please send log of what you see after you have resumed from suspend.
Hello Reinette, OK let's do that. I have currently a linux-2.6.31.4 kernel and I just took the latest snapshot from http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=snapshot;h=6fe27a4c7a142fe5bcc5ced404e8941e1f4f2e1d;sf=tgz I took only a tar ball of drivers/net/wireless/iwlwifi but that does not seem to be compatible with the rest of the kernel. It does not compile: drivers/net/wireless/iwlwifi/iwl-agn.c: In function 'iwl_read_ucode': drivers/net/wireless/iwlwifi/iwl-agn.c:1436: error: 'struct wiphy' has no member named 'fw_version' drivers/net/wireless/iwlwifi/iwl-agn.c:1437: error: 'struct wiphy' has no member named 'fw_version' How about this: you tell me which tar-ball to use. Send me a link to a git tar-ball/snapshot Thanks very much
You can download compat-wireless package from http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-2.6.tar.bz2 And follow the README. You don't need change your kernel with it. For wireless-testing, you need change/rebuild your kernel, and thus need pull the whole git tree and rebuild whole kernel.
Created an attachment (id=2265) [details] compat-wireless-2009-12-07, iwlagn debug=0x43fff, 5100 card that works, this case shows how it should be. First test: wifi link 5100 card that is OK and works. It re-associates automatically after wake-up from suspend to ram. System: compat-wireless-2009-12-07 module loaded with iwlagn debug=0x43fff kernel: Linux ecopad 2.6.31.4-1 #5 SMP PREEMPT Tue Dec 8 09:25:04 EST 2009 i686 Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz GenuineIntel GNU/Linux
Hello Reinette, above the debug printout form the 5100 card that re-associates automatically and works as it should. Have a look at the attached log and tell me if this is good and the way you want to have it. If you are satisfied then I will open the laptop and replace the card with a "bad" one. I don't want to swap all the time the cards as this involves opening the laptop. Ideally I would just like to swap once.
Created an attachment (id=2289) [details] card 5300: dmesg; iwconfig; iwlagn debug=0x43fff; printouts before and after suspend to ram I put the 5300 card back into the laptop. In general I must say that it is really difficult to work with a "moving target". The compat-wireless-2009-12-07 driver on top of 2.6.31.4 kernel + 5300 card does not show this packet loss problem anymore. The attached 5300.txt file shows the 5300 card and it's behavior after suspend to ram. The card does automatically re-associate and it does not show packet loss. However I must still say that the 5100 is the better card. Because I have seen now at least once that the 5300 would loose the association just in the middle of a download. ... but that is a different problem. I have the 5300 card back in the laptop for just 1 day and I would like to really use it for a week or more before giving a final judgement. Something has definitely changed in the wifi driver and it helps the 5300 card.
FYI. Reinette is on vacation now.
the main problem with certain packets not being sent out seems to be resolved in 2.6.32