Bug 1877

Created attachment 1864 [details]
dmesg

Created attachment 1865 [details]
acpidmp

Created attachment 1866 [details]
dmidecode

Created attachment 1867 [details]
interrupts

Created attachment 1868 [details]
lspci

     osl-0885 [8337] os_wait_semaphore     : Failed to acquire semaphore
[df6de500|1|0], AE_TIME
     osl-0885 [8420] os_wait_semaphore     : Failed to acquire semaphore
[df6eef60|1|0], AE_TIME
     osl-0885 [8416] os_wait_semaphore     : Failed to acquire semaphore
[df6eef60|1|0], AE_TIME
     osl-0885 [8462] os_wait_semaphore     : Failed to acquire semaphore
[df6eef60|1|0], AE_TIME


these don't look good.

BTW. what video driver are you using?
also, can you get rid of pnp, or does it actually do something useful?

how can you tell the kbd is not working if video is out -- can you look for 
keyboard interrupts?

thanks,
-Len

osl-0885 [8462] os_wait_semaphore     : Failed to acquire semaphore 
[df6eef60|1|0], AE_TIME 
 
I get quite a few of these, what do they mean? 
 
Video driver: i810 (also fails without X, just console)  
I've gotten rid of pnp ... screen still dead on resume 
 
sorry, I've been a bit sloppy - the keyboard and mouse DO work after a resume: 
running off the console only, sleep and resume, then from a LAN connection to 
the machine: 
"cat -r /dev/mouse" DOES register mouse events,  and typing "logger hello" on 
the keyboard 
DOES show up in syslog.  I have an external keyboard and mouse at work, driven 
via usb, and 
these are dead on resume. I haven't investigated kicking usb in some way.   
 
I've attached the output of /var/log/messages (all my syslog goes there) the 
command I executed was: 
 
logger S3 in ; echo 3 >| /proc/acpi/sleep; logger S3 out 
 
after the  resume I typed "logger hello" on the keyboard a couple of times  
these tags make it easy to spot the timing of events. I've also attached  
output of dmesg after the above. In both there's interesting messages about 
method execution failures. 
 
on the LAN connection after the resume you get (copied by hand): 
--- 
Message from syslogd@qubit at Mon Jan 11:17:57 2004 ... 
qubit kernel: MCE: The hardware reports a non fatal, correctable incident 
occured on CPU 0. 
 
Message from syslogd@qubit at Mon Jan 11:17:57 2004 ... 
qubit kernel: Bank 1: f200000000000111 
--- 
 
Hope all this helps 
 
Alexei 
 

Created attachment 1901 [details]
/var/log/messages after sleep-resume

Created attachment 1902 [details]
dmesg after sleep-resume

Do you want more info?  I have the exact same results on a Shuttle K41G.  The machine goes to sleep, but only partially wakes up (no keyboard, monitor or network) but the drives spin up.   Did this work better in 2.5?  I've also installed the latest APCI patches.

Created attachment 1937 [details]
dmesg output of same problem on ASUS M2N

The same problem can be found on an ASUS M2N. 
Here is the dmesg output of that.

When trying to get/set the LCD display via special device
/proc/acpi/asus/lcd, dmesg shows lines like

 Asus ACPI: Error reading LCD status
 Asus ACPI: Error switching LCD

Both laptops are centrino machines with Intel 855GM chipsets,
it seems. Could this be a problem of the intel810/830 graphics 
driver(s)?

Created attachment 1938 [details]
demidecode ASUS M2N

Created attachment 1939 [details]
lspci -vv ASUS M2N

Created attachment 1940 [details]
acpidmp ASUS M2N

Same problem on Debian unstable and ASUS M3410C (M3N, Intel 855GM, report at
http://luca.pca.it/projects/asus/m3410c.php)

More details at
http://sourceforge.net/mailarchive/forum.php?thread_id=3676335&forum_id=6102

I attached my DSDT (in raw format from 'cat /prco/acpi/dsdt > dsdt.raw')

Created attachment 1941 [details]
ASUS M3410C (M3N DSDT in raw format

from 'cat /proc/acpi/dsdt > dsdt.raw'

     osl-0885 [382936] os_wait_semaphore     : Failed to acquire
semaphore[df73e5a0|1|0], AE_TIME
     osl-0885 [382945] os_wait_semaphore     : Failed to acquire
semaphore[df73e5a0|1|0], AE_TIME
     osl-0885 [382954] os_wait_semaphore     : Failed to acquire
semaphore[df73e5a0|1|0], AE_TIME

same here on an ASUS M3410C (M3N), reported in:

- ACPI-devel
http://sourceforge.net/mailarchive/forum.php?thread_id=3337095&forum_id=6102

- ACPI-support (old)
http://sourceforge.net/mailarchive/forum.php?thread_id=3282131&forum_id=7803

This seems a common problem for a lot of ASUS Centrino users (but strangely,
AFAIK not for all).

> This seems a common problem for a lot of ASUS Centrino users (but strangely,
AFAIK not for all).

I've also not had it on an ASUS M2400E, but that is no Centrino and has a SiS
chipset. In fact, on that machine suspend to ram and suspend to disk work perfectly.

Q: Are we sure that the ones that have not seen the problem really have an ASUS
Centrino with Intel 855GM? And if so: Which BIOS and DSDT? Maybe we can narrow
down the problem further. 

Since it happens also on Panasonic with Intel 855GM, it really reeks of being a
chipset-related issue.

> I've also not had it on an ASUS M2400E, but that is no Centrino and has a SiS
> chipset. In fact, on that machine suspend to ram and suspend to disk work
> perfectly.
So you experienced the same 'osl' problems on a non-Centrino ASUS laptop, right?

> Q: Are we sure that the ones that have not seen the problem really have an 
> ASUS Centrino with Intel 855GM? And if so: Which BIOS and DSDT? Maybe we can
> narrow down the problem further. 
Because of my report installing Debian on the M3410C (the link reported in my
first post), I got some mails about users with the same family notebook (M3N)
and the same 'osl' problem. I can search in my mailbox for them, if it could be
useful, but anyway the problem is always the same: message repeated again and
again and again in the 'dmesg' (or in console), with sometimes the fan turning
on and the keyboard not responding for 2/3sec.

> Since it happens also on Panasonic with Intel 855GM, it really reeks of being a
chipset-related issue.
Well, this could be, but I noticed a strange fact: with my old BIOS (0203A), I
got only the 'osl' problems, not the other one related to ALSA I saw Georg also
have, this one:
=====
codec_write 0: semaphore is not ready for register 0x26
codec_semaphore: semaphore is not ready [0xff][0xffffffff]
codec_write 0: semaphore is not ready for register 0x0
codec_semaphore: semaphore is not ready [0xff][0xffffffff]
=====

This problem first occurred when I upgraded my BIOS to lastest 0205A version. I
saved the old BIOS, so I could make some deeper tests, if needed.

1) are the 2 problems related?
2) could it/they be due to the video chipset?

 >> I've also not had it on an ASUS M2400E, but that is no Centrino and has a SiS
 >> chipset. In fact, on that machine suspend to ram and suspend to disk work
 >> perfectly.

 > So you experienced the same 'osl' problems on a non-Centrino ASUS laptop, right?

No. Plain vanilla 2.6.1 works pretty much perfectly on that laptop (ASUS M2400E:
Mobile Pentium 4, SiS chipset). Suspend to RAM & DISK both seem to work reliably
and as often as one cares to use them...


> This problem first occurred when I upgraded my BIOS to lastest 0205A version.

Hm. Did you ever contact ASUS about that issue? Is there maybe some BIOS update
coming?

I saw on 

 http://www.asus.it/support/download/item.aspx?ModelName=M2N&Type=Latest

that ASUS is offering a M2N BIOS 2.06. But only for DOS, which I don't have. So
how do I update?

Just checked. I seem to have the latest BIOS already.

But in case someone wondered: http://www.nenie.org/misc/flashbootcd.html

Possibly related to

http://bugzilla.kernel.org/show_bug.cgi?id=1688 ?

> Hm. Did you ever contact ASUS about that issue? Is there maybe some BIOS
> update
> coming?
No, never and I'm quite stupid for this: the first time I should contact it, but
I always told 'tomorrow'... I'll contact ASUS later in the day.

> [...] but anyway the problem is always the same: message repeated again and
> again and again in the 'dmesg' (or in console), with sometimes the fan
> turning
> on and the keyboard not responding for 2/3sec.
Again, I'm a bit stupid: now I remember that when I tried Konami's 'Pro
Evolution Soccer 3' demo on XP-Pro-SP1, I suffers of slowdowns and fan turning
on for 2/3sec (actually the game wasn't unplayable). AFAIK I don't remember
other similar problem on XP. IMHO this means that this bug isn't related to
Linux kernel or ACPI sleep states, but a bug in the BIOS graphic section, am I
right?

Created attachment 1966 [details]
dmesg from Acer TM240

Created attachment 1967 [details]
dmedecode from Acer TM240

Created attachment 1968 [details]
interrupts from Acer TM240

Created attachment 1969 [details]
lspci from Acer TM240

Hi,
I have exactly the same problem (after resume from S3 keyboard,
net, touchpad ... work but the screen is blank).
I've got Acer TravelMate 243LC, with Intel's 82852/855GM graphics chipset.



Also problems with:
...
AC'97 warm reset still in progress? [0xffffffff]
codec_semaphore: semaphore is not ready [0xff][0xffffffff]
codec_write 0: semaphore is not ready for register 0x26
...

I have attached dmesg, dmidecode, interrupts and lspci
hope it helps you

Jozef Vesely
vesely@gjh.sk

Hi 
have a look at this, I think it is retty similar to our problem ...

Intel

I have an IBM Thinkpad R50P (the same Intel chipset as above). When I resume 
from S3, I have a blank screen. BUT - I can still interact, can even start X 
normally. A switch (Ctrl+Alt+F1..6) does not work though. (Using APM, 
everything works ok) Symptoms seen under both 2.6.1, 2.6.2-rc2-mm1. Help. 

Created attachment 2062 [details]
Report about current (2.6.3-rc1) situation of the problem

I tried to see whether anything has changed. 

The number of errors seemed to go down somewhat, but the main 
phenomenon didn't change, although the keyboard worked (contrary 
to the main description of the bug).

Update report on current (2.6.3-mm3): 
 
I am still encountering the same problem symptoms with this kernel. Console 
remains blank - input is still accepted - X starts normally. 
 
The MCE "non-fatal" errors is unrelated. (Search for non-fatal/Dave Jones/MCE 
in kernel archives). 
 
I would like to know if anyone/everyone else is using the framebuffer console 
driver or just plain text vga console?   

Partial sucess! S3 resume on my Panasonic W2 (centrino, 855GM) will work under 
the following: kernel 2.6.1 or 2.6.3 running XFree86 4.4 and VESA driver. Upon 
resume, hitting Ctr-Alt-F8, Ctr-Alt-F7 will revive the screen.  
 
This doesn't work with the i810 X driver, or on the console. I didn't try 
previous versions of X for this. Also upon resume the network card seems dead, 
and a reboot will hang the machine (I haven't explored these in too much 
detail). 

Good work Alexei!
it works for me on Acer TM240 now too

kernel: success with both 2.6.0-test11 and 2.6.3-rc4
X: 4.4.0 vesa driver, 4.3.0 vesa driver works also

Works:
net, keyboard,  _X_ (after Ctr-Alt-F8, Ctr-Alt-F7)

Does not work:
* USB has to be disabled
   hang up while resuming otherwise, I don't understand it
   "worked" (did not hang) some time ago, but I do not have the
   config anymore :-(

* No console, (neither vesafb, nor normalvga)
   I can login, but all I see is blank screen
   (with cursor flashing in the corner under normalvga)

* No sound
   just lot of:
        codec_semaphore: semaphore is not ready [0xff][0xffffffff]
        codec_write 0: semaphore is not ready for register 0x6
        codec_semaphore: semaphore is not ready [0xff][0xffffffff]
        codec_read 0: semaphore is not ready for register 0x6
   messages in kernel log

* No shutdown or reboot
    hangs just before switching the power off, repeated
    suspend to mem works OK

* Restart of X
    only blank screen after X restart

BTW: I have contacted Intel about this issue, but with no 
usefull outcome yet (they escalated the issue the engeneering
department ... :-) )

Jozef Vesely
vesely@gjh.sk

hello everybody,

I have some new information:

kernel 2.6.7
vesafb console
X.org xserver (probably same with xfree 4.4.0 and last xfree 4.3)
vesa X driver

after suspending form X, resume still results in dead screen, but
after switching to console, it is brought to life and you have both
working console and X

vesa X driver saves state of the graphic card at startup, and
restores it every time you switch to console and that is what
brings screen to life. If you add something like:

static Bool VESAEnterVT(int scrnIndex, int flags){
    ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
+   VESASaveRestore(xf86Screens[scrnIndex], MODE_RESTORE);

into the X vesa driver, it restores that saved state also before
switching back to X, so after resume there is no need to swith to
console and back.
(something similar may work for also for i810 driver, I have not tried)

I would like to have a kernel module to respond to power
managemnet callbacks by saving and restoring the state of
graphic card. This would work even without vesafb and
vesa X driver (it does not supports acceleration :-( ) or
without X at all. Therefore I investigated further about
how to save and restore the graphic state.


VESA X driver does it by making a bios call. I am not sure, 
but I suppose something like that is not possible even in 
kernel. (X server has built in emulator to do this). This 
call however could be disassembled to find out what it does.


Another way is to look into the documentation:
i810 Programmer's Reference Manual:
ftp://download.intel.com/design/chipsets/manuals/29802601.pdf

There is a chapter about saving and restoring of graphic state.
I tried to folow those instructions but I did not manage to bring
screen to life. (Error was probably on my side.)

Last thing I tried was watching video cards registers that change
between suspend and resume and do not change during normal operation.
After resume I restored them to the values before suspend.

I have seen all sorts of flickering and garbled display, but
finaly I have found the proper set of registers to restore.
(this method also worked with i810 X driver)

I definitely can not recomend this to you, but at least I have
confirmed that our dead screen problem is caused by graphic
state not being restored on resume.

I will try to disassenble the bios call as well as understand
the documentation during the summer vacation (exam period now in 
progress :-(). However it would be great if somebody with 
more experience (maybe i810 X/kernel driver autor) could look on it.

goodbye

Jozef Vesely
vesely@gjh.sk

Same behaviour on a Samsung X05 ("centrino" platform)- vesa X driver allows for
proper resume, while i810 driver doesn't

Possibly this driver: http://www.xfree86.org/~dawes/intelfb.html needs to be
ported to 2.6. and suspend/resume capability [and proper LCD / i2c handling]
added... anyone?

Created attachment 3558 [details]
Results of my investigation

I have attached reults of my "investigation".
Don't be happy it is highly experimental and I do not 
recomend you to use it. On the other hand I would be grateful
if you sent me your improvements, ideas and comments about it.

README from attached archive:

How does it work:
 There is an arbitrary list of ports that are saved and
 restored without any idea about what they mean, what bits
 are reserved, or how they should be used.

 That is enough to switch the screen on and X i810 driver can
 handle the rest.

 The shape of mouse cursor stops changing (pointer, text
 cursor, hours, resize arrow ...), and the video overlay
 is not working (stays blue). To solve it switch to console
 and back or use vesa_helper.

 While switching between X and console, the garbage appears
 on the screen (approx for 1 sec). (I have some idea how to
 change X driver to avoid this, but I am not sure)

 If you want to resume the console (vesafb) you have to
 switch to X and back or use vesa_helper

vesa_helper:
 Vesa bios call needs to be made to set the video mode.
 However it can not be made from kernel. (Really?)
 Therefore usermode helper program is used to do it.

 It may _cause hang on resume_ if vesa_helper is not in
 memory, therefore call it (it is harmless without
 parameters) before going to sleep.
 I know it is annoying, I need to solve this somehow.

vesa_helper:
 Vesa bios call needs to be made to set the video mode.
 However it can not be made from kernel. (Really?)
 Therefore usermode helper program is used to do it.

 It may _cause hang on resume_ if vesa_helper is not in
 memory, therefore call it (it is harmless without
 parameters) before going to sleep.
 I know it is annoying, I need to solve this somehow.
Why module and not userspace:
 All this can be done in userspace. Either save state before
 suspending and restore it after resuming. My first tries
 were like this:
 # save_state;
 # echo -n mem > /sys/power/state;
 # restore_state;

 Or run a daemon that saves periodically the state, somehow
 How?) detects the resume and then restores the state.
 This has problems since I need to detect the resume from
 userspace, detect if the X is running (because vesa bios
 call does not like X running on current VT)...

 On the other hand kernel module uses power management
 callbacks to save and restore state when it is needed.
 It does so before userspace processes are waken up
 (Probably it is not good thing to call userspace helper?)
 and even before some other devices are resumed.

 It helps if you can see kernel messages produced by
 resuming devices, frozen kernel with backtrace on
 dead screen in not very useful. (I do not have serial
 port to hook console to.) (I really found and solved
 one case when resume froze on my machine :-))

Ideal solution:
 Ideally proper way of saving and restoring of state should
 be found and implemented in kernel module. Such solution
 should not need to call vesa bios, and should not require
 any other interaction (like switching X <-> console) to fully
 restore the graphic state (including overlay, and cursors)

Requirements:
 i810 X driver, X.org Xserver
 vesafb console driver, 2.6.8.1 kernel

Compile:
 # make -C i855GM-restore/
 # make -C vesa_helper/

Usage:
 Read the source first and understand what it does,
 what it does not do and what it does wrong

 # insmod i855GM-restore/i855GM-restore.ko use_helper=1
helper_path=/path/to/vesa_helper
 # /path/to/vesa_helper # do not forget run vesa_helper before suspending or
use_helper=0
 # echo -n mem > /sys/power/state
 # pray...

Author:
 "Jozef Vesely" <vesely@gjh.sk>
 Skeleton based on acerhk, ideas taken form various other drivers,
 also uses lrmi-0.8 library.

 This is my first kernel module. Comments and ideas welcomed.

 WARNING: Use at your own risk. If you use it,
 there is no guarantee whatsoever that it won't
 burn your card, eat your laptop or cause Third
 World War.

TODO: vesa_helper should check if the mode is supported

TODO: dynamically alloc and free mem for saved[] ports

TODO: look at the state we are going to/from before saving/restoring state
      vesa_helper does not play well with suspend to disk

TODO: use correct video mode (the one the console was initialized to at boot)
      currently module parameter Is there a way how to find it out?

upps, it is a .tar.gz archive

same with 2.6.9? 

For me (ASUS M2N, i855GM) the problem has disappeared now.

Hello,

> same with 2.6.9?
I don't have an ASUS M3N anymore, so I cannot say if the problem has got solved
or not.

Thx, bye,
Gismo / Luca

How about VBErestore workaround in bug #3177?
That seems to work fine with i810 driver on few laptops..

Tested the bug with a new kernel, without real sucess, I haven't tried the
VBERestore option yet, will try that next. Here is a summary of the results:

Linux 2.6.9 Tue Nov 23 15:48:35 EST 2004 
X.Org version: 6.8.1

With i810 or console only:  

        Will go to sleep OK as before. Light flashes when asleep.
        Wakes up with lid event but screen dead as before.

With VESA driver:

        As above, except screen can be woken by shifting to a virtual
        terminal then shifting back. When screen has returned I find 
        that the root session has been logged out (odd?).


In syslog (using VESA X driver):

Nov 24 23:36:17 : acpitest start
Nov 24 23:36:36 kernel: Stopping tasks:
=====================================================|
Nov 24 23:36:36 kernel: Back to C!
Nov 24 23:36:36 kernel: PCI: Setting latency timer of device 0000:00:1d.0 to 64
Nov 24 23:36:36 kernel: PCI: Setting latency timer of device 0000:00:1d.0 to 64
Nov 24 23:36:36 kernel: PCI: Setting latency timer of device 0000:00:1d.7 to 64
Nov 24 23:36:36 kernel: ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 9 (level,
low) -> IRQ 9
Nov 24 23:36:36 kernel: PCI: Setting latency timer of device 0000:00:1f.5 to 64
Nov 24 23:36:36 kernel: PCMCIA: socket df532830: *** DANGER *** unable to remove
socket power
Nov 24 23:36:36 kernel: psmouse.c: TouchPad at isa0060/serio4/input0 lost sync
at byte 1
Nov 24 23:36:36 kernel: Restarting tasks... done
Nov 24 23:36:36 kernel: MCE: The hardware reports a non fatal, correctable
incident occurred on CPU 0.
Nov 24 23:36:36 kernel: Bank 1: f200000000000111
Nov 24 23:37:08 : acpitest stop

Tried the VBERestore trick. I works in that the laptop will suspend and return,
but the Xserver gets killed on return (X.org 6.8.1).

NB the laptop will not reawaken the screen if I use just the console with no X
running. Although it tempting to dismiss this bug as an X video driver issue, it
seems crazy to require X to run in order to suspend and reawaken a laptop. 

cheers,  Alexei

> it tempting to dismiss this bug as an X video driver issue

That and a BIOS issue for non GUI mode.

Note that Windows has no text mode, and that is what the OEM
tests with.

I successfully use the x86emu library (the one X uses),
compiled as kernel module to call vesa video bios before
suspend and after resume. This way I have no problem even
in text mode (vesa framebuffer).

This in kernel cpu emulator is huge, and my code is not clean,
but if anybody is interested I can post it here.

lsmod
Module                  Size  Used by
executor                6260  0
x86emu                169248  1 executor

Created attachment 4601 [details]
in kernel x86emu (.tar.gz)

Hello,

As there were some people interested in the solution mentioned above, 
I post it here.

I originaly did not intend to release it to the public in this state
since it needs to be cleaned up first, however I do not have time
to do it now.

Please be aware that I am _not_ experienced kernel hacker and so it
may not work at all or be buggy. However it works for me.

Instructions:

tar -xvzf executor_and_x86emu.tgz
cd x86emu
make
insmod x86emu.ko
cd ../executor
make
insmod executor.ko

Something like this should appear in your kernel log:

x86emu loaded.

----- Module loaded -----
Found VGA device: i855GM
Int10 entry: C000:0014
BIOS signature: 0xAA55 (OK)
BIOS size: 0xC800
halt_sys: file /root/dev/VGA_suspend/mod/x86emu/ops.c, line 9832 halted
AX after call: 0x004F (OK)
BX after call: 0x003B (size 3776)

try echo -n mem > /sys/power/state to suspend and resume
while suspending it prints:

Saving state ...
halt_sys: file /root/dev/VGA_suspend/mod/x86emu/ops.c, line 9832 halted
AX after call: 0x004F (OK)

and while resuming:

Restoring registers ...
halt_sys: file /root/dev/VGA_suspend/mod/x86emu/ops.c, line 9832 halted
AX after call: 0x004F (OK)

I use 2.6.11 kernel (but it worked also with other 2.6 versions)
X.org xserver (6.7.0) with i810 driver, and vesafb for console

!! It stopped working when I upgraded to X.org 6.8.0

Please let me know if it works for you.

Good luck,

Jozef Vesely
vesely@gjh.sk

Any ideas on what to do with this "metabug"? I'd suggest closing it, as nothing
seems to happen here lately... and as S3 resume seems to be in much better shape
than it was this February, when the last comment was made...

The video issue is a duplicate. If you still has keyboard issue, please reopen 
it.

*** This bug has been marked as a duplicate of 1516 ***