Description of problem: Now I'm running kernel-2.6.18-138.el5.jwltest.84.x86_64 on Thinkpad T400. Sometimes when suspending from Power Manager the suspend does not work. It stops to "Disabling non boot CPUs..." and after waiting a while, a minute maybe, I see: iwlagn: No space for Tx iwlagn: Error sending REPLY_STATISTICS_CMD: enqueue_hcmd failed: -28 and the computer just hangs there. The message did appear before on occasions I did not make note of but I'm wondering if it causes the suspend to not work properly. The suspend seems to work better if WLAN is disabled from the switch. Version-Release number of selected component (if applicable): How reproducible: Suspend from Power Manager. WLAN on with some traffic? Steps to Reproduce: 1. 2. 3. Actual results: Sometimes hangs to "Disabling non boot CPUs..." Expected results: Goes to suspend Additional info:
Can you post the output of 'lspci -n' please?
Created attachment 342282 [details] lspci -n output Attached is the lspci -n command output. Actually I haven't seen this anymore since I upgraded to kernel-2.6.18-140.el5.x86_64 It was not happening all the time before the upgrade. I'll keep an eye for it for a while.
I'm going to close this based on comment 2. Please reopen if the problem persists with current kernels from here (or the actual RHEL 5.4 release kernel): http://people.redhat.com/dzickus/el5/
Suspending was working somehow till 2.6.18-164 Now with 2.6.18-164.2.1 first or second or third suspend crashes. If I disable wlan from the switch I can suspend as many times I want. So the wlan and suspend problems are definitely related. The only clue is still this message which appears after a while: iwlagn: No space for Tx iwlagn: Error sending REPLY_STATISTICS_CMD: enqueue_hcmd failed: -28 Also, without the wlan on suspending is faster. When wlan is on it takes more time to suspend, looks like it is moving in slow motion.
I noticed that I get these in the syslog when computer is connected to wlan (wlan disconnects by itself sometimes): BUG: warning at include/../net/mac80211/rate.h:153/rate_lowest_index() (Not tainted) Call Trace: [<ffffffff882f7784>] :iwlagn:rs_get_rate+0x176/0x1b2 [<ffffffff882263a2>] :mac80211:rate_control_get_rate+0x85/0xe5 [<ffffffff8822b360>] :mac80211:ieee80211_tx_h_rate_ctrl+0x31/0xfa [<ffffffff8822bf5e>] :mac80211:ieee80211_master_start_xmit+0x226/0x3fc [<ffffffff80239147>] __qdisc_run+0x136/0x1f9 [<ffffffff8002f9cb>] dev_queue_xmit+0x150/0x271 [<ffffffff882256f1>] :mac80211:ieee80211_sta_work+0x50f/0x720 [<ffffffff882251e2>] :mac80211:ieee80211_sta_work+0x0/0x720 [<ffffffff8004d80f>] run_workqueue+0x94/0xe4 [<ffffffff8004a057>] worker_thread+0x0/0x122 [<ffffffff8009f9f5>] keventd_create_kthread+0x0/0xc4 [<ffffffff8004a147>] worker_thread+0xf0/0x122 [<ffffffff8008c3c2>] default_wake_function+0x0/0xe [<ffffffff8009f9f5>] keventd_create_kthread+0x0/0xc4 [<ffffffff8009f9f5>] keventd_create_kthread+0x0/0xc4 [<ffffffff8003298b>] kthread+0xfe/0x132 [<ffffffff8005dfb1>] child_rip+0xa/0x11 [<ffffffff8009f9f5>] keventd_create_kthread+0x0/0xc4 [<ffffffff8003288d>] kthread+0x0/0x132 [<ffffffff8005dfa7>] child_rip+0x0/0x11
Please also make sure you have the lastest available firmware package for your wireless device. Also, please try the test kernels here: http://people.redhat.com/linville/kernels/rhel5/ Do these kernels work better for you?
Ok, The wlan part seems to work faster and better. Waking up from suspend sometimes freezes with kernel-2.6.18-175.el5.jwltest.96.3.x86_64 and latest v2 firmware. The trouble of going in to suspend seems to have gone away.
I have got also couple of kernel panics when waking up from suspend.
Any chance to get a logs (serial console, netconsole, kdump) when kernel do resume and crash ?
Maybe if you send a link to instructions howto use netconsole or kdump
Sure Kdump: http://kbase.redhat.com/faq/docs/DOC-6039 Don't know about RHEL netconsole howto, here is fedora doc: https://fedoraproject.org/wiki/Netconsole Easiest way to setup netconsole on RHEL is edit /etc/sysconfig/netconsole file and run "/etc/init.d/netconsole start". I'm not sure if such debugging options will be useful, it depends if proper subsystems initialize before kernel resume crash. Please let as know.
I'm sorry, I can't find time to debug this...
As of kernel-2.6.18-194 the suspend bug when wireless network is on seems to have been fixed.
I glad this is fixed (please reopen if not). Thanks.