Distribution:Debian unstable Hardware Environment:Panasonic W2 laptop Software Environment:Kernel 2.6.{0test9,0test11,1}, 2.4.*, both with minimal options (eg no usb etc) and with full options compiled in Problem Description: Laptop seems to go to sleep OK. On resume the keyboard, mouse and screen are dead. No ACPI events are registered either (eg LID events). network DOES come back and system appears fine if you log in from the network. other observations: The SD drive light remains lit after resume (only time I've seen it lit). LED's don't flash when sleeping. this gets logged to console: # qutrit kernel: MCE: The hardware reports a non fatal, correctable incident on CPU 0 # qutrit kernel: Bank 1: f200000000000111 Steps to reproduce: echo 3 > /proc/acpi/sleep
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 ***