Bug 4390

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 ***