I cannot get the IWL5300 wireless card to suspend/resume properly either to RAM or to disk. I have tried a variety of kernels: vanilla-sources-2.6.32 and 2.6.34 and use the latest iwl5000-ucode. I can get the driver to work if I unload and reload the module after resuming. I have tried adding a SUSPEND_MODULES=iwlagn to /etc/pm/sleep.d/o1iwlagn Reproducible: Always Steps to Reproduce: 1.Suspend either to disk or RAM 2.resume 3.wireless card is hung and you have to reload the module
Problem occurs on Lenovo T400 ThinkPad
Please provide us a full dmesg output when you resume your computer Plus I would like to know which script/program you use to suspend your computer Thank you
emerge --info is missing, as well as dmesg output. I can only support you on 2.6.34, not anything older. I also need your dmidecode output for the ThinkPad. Until such information is provided, this bug report is not useful to me. Thanks.
Created attachment 232859 [details] dmesg output
Created attachment 232861 [details] Output of emerge --info Emerge --info output in file emerge.info
Created attachment 232867 [details] dmidecode output
You are not on the newest available BIOS, which is 7UUJ42US dated 2010/04/20 (you are on 7UET81WW dated 2009/11/26). I have linked the relevant update in the URL field of this bug. Should you want to retrace my steps, your machine is: ThinkPad T400 2764-CTO You have an IEEE1394-equipped model and by my calculations, you are 3 BIOS versions behind. This is not a supportable situation.
Created attachment 232925 [details] DMIDECODE showing latest bios Bios now latest version all symptoms persist
(In reply to comment #8) > Created an attachment (id=232925) [details] > DMIDECODE showing latest bios Confirmed, thank you.
(In reply to comment #4) > Created an attachment (id=232859) [details] > dmesg output The odd thing here is that no "iwlagn" device is touched. So it is neither turned off nor back on. Perhaps you already unloaded the driver here? To see any failure to suspend or resume, it is best if you leave the driver loaded for your dmesg trace.
Created attachment 232971 [details] dmesg with SUSPEND_MODULES=iwlagn removed I have tried it with the iwlagn module suspended in /etc/pm/sleep.d Now see dmesg with the module left in place. The behavior is slightly different in that the iwlagn LED now blinks but still no Internet via a browser without a reload. Strangely you CAN ping an ip address on the Internet via console and also ping using a domainname via a console but no Internet access via a browser until reload of module
(In reply to comment #11) > Strangely you CAN ping an ip address on the Internet via console and also ping > using a domainname via a console but no Internet access via a browser until > reload of module That seems like a userland problem, particularly it seems like NetworkManager gets confused about state. Do your browsers & mail clients fall into "off-line mode" and refuse to load any content by chance? This would fit the "console works fine, GUI problematic" behaviour that you describe.
(In reply to comment #12) > (In reply to comment #11) > > Strangely you CAN ping an ip address on the Internet via console and also ping > > using a domainname via a console but no Internet access via a browser until > > reload of module > > That seems like a userland problem, particularly it seems like NetworkManager > gets confused about state. Do your browsers & mail clients fall into "off-line > mode" and refuse to load any content by chance? > This would fit the "console works fine, GUI problematic" behaviour that you > describe. > Yes, I would agree a GUI problem if the basic network function runs in console mode properly. How to diagnose problem with KDE and iwlagn?
(In reply to comment #13) > Yes, I would agree a GUI problem if the basic network function runs in console > mode properly. How to diagnose problem with KDE and iwlagn? I believe there is a knetworkmanager applet that sits in the tray, or can be accessed through the menus. It would be worth knowing what that reports. Failing that, you could try nm-tool in a terminal before & after suspending and diff the two outputs.
(In reply to comment #14) > (In reply to comment #13) > > Yes, I would agree a GUI problem if the basic network function runs in console > > mode properly. How to diagnose problem with KDE and iwlagn? > > I believe there is a knetworkmanager applet that sits in the tray, or can be > accessed through the menus. It would be worth knowing what that reports. > > Failing that, you could try nm-tool in a terminal before & after suspending and > diff the two outputs. > (In reply to comment #14) > (In reply to comment #13) > > Yes, I would agree a GUI problem if the basic network function runs in console > > mode properly. How to diagnose problem with KDE and iwlagn? > > I believe there is a knetworkmanager applet that sits in the tray, or can be > accessed through the menus. It would be worth knowing what that reports. > > Failing that, you could try nm-tool in a terminal before & after suspending and > diff the two outputs. > OK so I thought it was a GUI-land problem EXCEPT ssh fails in console mode after I suspend/resume. I reload the module and voila ssh works again in console. I could do a hack to the suspend/resume script I think to reload the module after resume but that is not the right way.
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > Yes, I would agree a GUI problem if the basic network function runs in console > > > mode properly. How to diagnose problem with KDE and iwlagn? > > > > I believe there is a knetworkmanager applet that sits in the tray, or can be > > accessed through the menus. It would be worth knowing what that reports. > > > > Failing that, you could try nm-tool in a terminal before & after suspending and > > diff the two outputs. > > > > (In reply to comment #14) > > (In reply to comment #13) > > > Yes, I would agree a GUI problem if the basic network function runs in console > > > mode properly. How to diagnose problem with KDE and iwlagn? > > > > I believe there is a knetworkmanager applet that sits in the tray, or can be > > accessed through the menus. It would be worth knowing what that reports. > > > > Failing that, you could try nm-tool in a terminal before & after suspending and > > diff the two outputs. > > > > OK so I thought it was a GUI-land problem EXCEPT ssh fails in console mode > after I suspend/resume. I reload the module and voila ssh works again in > console. I could do a hack to the suspend/resume script I think to reload the > module after resume but that is not the right way. > One more tidbit, ntpdate -b command DOES work after suspend/resume even though ssh does not, so apparently some low level network functions do work while more complex functions like ssh do not.
related? https://bugzilla.kernel.org/show_bug.cgi?id=15164
Just putting this in NEEDINFO state for managerial reasons, poke us when you have news on this.
