Latest working kernel version: ? Earliest failing kernel version: ? Distribution: Fedora 10 Hardware Environment: Panasonic Toughbook CF-51 Software Environment: Problem Description: The system hangs during suspend to RAM. It does not matter whether any kernel modules are loaded. Suspend to disk seems to be working properly. Using the no_console_suspend test_suspend=mem boot options, the system hangs after printing: ACPI: Preparing to enter system sleep state S3 to the console. The screen, backlight, hard drive and fan all stay on. Upon rebooting and running dmesg -s 1000000 | grep "hash matches", bdi 1:12: hash matches is output. However the system clock still has the correct time. Steps to reproduce: Attempt to suspend to RAM Linux panasonic. 2.6.28.2 #2 SMP Tue Jan 27 23:35:02 EST 2009 i686 i686 i386 GNU/Linux ---------------------------------------------------------------------------- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.73GHz stepping : 8 cpu MHz : 800.000 cache size : 2048 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts est tm2 bogomips : 1596.25 clflush size : 64 power management: ------------------------------------------------------------------------------- 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 04) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4) 00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 04) 00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 04) 00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04) 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 04) 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19) 06:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa) 06:00.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa) 06:00.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 02) 06:04.0 Network controller: Intel Corporation PRO/Wireless 2915ABG Network Connection (rev 05)
Reassigned to acpi. Might be wrong. The "bdi 1:12: hash matches" thing mystifies me. What does "bdi 1:12" correspond to? A block device? Seems that way. So perhaps we died while trying to suspend a device with major 1, minor 12? That's a mad guess. Are you sure that you had CONFIG_PM_TRACE_RTC=y? Rafael, are you familiar with the pm_trace stuff, able to interpret this better? Thanks.
It seems to hang during suspend and pm_trace only works during resume. Jacob, there are a couple of things to try: 1) boot with acpi_sleep=old_ordering and see if suspend to RAM works, 2) use pm_test as described in Documentation/power/basic-pm-debugging.txt
Hi, Jacob Will you please do the test required by Rafael in comment #2? Will you please attach the output of acpidump, lspci -vxxx? Will you please add the boot option of "acpi_sleep=s3_beep" and do the following test ? a. kill the process which is using the /proc/acpi/event b. dmesg >dmesg_after; echo mem > /sys/power/state; dmesg >dmesg_after; sync; c. press the power button and see whether the system can be resumed If the system can't be resumed, please reboot the system and check whether there exists the file of dmesg_after. Thanks.
acpi_sleep=old_ordering allows the system to suspend and resume, but with many errors in the dmesg log with IRQ and device reset errors. The dmesg is without any USB devices will be attached. If I have an external USB mouse attached, when the system comes out of resume its movement is very erratic. The touchpad and keyboard are PS/2 so they seem to be ok.
Created attachment 20082 [details] dmesg suspend/resume with acpi_sleep=old_ordering; multiple errors in log
Created attachment 20083 [details] acpidump
Created attachment 20084 [details] lspci -vxxx
Hi, Jacob How about the test as mentioned in comment #3? Please don't add the boot option of "acpi_sleep=old_ordering". If there is no option of "acpi_sleep=old_ordering", the _PTS object will be executed after the device is already put into sleeping state. If it is added, the _PTS object will be executed before putting the device into sleeping state. It is very strange that the system can be resumed when adding the boot option of "acpi_sleep=old_ordering". Thanks.
Without acpi_sleep=old_ordering and with acpi_sleep=s3_beep, running dmesg > dmesg_after; echo mem > /sys/power/state; dmesg > dmesg_after; sync produces a hang during suspend, just as before without any options. The system never goes into suspend; the LCD backlight even stays on and the fan is running at full speed. The last message on the screen during the hang is that it is suspending consoles. After reboot a file dmesg_after exists, but it is the dmesg produced before the system attempts to suspend (i.e., from the first invocation of dmesg before echo).
Hi, Jacob Typo. Sorry for the wrong command. It should be dmesg >dmesg_before; echo mem > /sys/power/state; dmesg >dmesg_after; sync; Will you please re-test it again? thanks.
In this case there is a dmesg_before but no dmesg_after, which makes sense since the system never actually finishes suspending.
Thanks for the confirm. It seems that the box behaves differently if the _PTS is executed in different order. Do you have an opportunity to try it on the latest kernel?(2.6.29-rc3) Thanks.
(In reply to comment #5) > Created an attachment (id=20082) [details] > dmesg suspend/resume with acpi_sleep=old_ordering; multiple errors in log Just to clarify, which of those messages you consider as errors? And yes, please try 2.6.29-rc3 with acpi_sleep=old_ordering.
The errors: pcmcia_socket pcmcia_socket0: *** DANGER *** unable to remove socket power pcmcia_socket pcmcia_socket1: *** DANGER *** unable to remove socket power firewire_ohci: Failed to reset ohci card. PM: Device 0000:06:00.2 failed to resume: error -16 irq 23: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.28.2 #2 Call Trace: [<c0463650>] __report_bad_irq+0x2e/0x6f [<c0463780>] note_interrupt+0xef/0x14b [<c0463d02>] handle_fasteoi_irq+0x8f/0xb5 [<c0463c73>] ? handle_fasteoi_irq+0x0/0xb5 <IRQ> [<c0404618>] ? common_interrupt+0x28/0x30 [<c044007b>] ? thread_group_cputime_alloc+0x68/0xc9 [<c044790c>] ? tick_nohz_stop_sched_tick+0x2f3/0x303 [<c0402a66>] ? cpu_idle+0x26/0xa8 [<c06a92e2>] ? rest_init+0x4e/0x50 handlers: [<c05de8ba>] (usb_hcd_irq+0x0/0xa3) [<c05de8ba>] (usb_hcd_irq+0x0/0xa3) Disabling IRQ #23 I will try 2.6.29-rc3.
2.6.29-rc3 without acpi_sleep=old_ordering -> still freezes during suspend 2.6.29-rc3 with acpi_sleep=old_ordering produces the same symptoms as 2.6.28.2, and the dmesg includes the following errors: BUG: sleeping function called from invalid context at kernel/workqueue.c:440 in_atomic(): 0, irqs_disabled(): 1, pid: 2431, name: pm-suspend Pid: 2431, comm: pm-suspend Not tainted 2.6.29-rc3 #1 Call Trace: [<c04286fc>] __might_sleep+0xdf/0xe4 [<c043c6a4>] flush_work+0x1a/0x93 [<c06c2d9e>] ? _spin_unlock_irqrestore+0x22/0x38 [<c043c871>] ? __queue_work+0x26/0x2b [<c043c926>] work_on_cpu+0x3c/0x46 [<c043bf75>] ? do_work_for_cpu+0x0/0x12 [<f045144a>] ? do_drv_read+0x0/0x3e [acpi_cpufreq] [<f0451391>] get_cur_val+0x9a/0xbf [acpi_cpufreq] [<f045140a>] get_cur_freq_on_cpu+0x54/0x94 [acpi_cpufreq] [<c0626b80>] cpufreq_suspend+0x9c/0x114 [<c05a4c98>] sysdev_suspend+0x3e/0x175 [<c05a8e04>] device_power_down+0xb4/0xf0 [<c045037d>] suspend_devices_and_enter+0xcf/0x16d [<c0450570>] enter_state+0x130/0x190 [<c045065f>] state_store+0x8f/0xa2 [<c04505d0>] ? state_store+0x0/0xa2 [<c0527bc1>] kobj_attr_store+0x1a/0x22 [<c04d3a7b>] sysfs_write_file+0xb4/0xdf [<c04d39c7>] ? sysfs_write_file+0x0/0xdf [<c04973da>] vfs_write+0x84/0xdf [<c04974ce>] sys_write+0x3b/0x60 [<c04038df>] sysenter_do_call+0x12/0x34 ------------[ cut here ]------------ WARNING: at kernel/hrtimer.c:618 hres_timers_resume+0x2f/0x45() Hardware name: CF-51LCMDDBM hres_timers_resume() called with IRQs enabled!Modules linked in: i915 drm i2c_al go_bit ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ond emand acpi_cpufreq dm_multipath uinput snd_intel8x0 snd_intel8x0m snd_seq_dummy snd_ac97_codec ac97_bus snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device sn d_pcm_oss snd_mixer_oss snd_pcm snd_timer ppdev parport_pc snd soundcore yenta_s ocket snd_page_alloc i2c_i801 rsrc_nonstatic ipw2200 serio_raw firewire_ohci par port video i2c_core iTCO_wdt iTCO_vendor_support libipw sky2 pcspkr firewire_cor e crc_itu_t output lib80211 joydev ata_generic pata_acpi [last unloaded: microco de] Pid: 2431, comm: pm-suspend Not tainted 2.6.29-rc3 #1 Call Trace: [<c042e4e1>] warn_slowpath+0x71/0xa8 [<c0414740>] ? lapic_next_event+0x13/0x17 [<c044769b>] ? clockevents_program_event+0xdb/0xea [<c044848d>] ? tick_dev_program_event+0x28/0x95 [<c0448544>] ? tick_program_event+0x22/0x29 [<c0447b2e>] ? tick_notify+0x2e1/0x2f0 [<c043c21f>] ? insert_work+0x3d/0x45 [<c06c4e4c>] ? notifier_call_chain+0x2b/0x4a [<c04416ef>] hres_timers_resume+0x2f/0x45 [<c0444d3a>] timekeeping_resume+0x13c/0x142 [<c05a4b4c>] __sysdev_resume+0x14/0x38 [<c05a4b91>] sysdev_resume+0x21/0x54 [<c05a915a>] device_power_up+0xb/0x15 [<c04503b1>] suspend_devices_and_enter+0x103/0x16d [<c0450570>] enter_state+0x130/0x190 [<c045065f>] state_store+0x8f/0xa2 [<c04505d0>] ? state_store+0x0/0xa2 [<c0527bc1>] kobj_attr_store+0x1a/0x22 [<c04d3a7b>] sysfs_write_file+0xb4/0xdf [<c04d39c7>] ? sysfs_write_file+0x0/0xdf [<c04973da>] vfs_write+0x84/0xdf [<c04974ce>] sys_write+0x3b/0x60 [<c04038df>] sysenter_do_call+0x12/0x34 ---[ end trace 104058e15f9549d5 ]--- pcmcia_socket pcmcia_socket0: *** DANGER *** unable to remove socket power pcmcia_socket pcmcia_socket1: *** DANGER *** unable to remove socket power firewire_ohci: Failed to reset ohci card. pm_op(): pci_pm_resume+0x0/0x4f returns -16 PM: Device 0000:06:00.2 failed to resume: error -16 irq 23: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Tainted: G W 2.6.29-rc3 #1 Call Trace: [<c04653e6>] __report_bad_irq+0x2e/0x6f [<c0465517>] note_interrupt+0xf0/0x149 [<c0465a4d>] handle_fasteoi_irq+0x8f/0xb5 [<c04659be>] ? handle_fasteoi_irq+0x0/0xb5 <IRQ> [<c0403fac>] ? common_interrupt+0x2c/0x34 [<c0574e13>] ? acpi_idle_enter_simple+0x150/0x18b [<c0628658>] ? cpuidle_idle_call+0x60/0x94 [<c0402a23>] ? cpu_idle+0x7f/0xa0 [<c06b2116>] ? rest_init+0x4e/0x50 handlers: [<c05e441b>] (usb_hcd_irq+0x0/0xa3) [<c05e441b>] (usb_hcd_irq+0x0/0xa3) Disabling IRQ #23
Created attachment 20108 [details] dmesg 2.6.29-rc3 suspend/resume with acpi_sleep=old_ordering
Hi, We seem to have problems with cpufreq_suspend and later with hres_timers_resume on the Jake's machine: On Wednesday 04 February 2009, bugme-daemon@bugzilla.kernel.org wrote: > ------- Comment #15 from jakethompson1@gmail.com 2009-02-04 07:38 ------- > 2.6.29-rc3 without acpi_sleep=old_ordering -> still freezes during suspend > > 2.6.29-rc3 with acpi_sleep=old_ordering produces the same symptoms as > 2.6.28.2, > and the dmesg includes the following errors: > > BUG: sleeping function called from invalid context at kernel/workqueue.c:440 > in_atomic(): 0, irqs_disabled(): 1, pid: 2431, name: pm-suspend > Pid: 2431, comm: pm-suspend Not tainted 2.6.29-rc3 #1 > Call Trace: > [<c04286fc>] __might_sleep+0xdf/0xe4 > [<c043c6a4>] flush_work+0x1a/0x93 > [<c06c2d9e>] ? _spin_unlock_irqrestore+0x22/0x38 > [<c043c871>] ? __queue_work+0x26/0x2b > [<c043c926>] work_on_cpu+0x3c/0x46 > [<c043bf75>] ? do_work_for_cpu+0x0/0x12 > [<f045144a>] ? do_drv_read+0x0/0x3e [acpi_cpufreq] > [<f0451391>] get_cur_val+0x9a/0xbf [acpi_cpufreq] > [<f045140a>] get_cur_freq_on_cpu+0x54/0x94 [acpi_cpufreq] > [<c0626b80>] cpufreq_suspend+0x9c/0x114 > [<c05a4c98>] sysdev_suspend+0x3e/0x175 > [<c05a8e04>] device_power_down+0xb4/0xf0 > [<c045037d>] suspend_devices_and_enter+0xcf/0x16d > [<c0450570>] enter_state+0x130/0x190 > [<c045065f>] state_store+0x8f/0xa2 > [<c04505d0>] ? state_store+0x0/0xa2 > [<c0527bc1>] kobj_attr_store+0x1a/0x22 > [<c04d3a7b>] sysfs_write_file+0xb4/0xdf > [<c04d39c7>] ? sysfs_write_file+0x0/0xdf > [<c04973da>] vfs_write+0x84/0xdf > [<c04974ce>] sys_write+0x3b/0x60 > [<c04038df>] sysenter_do_call+0x12/0x34 > ------------[ cut here ]------------ > WARNING: at kernel/hrtimer.c:618 hres_timers_resume+0x2f/0x45() > Hardware name: CF-51LCMDDBM > hres_timers_resume() called with IRQs enabled!Modules linked in: i915 drm > i2c_al > go_bit ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 > cpufreq_ond > emand acpi_cpufreq dm_multipath uinput snd_intel8x0 snd_intel8x0m > snd_seq_dummy > snd_ac97_codec ac97_bus snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device > sn > d_pcm_oss snd_mixer_oss snd_pcm snd_timer ppdev parport_pc snd soundcore > yenta_s > ocket snd_page_alloc i2c_i801 rsrc_nonstatic ipw2200 serio_raw firewire_ohci > par > port video i2c_core iTCO_wdt iTCO_vendor_support libipw sky2 pcspkr > firewire_cor > e crc_itu_t output lib80211 joydev ata_generic pata_acpi [last unloaded: > microco > de] > Pid: 2431, comm: pm-suspend Not tainted 2.6.29-rc3 #1 > Call Trace: > [<c042e4e1>] warn_slowpath+0x71/0xa8 > [<c0414740>] ? lapic_next_event+0x13/0x17 > [<c044769b>] ? clockevents_program_event+0xdb/0xea > [<c044848d>] ? tick_dev_program_event+0x28/0x95 > [<c0448544>] ? tick_program_event+0x22/0x29 > [<c0447b2e>] ? tick_notify+0x2e1/0x2f0 > [<c043c21f>] ? insert_work+0x3d/0x45 > [<c06c4e4c>] ? notifier_call_chain+0x2b/0x4a > [<c04416ef>] hres_timers_resume+0x2f/0x45 > [<c0444d3a>] timekeeping_resume+0x13c/0x142 > [<c05a4b4c>] __sysdev_resume+0x14/0x38 > [<c05a4b91>] sysdev_resume+0x21/0x54 > [<c05a915a>] device_power_up+0xb/0x15 > [<c04503b1>] suspend_devices_and_enter+0x103/0x16d > [<c0450570>] enter_state+0x130/0x190 > [<c045065f>] state_store+0x8f/0xa2 > [<c04505d0>] ? state_store+0x0/0xa2 > [<c0527bc1>] kobj_attr_store+0x1a/0x22 > [<c04d3a7b>] sysfs_write_file+0xb4/0xdf > [<c04d39c7>] ? sysfs_write_file+0x0/0xdf > [<c04973da>] vfs_write+0x84/0xdf > [<c04974ce>] sys_write+0x3b/0x60 > [<c04038df>] sysenter_do_call+0x12/0x34 > ---[ end trace 104058e15f9549d5 ]--- > pcmcia_socket pcmcia_socket0: *** DANGER *** unable to remove socket power > pcmcia_socket pcmcia_socket1: *** DANGER *** unable to remove socket power > firewire_ohci: Failed to reset ohci card. > pm_op(): pci_pm_resume+0x0/0x4f returns -16 > PM: Device 0000:06:00.2 failed to resume: error -16 > irq 23: nobody cared (try booting with the "irqpoll" option) > Pid: 0, comm: swapper Tainted: G W 2.6.29-rc3 #1 > Call Trace: > [<c04653e6>] __report_bad_irq+0x2e/0x6f > [<c0465517>] note_interrupt+0xf0/0x149 > [<c0465a4d>] handle_fasteoi_irq+0x8f/0xb5 > [<c04659be>] ? handle_fasteoi_irq+0x0/0xb5 > <IRQ> [<c0403fac>] ? common_interrupt+0x2c/0x34 > [<c0574e13>] ? acpi_idle_enter_simple+0x150/0x18b > [<c0628658>] ? cpuidle_idle_call+0x60/0x94 > [<c0402a23>] ? cpu_idle+0x7f/0xa0 > [<c06b2116>] ? rest_init+0x4e/0x50 > handlers: > [<c05e441b>] (usb_hcd_irq+0x0/0xa3) > [<c05e441b>] (usb_hcd_irq+0x0/0xa3) > Disabling IRQ #23
Hi, Jacob Will you please do the following test on the 2.6.29-rc3 kernel? (The CONFIG_PM_DEBUG should be enabled in kernel configuration. And you had better test it with/without the option of "acpi_sleep=old_ordering") a. echo core > /sys/power/pm_test b. echo mem > /sys/power/state; dmesg >dmesg_after; c. If the system can come back, will you please attach the output of dmesg? thanks.
without acpi_sleep=old_ordering: same as before, freezes during suspend at Suspending consoles with acpi_sleep=old_ordering: gives Suspending consoles message for a few seconds, then comes back with PM: Syncing filesystems and returns to shell prompt, but the prompt is frozen. See attached dmesg.
Created attachment 20145 [details] dmesg 2.6.29-rc3 suspend/resume with acpi_sleep=old_ordering, echo core > /sys/power/pm_test
can you send the output of command 'dmidecode'? we could blacklist the system.
Created attachment 20428 [details] dmidecode output
Created attachment 20477 [details] Add the pansonic CF51 box to dmi check table to use the old suspned order Will you please try the debug patch and see whether the box can be resumed? Thanks.
patch in comment #23 applied to acpi-test (with correct spelling of Panasonic:-)
shipped in 2.6.30 merge window (2.6.29-git14) closed. commit 2a9ef8e1a856be8e526bb9b10fb98c5012f6e3f8 Author: Zhao Yakui <yakui.zhao@intel.com> Date: Wed Mar 18 16:36:25 2009 +0800 ACPI: suspend: Add the Pansonic CF51 box to the dmi check table