| Summary: | IWL5300 - iwlagn dies on suspend/resume | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | warren coleman <warren64c> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | chainsaw, mobile+disabled |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
dmesg output
Output of emerge --info dmidecode output DMIDECODE showing latest bios dmesg with SUSPEND_MODULES=iwlagn removed |
||
|
Description
warren coleman
2010-05-25 01:29:10 UTC
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. Just putting this in NEEDINFO state for managerial reasons, poke us when you have news on this. |
