it's fujitsu siemens c-1020 laptop, running slackware-current bios version - 1.35 1. echo "standby" > /sys/power/state screen blanks, but nothing else happens. syslog contains only : Mar 23 10:49:59 is kernel: Stopping tasks: ========================| Mar 23 10:49:59 is kernel: Restarting tasks... done /var/log/acpid : [Wed Mar 23 08:39:58 2005] received event "video VGA0 00000080 00000000" [Wed Mar 23 08:39:58 2005] executing action "/etc/acpi/acpi_handler.sh video VGA0 00000080 00000000" [Wed Mar 23 08:39:58 2005] BEGIN HANDLER MESSAGES [Wed Mar 23 08:39:58 2005] END HANDLER MESSAGES [Wed Mar 23 08:39:58 2005] action exited with status 0 [Wed Mar 23 08:39:58 2005] completed event "video VGA0 00000080 00000000" 2. echo "standby" > /sys/power/state system goes to standby ok, but resuming fails. if i do this from console, it contains grey dots. if i do this from x, sometimes session is restored ok, i can move my mouse (but nothing i click on opens), sometimes it's the same garbled screen. if i do this from console, i can switch virtual consoles (if i do this, grey dots disappear) and also ctrl+l removes those dots. after resuming hdd activity light is permanently on. after some time computer shuts down itself. possibly related line in /var/log/debug : Mar 23 10:53:30 is kernel: Back to C! lines in syslog : Mar 23 10:53:30 is kernel: Stopping tasks: =========================| Mar 23 10:53:30 is kernel: hub 1-0:1.0: resubmit --> -108 Mar 23 10:53:30 is kernel: ACPI: PCI interrupt 0000:00:11.1[A]: no GSI - using IRQ 0 Mar 23 10:53:30 is kernel: uhci_hcd 0000:00:11.2: host system error, PCI problems? Mar 23 10:53:30 is kernel: uhci_hcd 0000:00:11.2: host controller halted, very bad! Mar 23 10:53:30 is kernel: Restarting tasks...<6>usb 1-1: USB disconnect, address 2 Mar 23 10:53:30 is kernel: done Mar 23 10:53:50 is kernel: hda: dma_timer_expiry: dma status == 0x21 Mar 23 10:54:00 is kernel: hda: DMA timeout error Mar 23 10:54:00 is kernel: hda: dma timeout error: status=0x58 { DriveReady SeekComplete DataRequest } Mar 23 10:55:30 is kernel: Mar 23 10:55:30 is kernel: ide: failed opcode was: unknown Mar 23 10:55:30 is kernel: hda: dma_timer_expiry: dma status == 0x21 Mar 23 10:55:30 is kernel: hda: DMA timeout error Mar 23 10:55:30 is kernel: hda: dma timeout error: status=0x58 { DriveReady SeekComplete DataRequest } Mar 23 10:55:30 is kernel: Mar 23 10:55:30 is kernel: ide: failed opcode was: unknown Mar 23 10:55:30 is kernel: hda: dma_timer_expiry: dma status == 0x21 Mar 23 10:55:30 is kernel: hda: DMA timeout error Mar 23 10:55:30 is kernel: hda: dma timeout error: status=0x58 { DriveReady SeekComplete DataRequest } Mar 23 10:55:30 is kernel: Mar 23 10:55:30 is kernel: ide: failed opcode was: unknown Mar 23 10:55:30 is kernel: hda: dma_timer_expiry: dma status == 0x21 Mar 23 10:55:30 is kernel: hda: DMA timeout error Mar 23 10:55:30 is kernel: hda: dma timeout error: status=0x58 { DriveReady SeekComplete DataRequest } Mar 23 10:55:30 is kernel: Mar 23 10:55:30 is kernel: ide: failed opcode was: unknown i can provide also output from pmtools, dmidecode or other tools, if that would help.
forgot to mention - i tried also removing all loaded modules - no difference
I think this is the USB resume bug. The USB guys are working on it.
hmm, or mabye not. I've asked the USB guys.
in this case an usb mouse was attached to the computer, but symptoms are the same without any peripherals attached.
Is this problem still present in 2.6.12-rc5?
unfortunately i don't have this laptop right now - i'll try to get it and test as soon as possible
Without USB, does the system work? I suppose it's an IDE bug. IDE drivers didn't invoke some ACPI methods. IIRC, the IDE bug impact many systems.
it still fails with 2.6.11.11; i tried to patch it up to .12-rc6, but patch failed on a lot of files (detecting reversed or previously applied files) and the result did not compile at all. this might be ide related, as hdd activity light is permanently on after attempted resume. it seems that there is an usb problem, too (though it is not related to the hang when resuming) : after resume attempt mouse works if touchpad is used, but usb mouse doesn't work. if it is replugged, it works (for a short while, until hardlock). this probably is usb resume problem that andrew mentioned, right ?
still reproducible with 2.6.12 (both with and without usb peripherals)
please verify that this is still an issue with 2.6.13
umm, www.kernel.org lists only 2.6.13-rc6 2005-08-07 18:45 i could try patching, but as i was unsuccessful last time, i'm not sure i will succeed. to which kernel am i supposed to apply this one : http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.13-rc6.bz2 ?
It applies to 2.6.12 Did you try sleep to mem ever (echo "mem" > /sys/power/state)?
1. looking at my initial report i wonder wether i have written something wrong - maybe first point was issuein "mem" instead of "standby" - but i'm not sure anymore. with 2.6.12, puttin "mem" in states results in same symptoms as standby - at resuming initial picture is painted, then screen goes blank with random grey circles appearing, then computer shuts down. 2. 2.6.13-rc6 patch applied without any errors, but compiling resulted in an error. i'll attach output. should i file this as a separate issue or is this a known problem ?
Created attachment 5665 [details] 2.6.13-rc6 compiling output
tested with 2.6.13, results are the same
>Mar 23 10:55:30 is kernel: ide: failed opcode was: unknown Did you still see the ide error with 2.6.13 after resume?
seems that actually behaviour has changed significantly enough - so i'll put complete results again here. -------------- echo "standby" /sys/power/state -------------- /var/log/syslog Sep 5 10:45:18 is kernel: Stopping tasks: ==========================================| Sep 5 10:45:18 is kernel: acpi_pm_prepare does not support 1 Sep 5 10:45:18 is kernel: Restarting tasks... done -> basically nothing happens, screen simply refreshes once -------------- echo "mem" /sys/power/state -------------- /var/log/debug Sep 5 10:47:03 is kernel: Back to C! Sep 5 10:47:03 is kernel: PCI: Setting latency timer of device 0000:00:01.0 to 64 /var/log/messages Sep 5 10:47:03 is kernel: ACPI: PCI interrupt for device 0000:00:11.5 disabled Sep 5 10:47:03 is kernel: ACPI: PCI interrupt for device 0000:00:11.4 disabled Sep 5 10:47:03 is kernel: ACPI: PCI interrupt for device 0000:00:11.3 disabled Sep 5 10:47:03 is kernel: ACPI: PCI interrupt for device 0000:00:11.2 disabled Sep 5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKA] -> GSI 9 (level, low) -> IRQ 9 Sep 5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:0a.1[B] -> Link [LNKB] -> GSI 9 (level, low) -> IRQ 9 Sep 5 10:47:03 is kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 Sep 5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.2[D] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10 Sep 5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.2[D] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10 Sep 5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.3[D] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10 Sep 5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.3[D] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10 Sep 5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.4[D] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10 Sep 5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.4[D] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10 Sep 5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 Sep 5 10:47:03 is init: Switching to runlevel: 0 Sep 5 10:47:19 is exiting on signal 15 /var/log/syslog Sep 5 10:47:03 is kernel: Stopping tasks: ===========================================| Sep 5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.1[A]: no GSI Sep 5 10:47:04 is kernel: Restarting tasks... done Sep 5 10:47:11 is nmbd[1685]: [2005/09/05 10:47:11, 0] nmbd/nmbd.c: terminate(56) Sep 5 10:47:11 is nmbd[1685]: Got SIGTERM: going down... Sep 5 10:47:11 is rpc.statd[1664]: Caught signal 15, un-registering and exiting. Sep 5 10:47:11 is rpc.mountd: Caught signal 15, un-registering and exiting. Sep 5 10:47:12 is kernel: nfsd: last server has exited Sep 5 10:47:12 is kernel: nfsd: unexporting all filesystems -------------------- so, it seemed that the system was shutting down normally, just the screen was garbled. then i modified /etc/acpi/acpi_handler.sh and commented out action for power button (runlevel 0) - probably it was receiving event from the power button when i tried to resume from sleep state ? after this modification, computer did not shutdown (though there still bere those circles on the screen) and capslock & scrollock leds were flashing simultaneously. what seemed strange, there was no indication in any of the logfiles about anything related to this action. i'll attach lspci output as there are a lot of pci references here, maybe that helps somehow.
Created attachment 5898 [details] lspci output
>probably it was receiving event from the power button when >i tried to resume from sleep state ? Yes, exactly. This is a good news. Is there any device working after resume? Such as network card?
>Sep 5 10:45:18 is kernel: acpi_pm_prepare does not support 1 This basically means your system doesn't support 'standby'.
heh. it seems that it is working after resume, only screen shows nothing. i can ssh into it, run commands. if i switch to another local virtual console and login, i can see that login has succeeded (in ssh session, of course as screen goes blank after console switching). i can also switch back to original console which still contains circles. to test this, i had gone into runlevel 3. after resuming i tried going to runlevel 4 (x)... it worked and display was resumed. virtual consoles still were blank. when i tried to log in kde, it stopped loading at the step "initializing system services". ok. it did not stop. it just took a long time (couple of minutes in this step) and now i have a working desktop after resuming from "mem" state. virtual consoles still are blank, logfiles contain nothing new. ... mid air collision :) but it is ok if /sys/power/state lists standby, mem and disk - it just lists available states, not the ones available to current hardware, right ? if so, how can other softare that manages states (for example, klaptopdaemon) detect which states are available, so unavailable states are not shown in it's menu ?
Great, looks you only have video issue. >so unavailable states are not shown in it's menu ? I'll look at it.
so, this is a problem with vesa framebuffer driver. after resuming console is unusable, xwin works ok.
>so unavailable states are not shown in it's menu ? This one has been fixed. The video issue is duplicate. *** This bug has been marked as a duplicate of 2439 ***