Bugzilla – Bug 106232
suspend fails on Toshiba A30 (snd_intel, yenta, 8139too problems)
Last modified: 2005-09-06 09:28:37 UTC
system hangs trying to suspend to disk. at hang, switching VCs is still possible for a while until the system get's completey stuck output (copied manually): (previous steps: rccardctl eject unload drivers for snd_intel8x0, pcmcia/yenta, usb_ehci powersave -U ) Stopping tasks: ===================================| Freeing memory ... done (62965 pages freed) acpi_bus-0212 [03] acput_bus_set_power : Decive is not power manageable cpufreq: suspend failed to assert current frequency is that timing core things it is. swsusp: Need to copy 21510 pages swsusp: critical section/: dopne (21595 pages copied) swsusp: Restoring Highmem cpufreq: suspend failed to assert current frequency is that timing core things it is. ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 177 PCI: Setting latency timer of device 0000:00:1e.0 to 64 ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 193 ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 20 (level, low) -> IRQ 217 (system hangs here)
Created attachment 47006 [details] hwinfo output of machine
ok, played with sysrq-t a bit: it gets stuck in suspending snd_intel8x0 removing snd* modules before calling "powersave -U" it gets stuck in "rtl8139_resume" ... next try without rtl8139 ...
(not rtl8139 but 8139too ...) backtrace of do_acpi_sleep: schedule_timeout process_timeout msleep socket_setup socket_resume pcmcia_socket_dev_resume pci_device_resume dpm_resume device_resume swsusp_write pm_suspend_disk pm_suspend_disk enter_state state_store state_store subsys_attr_store flush_write_buffer sysfs_write_file sysfs_write_file vfs_write sys_write sysenter_past_esp
ok, after "pccardctl eject" and removing pcmcia* and yenta-socket as well, I manage to suspend to disk ... now removed: snd_intel8x0 8139too yenta_socket are all of these broken ?
after resume, do_acpi_sleep hangs in "alloc_pages", I can do sysrq and switch consoles, but not type anything
Yes, it is quite possible that snd_intel, 8139too and yenta_socket are broken. We need to go after such drivers one-after-one :-(. In the meantime, our powersaved supports automatically unloading such modules. If you are using DRI (3D acceleration), you can easily add it to the "broken" list, too. Now, I'd like to know more about the "alloc_pages" hang.
what can I do to help ? unloading the drivers might be difficult, since all these are probably in use (possibly except for the sound driver) when trying to suspend. Or is powersave using some kind of "force unload" mechanism ? (and yes, of course I use dri as well ... ;)
Can you try it without 3D and those offending modules to see if base system is stable? Should be easy to do from text console. powersave should be able to unload at least sound and network just fine. Then we can debug the rest...
argh, the laptop is at home today. will try to remember to test in the evening
ok, tried without *agp* drm intelfb ... after resume still stuck (able to change consoles, type letters but no process execution sysrq-t shows this (manually copied and re-typed): io_schedule sync_page __wait_on_bit_lock sync_page __lock_page wake_bit_function do_generic_mapping_read _generic_file_aio_read file_read_actor generic_file_read generic_file_read autoremove_wake_function vfs_read kernel_read prepare_binrpm do_execve sys_execve syscall_call
hang trace provided (actually looks a bit like a deadlock, I think I saw another process backtrace pretty similar in the list)
current setting: UNLOAD_MODULES_BEFORE_SUSPEND2DISK="snd_intel8x0 usbserial ehci_hcd uhci_hcd 8139too pcmcia yenta_socket" (rest unmodified from new installation). oops camera-image to be attached.
Created attachment 48395 [details] oops screenshot was so sure I already attached this in the afternoon ...
That is not an oops, but sysrq-t output. And only few last lines of it... Can you try init=/bin/bash boot to see if it works at least with no modules at all?
even better: it works with 2.6.13-20050901172817-default from dist/kerneltest now I just have to reduce the list of modules to be unloaded again.
just suspended with a complete empty list. seems something major has been fixed.
an empty list means "use default list" If you want to unload no module at all, enter "NONE" Hopefully we never get a module with name NONE ;-)
ok, I'll try that for fun ... btw: with the vbetool hack, even suspend2ram works again.
tested both STD and STR with module lists set to "NONE" : success wow, that's fast. but for some reason the poweron acpi event catches me again on STR (system comes back up happily sees I pushed the power button (to wake it up) and does a normal shutdown ...)
(In reply to comment #19) > tested both STD and STR with module lists set to "NONE" : success cool. But don't do stupid things like (un)-plugging usb while suspended now, it might be fatal. > wow, that's fast. but for some reason the poweron acpi event catches > me again on STR (system comes back up happily sees I pushed the power > button (to wake it up) and does a normal shutdown ...) open a bug, assign to hmacht and me in cc:, this should not happen and i have not seen this for a long time. Might not be fixed for RC1 but we need to have a look at it.
the power-button problem seems not really reproducible, so we can ignore that one. I guess we can close this bug.
ok. If you hit the power-button-problem again, don't hesitate to open a bug for it :-)