Bugzilla – Bug 114017
Suspend to disk failed after coming back with os_wait_semaphore
Last modified: 2005-09-22 02:51:41 UTC
HW: HP Omnibook 6100, 1 GHz, 768 MB RAM The fist time suspend-to-disk is working properly. Only there is a 4 divided screen for a short time. After comming back the secon time using this function system stops with following message: osl-1048[227] os_wait_semahore: Failed to acquire semaphore [dfffefc0|1|0], AE_TIME It does´nt matter if I use the sleep-modi-key or the function over kde. The problem is, this failure occurs very often, but is not 100% reproducible. After a cold start system repairs open entries and the world is pretty good again. The semaphore address is always the same. I could not found a logfile with this written error message.
Created attachment 48084 [details] Logfiles Logfiles: boot.msg messages suspend2disk.log suspend2disk_2.log
Well, you could try running with ACPI disabled :-). You could also try using shutdown mode instead of platform one, that should help. But I'd say this is bug in your ACPI BIOS.
Switching to shutdown mode is done easily in /etc/sysconfig/powersave/sleep: SUSPEND2DISK_SHUTDOWN_MODE="shutdown"
How can it be a bug in ACPI Bios if its working with w2k properly? And the first time it is working. Only if I do this the second time its crashed.
(In reply to comment #4) > How can it be a bug in ACPI Bios if its working with w2k properly? If this was true, all BIOSes would be bug free wrt ACPI. They are not. > And the first time it is working. Only if I do this the second time its crashed. As a workaround, try "shutdown" mode, this bypasses ACPI in the most critical paths on suspend to disk (set it in /etc/sysconfig/powersave/sleep)
Ok, I changed SUSPEND2DISK_SHUTDOWN_MODE to "shutdown". I tested suspend-to-disk 3 times over sleep-mode key. It was OK, but to start a 4 time was not possible ober sleep-mode key. The key was blocked. I used the suspend-to-disk funktion over kpowersave and than the funtion failed in shutdown phase. Here the last 8 lines from the screen: ------------------------------- acpi-bus-0212[69] acpi_bus_set_power: Device is not power manageable. Qriting dat to swap(9610 pages).... 18%<6>e100: eth0: e100_watchdog: link up, 100 Mbps, full_duplex done. Writung pagedir ... done(38 pages). S| md: stopping all md devices. md: md0 switched to read-only mode. Stutdown: hda osl-1048[86] os_wait_semaphore: Failed to acquire semaphore[dfffed40|1|0], AE_TIME ---------------------------------- I switched the computer of and started again. The OS could finished the suspend-to-disk with comming back to memory without any failure. Strange! Please notice that the semaphore is different to the first bug report.
Okay, so something is wrong with ACPI BIOS. Can you try vanilla kernel? Should we disable "platform" mode based on DMI? Does it work reliably with "reboot" method?
Created attachment 49540 [details] /var/log/messages I´ve installed RC1 and with this version the failure is not reproduceable. I tried CPUFREQ_CONTROL in /etc/sysconfig/powersave/cpufreq with "userspace" and without. The different error messages you can find in the logfile.
Suspend to disc crashed today again after comming back with: APCI-1048: *** Warning: Failed to acquire semaphore [dfffe520|1|0], AE_TIME (RC1 is running) Please, have a look also to BUG 116384 "Suspend to disk over sleep key button is not working properly"
Well, I need something reproducible to debug this. Sorry.
If you can give me an idea how to go I will try to find a reproducible way to find the bug. What kind of components are involved with this semaphore bug?
ACPI interpretter and ACPI bios is involved.
I tried to reproduce the bug again. By the way, you can find this bug reported from user other Linux system as well. Google can help to find it. The bug is not 100% reprodureable but during my test the bug occurs after two, tree or four times using suspend to disc. The dependency is not clear but I guess the bug depends on some interrupts (Maestro, Graphic-Sound-System) IRQ 5 and (Yenta Cardbus, PCI1420 and e100) IRQ 10 (look file screen.txt see below). Please compare message logfile line 213 to 220 with screen.txt. In screen.txt I have written what the screen has shown. The semaphore error messages you cannot find in message logile.
Created attachment 50002 [details] messages from the screen
Created attachment 50003 [details] /var/log/messages
Created attachment 50004 [details] hwinfo
Created attachment 50005 [details] lshal
Created attachment 50006 [details] /var/log/syspend2disk.log
Created attachment 50007 [details] bios setting HP Omnibook 6100
I asked you for a try with vanilla kernel, but no, you attach 1000 random files, instead. That is surely going to help.
I use sometimes vanilla for cooking, but for a kernel? Ok, can you tell me what is vanilla kernel and how I can get it? Sorry, if I hurt you with this 1000 files. I thought it could be a necessary information for you.
Vanilla kernel means kernel straight from linus, unmodified. You can get it at www.kernel.org.
2.6.13.1 oder 1.6.14-rc1 ?
I installed the vanilla kernel 2.6.13.1 and tested suspend-to-disc under the same conditions like before in approx. 20 minutes 10 times (boring job). With this kernel the bug doesn´t occurs. The differenz in the behaviour was that the blue SuSe screen was not there. Before I send the system to suspend last time I started a ping and let it run. After comming back and enter password ping was running again. This is different to the kernel before. The task was broken every time after comming back. I hope this was helpful.
So it is broken in SuSE and same config works with vanilla. I am not aware of any big changes in ACPI that might be responsible. Are you using DSDT override? Ah, we are using ec burst mode by default, that could explain it. Can you revert patches.suse/acpi_enable_ec_burst_mode or disable it by kernel parameter? patches.fixes/acpi-thermal-polling looks remotely weird, too.
Thomas is ec_burst master ;-)
If you mean DSDT from the kernel config file here is the setting: # CONFIG_ACPI_CUSTOM_DSDT is not set If you mean DSDT from /etc/sysconfig/kernel here is this setting: ACPI_DSDT="" Anything else? I disabled acpi_enable_ec_burst_mode by kernel parameter (see below). #---/var/log/boot.msg---# <5>Kernel command line: root=/dev/hda2 vga=0x317 selinux=0 resume=/dev/hda1 splash=silent acpi_enable_ec_burst_mode=off But the result hasn´t changed. After 3 times suspend the semaphore bug was there again. In the boot log file there was no other information about this setting. How can I know the parameter was working? If you want to have to revert this in the kernel you have to explain it more detailed. Than I can try it.
the correct parameter is ec_burst=0 (off) ec_burst=1 (on, default)
Thanks for this correct parameter. After set ec_burst=0 the bug doesn´t occur. I tested suspend to disc 10 times.
Okay, ec_burst problems go to trenn. *** This bug has been marked as a duplicate of 106257 ***
Sorry, but I cannot agree with this decision. Bug 106257 description is total different and the reason for this two bugs I guess also.