Most recent kernel where this bug did *NOT* occur: - Distribution: Ubuntu / Archlinux Hardware Environment: BenQ S73U (http://linuxwiki.de/LutzWillek/benq_s73u) Software Environment: Problem Description: System shuts down, but doesn't power-off. I got 23 warnings when compiling /proc/acpi/dsdt with the iasl-compiler, but no errors. Sebastian Lammermann managed to turn all warnings down by rewriting the DSDT, but one. Unfortunately the behavior didn't change, shutdown is still not working. original: http://openwrt.loswillios.de/dsdt.dsl modified: http://www.hft-leipzig.de/~s03114/dsdt.dsl I have put some bootlogs here: http://web746.webbox240.server-home.org/acpi/acpi-2.6.20.log http://web746.webbox240.server-home.org/acpi/acpi-2.6.21.1.log http://web746.webbox240.server-home.org/acpi/acpid There is also a thread on linux-acpi where I was told to fill a bugreport here (http://marc.info/?t=117870169900008&r=1&w=2). Please let me know if you need more information. Jan Willies (jan@willies.info)
Please attach the acpidump output and the content of /var/log/message.
Created attachment 12068 [details] acpidump output on a BenQ S73U
Created attachment 12069 [details] messages log on a BenQ S73U The notebook was cleanly booted at 22:09, then put into standby at 22:10 (via the suspend soft button). The standby did not work. Display was turned off, hard drive maybe too, the rest stayed on. The computer was turned off manually and turned on again 4 minutes later.
does init 0 shutdown the system properly? if that works, but "echo mem >/sys/power/state" fails, then this is a suspend bug, not a power-off bug.
init 0 does not shutdown the system. Everything stays on, even the display (you see the Ubuntu logo and the progress bar going backwards). After that nothing happens and I have to turn it off manually. echo mem > /sys/power/state completely freezes the computer the moment I hit enter. Nothing works anymore, and again I have to turn it off manually.
init 0 does not shutdown the system, the last message is call acpi_power_off... echo mem >/sys/power/state fails too. Now we work on a custom dsdt. We think that the suspend fail because the (setback adresses??) (dont know the english word: Rücksprungadresse) from functions dealing with PCI/WLAN are not properly handled... Method (_OSC, 5, NotSerialized) { Store (Arg3, Local0) Multiply (Local0, 0x04, Local1) Name (BUF1, Buffer (Local1) {}) Store (Arg4, BUF1) Store (Zero, Local1) Store (Zero, Local2) While (Local0) { Multiply (Local1, 0x04, Local2) CreateDWordField (BUF1, Local2, CAPB) If (Arg2) { If (LEqual (Local1, Zero)) {} } Else { } Increment (Local1) Decrement (Local0) } Return (BUF1) } you will find my acpidump (and more) at http://linuxwiki.de/LutzWillek/benq_s73u
Lutz, Frank, is there any luck with the custom DSDT table? Do you have a chance to try the latest kernel?
no, we fixed the dsdt and no we can recompile without warnings/errors. But unfortunately the laptop still power off. Yes, I tried some of the newer kernel(22.1, 22.6, 23.1) but there is no improvement. Lutz
I'm owner of a BenQ S73G, which is akin to the S73U. The power-off doesn't work too. I was able to shut down the system properly using SuSE Linux 10.1. The problem occured using the original SuSE-kernel 2.6.16.21-0.25. But it seemed to be fixed after applying a kernel update released by novell sometime between november 2006 and may 2007. I don't remember the exact version of this update. The shutdown didn't work every time, but at least it worked in the majority of cases. Unfortunately one of the next automatic updates restructed the old behavior and since then the notebook didn't shut down correct any more. I hope this information can help to identify the reason and maybe to find a solution for this problem.
Is snd-hda-intel module loaded? If so, try to remove it before powering off, it may help.
I tried it without the snd-hda-intel module loaded, but no luck. The notebook still shuts down fan & harddisk, but display stays on. 'rmmod snd-hda-intel' reported "module in use" all the time, so I blacklisted it.
Hi everyone! I found out that the Notebook DOES power down correctly (at least in 90 % of all cases) if you do the following: - Run your computer with battery power - Wait until it suspends to disc and turns off in the end (because the battery's empty) - Load your battery and restart the computer - Use it as normal - Shut down as normal => NOW it should turn off correctly (if it doesn't, reboot and give it another try)!!! I hope this helps Regards Sebastian Lammermann
I can confirm that the way described above works for me too. Incomprehensible, but it does the job! regards Lutz Willek
I too have the problem described above: The system won't power off but stop with the message "Power Down". My kernel-version is 2.6.24, my system is Gentoo Linux on a BenQ S73G (Core Duo processor). Are there any further tests i can perform to determine the exact cause and/or to provide other useful information? Regards Marcel Hoetter
HI, Marcel Will you please attach the output of acpidump? thanks.
Hi, Marcel Will you please confirm whether the windows can be powered off correctly? Thanks.
Created attachment 15785 [details] acpidump BenQ S73G Thanks for the reply, Yakui! I've attached the acpidump for my BenQ S73G.
Created attachment 15793 [details] acpidump_BenQS73U.txt same bug with vanilla Kernel 2.6.25
Will you please confirm whether the windows can be shut down correctly on the laptop? Please try the latest kernel and see whether the problem still exists. Note: ACPI should be enabled in kernel configuration and use the command "poweroff" to shutdown the laptop. Thanks.
As far as I remember XP shut down the computer- no windows installed yet. Comment #9 says that a SuSE-kernel 2.6.16.xxx was able to shut down the notebook. We tried all (!) of this versions to find out whats make the difference- without result. I suppose comment #9 was a unrecognized effect described in comment #12. So all kernels (including the latest version 2.6.25) seems to be affected in the same way. We tested nearly all combinations with/without loaded modules, ACPI enabled/disabled, but no result, no powerdown. Only #12 and a modified way described in http://linuxwiki.de/LutzWillek/Benq%20S73u (german) seems to be able to shut down the notebook: - Run your computer with battery power - as root: echo disk >/sys/power/state (system hangs, no power down) - DON'T power off the system by hand - remove the battery, wait a second - Plug in the power-Adapter, restart the laptop, load your battery - Use it as normal, shut down as normal, it works But this behavior is not permanently, it will break: - If you reboot (ie. no power off-power on; init 6) - If you shut down while AC is not plugged in (ie. battery powered) - If you boot to Windows and back to Linux (unconfirmed) - ...more issues???
Windows Vista Business powers down just fine on my BenQ S73U. Suspend to RAM and Suspend to disk work fine as well. No problems whatsoever.
Working shutdown/suspend/hibernate confirmed for Windows XP & Visa Business. When i`ve time i will try a Knoppix or some other CD-bootable Linux...
Created attachment 15835 [details] use the attached tool to read/write some I/O ports
Will you please use the attached tool to read/write some I/O ports? a. read 0x404 I/O port . 16-bit access mode (./ior --addr 0x404 --width 16) b. write 0x404 I/O port, 16-bit access mode Note: The value written into 0x404 port should be following: bitwise OR between 0x3C00 and the value read from 0x404 port After the value is written into 0x404 port, wait for some time and see whether the system can be powered off. Thanks.
Hello, i did the following: traveltux io_op # ./ior --addr 0x404 --width 16 the value of IO port 0x404 is 3 traveltux io_op # ./iow --addr 0x404 --width 16 --value 0x3C03 the value written into IO port 0x404 is 3c03 Is this correct? Unfortunatly, the system still does'nt power off. I'am available for more tests though. Let me know if i can do anything else. Regards, Marcel
I performed the procedure as well. Original value was 3, so I used iow to write 0x3C03. Before attempting to power down, I used ior again to read the newly written value. Curiously enough, the program read the value 0x1C03 from address 0x404. Is that expected behaviour? Shutdown did not work. HD and fan turn off, but display stays on.
Thanks for the test. And what you have done is right.
Hi, Frank && Marcel Will you please attach the output of lspci -vxxx? Thanks.
Created attachment 15858 [details] lspci -vxxx output
Created attachment 15865 [details] lscpi -vxxx output on S73U
Thanks for the info. Will you please confirm whether suspend to disk can work well on this laptop? (It will be great if you can also confirm it on windows). How to susepnd to disk is listed in the following : a. set "CONFIG_HIBERNATION " in kernel configuration b. after the system is booted, echo disk > /sys/power/state. Thanks.
Hi! Yes suspend to disk does work (with TuxOnIce). I have to shut down the notebook manually though after everything is written to disk (same problem as with normal shutdown). Windows XP & Vista do the trick w/o the need of manual shutdown.
I'm not really sure how to set CONFIG_HIBERNATION in the kernel configuration. Could someone point me to some more details about this? I'll gladly test then.
Hi, Frank After running the command of "make menuconfig",you can see the hibernation option in power management menu and select it. Thanks.
Does this mean I have to do a kernel compile? I'm afraid I've never done that before...
Hi Frank, sadly, suspend to disk (a.k. hibernate) is something that does not run out of the box on many linux-systems. There are various howto's for different distributions though: Gentoo (i used that one; it's good): http://www.gentoo.org/doc/en/power-management-guide.xml Ubuntu: https://help.ubuntu.com/community/Suspend2Kernel Fedora: http://mhensler.de/swsusp/ Mostly, kernel patching & compilation is needed. If you have time and like to fiddle with your distributions/linux internals: give it a try. If not, IMHO, don't bother...;-) Regards, Marcel
Hi, Marcel & Frank Will you please try the debug patch in comment 5 of bug 10503 and see whether the system can be shutdown ? Thanks.
I added the line "enable = 0" to the pci.c file as described in the patch and compiled & booted the kernel. It had no effect though, sorry.
Same grim news from me. Adding the line to pci.c had no effect, Ubuntu neither shuts down properly nor does standby work.
Hi, Marcel&Frank Will you please confirm whether some devices can be disabled in BIOS? For example: Cardbus controller, ethernet device, wireless device. If they can be disabled, please disable them in BIOS and see whether the system can be shutdown correctly. When they are enabled in BIOS, please don't load the device driver for them and see whether the system can be shutdown correctly. Thanks.
Hi, Marcel&Frank Will you please confirm whether the windows can be shutdown correctly after uninstalling the device driver device driver for the Cardbus controller, ethernet, wireless devie ? Of course the devices should be enabled in BIOS. Thanks.
Maybe you forget to configure modem.
Sorry for the late response, been a busy week. The laptop BIOS is utterly useless, other than setting time and date you can't do anything whatsoever. I did several tests: First I disabled WiFi, Ethernet and the SD Card reader with modprobe -r. But the problem remained, the device wouldn't shutdown. I then added the module names to /etc/modprobe.d/blacklist. Ubuntu ignored the network components however and only disabled the SD Card reader. I was unsuccessful finding out which module is used for the TI cardbus controller.
Hi, FranK & Marcel Will you please use the I/O tool in comment #23 to get the following output? ior --addr 0x530 --width 32 If the output bit 4 is 1, please clear it and write it back to 0x530. After this, please see whether the system can be shutdown correctly. thanks.
As there is no response for more than one month, the bug will be rejected. If the problem still exists, please reopen it again and do the test required in comment #44. Thanks.
[chris@book io_op]$ su -c "./ior --addr 0x530 --width 32" Passwort: the value of IO port 0x530 is 100f6 Please tell me, if I did anything wrong. Would like to reopen, but don't have the rights to. mybe you can do, ykzhao. regards, chris
running Fedora 2.6.25.14-108.fc9.i686, if that does matter. sry and regards, chris
reopening because of provided information above
Hi, Christian Will you please confirm whether you have the same system with the Marcel&Frank? If yes, please write 0x100e6 to 0x530 port I/O and see whether the system can be shutdown. If not, please open a new bug and attach the output of acpidump, lspci -vxxx, dmesg. thanks.
yes, I have got the same system (s73u). [chris@book io_op]$ su -c "./iow --addr 0x530 --width 32 --value 0x100e6" Passwort: the value written into IO port 0x530 is 100e6 [chris@book io_op]$ No shutdown :/
Hi, Chirstian Do you mean that the system still can't be shutdown by poweoff command after writing 0x100e6 to 0x530 I/O port? Right? Thanks.
Hi yakui, sry for my bad wording. There is no shutdown by invoking the following cmds: [chris@book ~]$ su -c "./iow --addr 0x530 --width 32 --value 0x100e6" [chris@book ~]$ su -c "halt" In the Boot-Console I can read "halt" and I hear a silent "klick", which normally invokes (in windows it does) the switch off. Then for 3 seconds the notebook is completely silent, but the display is on. Then the cooler starts to work. HDD sounds to be off. Book has to be switched off manually. In the End the iow did *not* changed the normal behaviour after running "halt". What I discovered is, that turning the notebook in "suspend to disk" (by manual switch off) and starting it again often (everytime I remember it) helps for a "normal" switch off at the next shutdown. Shall I try and read out the value of the register after a suspend to disk?
Your laptop similar http://www.maxselect.ru/catalog/models.html?id=4706. They have an identical platform - Barebone Mitac Laptop 8224D. This laptop has ASPlinux, and work correctly. Sorry, but I cannot search additional information. Maybe cannot help this information?
Hi, Christian Please use the command of "poweroff" instead of "halt". Thanks.
Using "poweroff" instead of "halt" does *not* change the behaviour. No power off. regards, chris
If you write 0x3C01 to 0x404 I/O port(16 bit), please see what happens? Of course the above should be done after writing the 0x100e0 to 0x530 I/O port. Thanks.
[chris@book ~]$ cd io_op/ [chris@book io_op]$ su -c "./iow --addr 0x530 --width 32 --value 0x100e6" Passwort: the value written into IO port 0x530 is 100e6 [chris@book io_op]$ su -c "./iow --addr 0x404 --width 16 --value 0x3C01" Passwort: the value written into IO port 0x404 is 3c01 [chris@book io_op]$ su -c "poweroff" sry, but still no poweroff. Behaviour did *not* changed.
sry, my fault: tried the same with: [chris@book ~]$ su -c "./iow --addr 0x530 --width 32 --value 0x100e0" instead of 0x100e6, but still no poweroff.
Hi, Christian Sorry for the late response. Will you please do the following on your box? a. boot the system with the option of "acpi=off" b. lspci -vxxx > lspci_acpi_off; and ./ior --addr 0x404 --width 16 c. ./iow --addr 0xb2 --width 8 --value 0xa0 d. lspci -vxxx > lspci_acpi_trans; and ./ior --addr 0x404 --width 16 Thanks.
Hi, Marcel&Frank Will you please do the similar test as mentionted in comment #59? After the test, please attach the output of lspci -vxxx and the result of 0x404 I/O port. thanks.
Hi yakui, i tried to boot with "acpi=off", but my system complains at the startup: .. MC-Bios bug: 8254 timer not connected to io-apic ata1.00: cmd 00:08... The message appears before root is mounted. Kernel: 2.6.27.5-117.fc10.686 (In reply to comment #59)
Hi, Christian Do you mean that the system can't be booted with acpi disabled after the following is complained in course of startup? >.. MC-Bios bug: 8254 timer not connected to io-apic >ata1.00: cmd 00:08... If so, please add the boot option of "noapic" and do the test as required in comment #59. Of course the boot option of "acpi=off" is still required. Thanks.
Created attachment 19192 [details] comment 59 / b: lspci -vxxx > lspci_acpi_off;
Created attachment 19193 [details] comment 59 / d: lspci -vxxx > lspci_acpi_trans;
Hi yakui, with your provided information from #61 I could successfully boot my system. Here are the outputs of iow and ior, executed in your provided order: [root@book io_op]$ ./ior --addr 0x404 --width 16 the value of IO port 0x404 is 0 [root@book io_op]# ./iow --addr 0xb2 --width 8 --value 0xa0 the value written into IO port 0xb2 is a0 [root@book io_op]# ./ior --addr 0x404 --width 16 the value of IO port 0x404 is 1 Thanks for your help.
Hi, Christian Please attach the output of lspci -vxxx instead of lspci -vxx when doing the test. Thanks
Hi, Christian Will you please boot the system with ACPI disabled and do the following test?(by adding the boot option of "acpi=off noapic") a. ./iow --addr 0xb2 --width 8 --value 0xa0 b. ./iow --addr 0x404 --width 16 --value 0x3C01 After writing 0x3C01 to 0x404 PM1A control register, please check whether the system is shutdown. Thanks.
Hi yakui, sry for my late response. I did the test of commect #67. I entered command (a) and (b) and by commiting (b) in the terminal my system was turned off. Means there was no poweroff possible, because the system did a hard shut down. I will do the test of Comment #66 and will attach the files in the next minutes. Thanks
me again. just to make it clear - hard shut down means, that the cmd (b) of Comment 67 had the same result as pressing my poweroff button about 6seconds. The book turned off (without unmounting, stopping processes...) immediately. This time, I hope I did your tests right (although I thought, I already did that lspci -vxxx) [root@book io_op]# lspci -vxxx > lspci_acpi_off [root@book io_op]# ./ior --addr 0x404 --width 16 the value of IO port 0x404 is 0 [root@book io_op]# ./iow --addr 0xb2 --width 8 --value 0xa0 the value written into IO port 0xb2 is a0 [root@book io_op]# lspci -vxxx > lspci_acpi_trans [root@book io_op]# ./ior --addr 0x404 --width 16 the value of IO port 0x404 is 1 [root@book io_op]# regards, chris
Created attachment 19401 [details] comment 66 / b: lspci -vxxx > lspci_acpi_off;
Created attachment 19402 [details] comment 59 / d: lspci -vxxx > lspci_acpi_trans;
Created attachment 19403 [details] comment 66 / d: lspci -vxxx > lspci_acpi_trans;
Created attachment 19419 [details] The S5 SLP_TYPE value is written to PM1A control register after acpi full initialization
Created attachment 19420 [details] The S5 SLP_TYPE value is written to PM1A control register after scanning pci device
Hi, Christian Thanks for the test. From the description in comment #69 it seems that the box is shutdown if the following step is exectuted: a. boot the system with ACPI disabled (add the boot option of "acpi=off noapci" b. ./iow --addr 0xb2 --width 8 --value 0xa0 ( mode switch between ACPI and legacy mode) c. ./iow --addr 0x404 --width 16 --value 0x3C01 (The S5 SLP_TYPE is written to the PM1A control register) Will you please try the above two debug patches on the latest kernel and see whether the system can be shutdown? It is noted that the above two patches had better be tested independently. Thanks.
Created attachment 19422 [details] ACPI is initialized after scanning pci devices Hi, Christian Will you please try the attached debug patch on the latest kernel(2.6.28-rc8) and see whether the system can be shutdown? In this debug patch the ACPI is initialized after scanning pci devices. Thanks.
Hi, Christian Do you have opportunity to try the patches on the 2.6.28-rc8 kernel and see whether the system can be shutdown? Note: When the patch in comment #73 or #74 is tested, you needn't use the command of "poweroff" or "shutdown". It is done in the boot phase. When the patch in comment #76 is tested, you need use the command of "poweroff" or "shutdown". Thanks.
hi yakui, thanks for your updates. Unfortunately I have no clue, how I get the 2.6.28-rc8 kernel, patch it, use it?! At the moment I am using f10 (2.6.27.7-134.fc10.i686) :/ regards
Hi, Christian You can download the source code(2.6.28-rc8) from www.kernel.org and then compile , install it. Please don't try the patch in comment #76. The patch is already tried on another box. And the box still can't be shutdown. Thanks.
*** Bug 12183 has been marked as a duplicate of this bug. ***
Hi Yakui! I tried your patches with kernel 2.6.28-rc8. The one in comment #74 had no effect. The system booted and could not be shut down properly (the "normal" behaviour). The patch in comment #73 in contrast resulted in the system to power off during the boot process (expected behaviour?).
Created attachment 19478 [details] The S5 SLP_TYP value is written to PM1A control register after building ACPI device tree
Created attachment 19479 [details] The S5 SLP_TYP value is written to PM1A control register after initializing EC driver
Hi Can someone try the debug patch on the kernel of 2.6.28-rc8 and see whether the system can be shutdown? (This is automatically done in the boot phase) Thanks. Hi, Johannes thanks for the test. From the test it seems that the system can be shutdown immediately by writing S5 SLP_TYP value to PM1A control register after ACPI full initialization. But it fails if this is done after scanning PCI devices. Will you please try the debug patch in comment #82/83 ? Thanks.
Created attachment 19480 [details] The S5 SLP_TYP value is written to PM1A control register after building ACPI device tree
Created attachment 19481 [details] The S5 SLP_TYP value is written to PM1A control register after initializing EC driver
Hi, Sorry for the typo:) Will you please try the debug patch in comment #85/86 ? thanks.
Hi! I tried the patches (comment #85/#86). Both had the same result: no shutdown in boot phase. In fact, no shutdown at all. :) I hope this information can help to locate the source of the problem. I am willing to do further tests (as far as I have enough time...).
Hi, Johannes thanks for the test. From the info in comment #81 it seems that the system can be shutdown if the S5 SLP_TYP is written immediately after ACPI full initialization. But from the info in comment #88 it can't be shutdown if the S5 SLP_TYP is written after building ACPI device tree. In the source code building ACPI device tree follows the ACPI full initialization. In the course of building ACPI device tree OS only checks whether there exists the ACPI handle for some ACPI devices and won't evaluate it. Will you please double check the patches in comment #73/#85 again? Thanks.
Hi! I "double checked" the two patches and I found that the information given in comment #81 is not completely correct. The patch in comment #73 does not always shut down the system. After booting the patched kernel about a dozen times, there seems to be a fifty-fifty chance (without any statistical significance) for the system to shut down. This reminds me of comment #12. The way described there to shut down the notebook does not work every time too. I also checked the patches in comment #85/#86 again, but I could verify everything I wrote in comment #88: no shutdown. I would be glad if anyone else could confirm this.
Hi I tried the patch in comment #73. And it doesn't work. I try to shutdown many times and I never had a successful shutdown. Halting system... md: stopping all md devices. sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk ACPI: Preparing to enter system sleep state S5 Disabilng non-boot CPUs .. Breaking affinity for irq 9 Breaking affinity for irq 12 CPU 1 is now offline SMP alternativs: switching to UP code CPU1 is donw Power down. acpi_power_off_called And stays there (I have drivers/acpi/ec.c #define DEBUG uncommented to see that) I tried the patch in comment #85 and it doesn't work Halting system... md: stopping all md devices. sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk e100 0000:06:08.0: PCI INT A disabled ACPI: Preparing to enter system sleep state S5 Disabilng non-boot CPUs .. Breaking affinity for irq 1 Breaking affinity for irq 9 Breaking affinity for irq 16 Breaking affinity for irq 20 CPU 1 is now offline SMP alternativs: switching to UP code CPU1 is donw Power down. acpi_power_off_called and stays there...
Although I seeing now that before booting the system when I press enter in kernel with patch in comment #85 my laptop shutdown. But I'm not sure if that is cause the patch. Sometimes the system boot and sometimes the system doesn't because it shutdown
Hi, Pablo It is very strange that your box still can be booted very normally after the S5 SLP_TYP value is written to PM1A control register in the boot phase. Will you please add the boot option of "noapic"? Of course the debug patch in comment #73/85 is still required. Thanks.
I tried with noapic, with acpi=off and noapic and normal. In all cases, the boot is apparently correct but as always, it doesn't shutdown
If this info does help in any way - FreeBSD comes with the same poweroff problem
Hi all, I compiled Kernel 2.6.28-rc8 with patches #73, #85, #86. Compilation was separately for each patch, in all cases I noticed the same behavior: laptop shutdown during boot time but not always, sometimes ( more less 50% times ) it boots normally and turns on system. I can do more tests
Created attachment 20431 [details] call the _WAK object after ACPI full initialization Will you please try the debug patch on the latest kernel and see whether the behaviour is changed? Thanks.
Does someone have an opportunity to try the boot option of "acpi_sleep=old_ordering" on the latest kernel and see whether the box can be shutdown? Thanks.
Shuld i try #97 patch with patch #73, #85, #86 or without?
OK i compiled 2.6.29-rc7 with patch #97 and result is that computer still doesn't shut down. the same result is for #98 option written in menu.lst for the same kernel.
Hi, Arkadiusz Thank for the test. It seems that the debug patch or the boot option doesn't help to solve the issue. Thanks again.
does maxcpus=1 make any difference, either after booting all the way up to single user and a poweroff from there, or with any of the tests, such as the one in comment #96? I think that moving the shutdown later and later in the boot process to find where writing the regsiters always fails is the only obvious method to isolate where (in time) we break.
if you mean adding maxcpus=1 to menu.lst then it does not make any difference, I checked.
Does anyone try the boot option of "acpi_sleep=old_ordering" and see whether the box can be shutdown by using hibernate? echo disk > /sys/power/state Thanks.
ping ...
(In reply to comment #104) > Does anyone try the boot option of "acpi_sleep=old_ordering" and see whether > the box can be shutdown by using hibernate? > echo disk > /sys/power/state > Thanks. in my case: after typing "echo disk > /sys/power/stste" in terminal i can hear as the hard disk and other pheripherals are turning off but screen displays the same during the all progres, which means the screen displays desktop with all opened windows and nothing changes. Anyway laptop still works after all progres ( no power off ).
I also just tried #104 and the system did not power-off and even resume failed. I have observed the following with Ubuntu 9.04 (2.6.28-11-generic): S2disk (with forced power-off if necessary) seems to put/keep the system in a state where power-off works: subsequent s2disk will always power-off. Even s2ram then does power-off. However, a subsequent s2ram fails on resume. The sequence s2disk-s2ram-s2disk-s2ram-s2disk and so on seems to always power-off and resume just fine. Also shutdown does power-off after s2disk, it however "breaks" it so a subsequent s2disk will not power-off. So basically, power-off works when only using s2disk (and s2ram when followed by s2disk). Personally, I could live with s2disk, but it would still be great if this issue could be solved. I would be happy to assist. Cheers, Torsten
I can confirm that command s2disk can disable my laptop. First usage put laptop in state which causes that every next usage of s2disk results in power off.
Bug is assigned? Great! So can we hope for a patch :-) Please let me know if I can contribute! Torsten
HI, Torsten Sorry that I have no idea about this bug. The status of this bug is changed to assigned from needinfo. Thanks.
*** Bug 12348 has been marked as a duplicate of this bug. ***
I confirm too that command s2disk save correctly the state of the box but doesn't poweroff, however when I start the system from s2disk, poweroff and suspend works fine,,, What changes s2disk to make poweroff and suspend work? logically something is different because the box power off.... Thanks,
*** Bug 12694 has been marked as a duplicate of this bug. ***
Sure, im commit for the bug 12694. i want to say that grub can halt normoally as push the power button in the end.
Some hopefully not completely useless info: When the box is in the state where it does not power off (after normal startup or restart), the screen is black during s2disk. When it is in the state where it does power off (after resume from s2disk), the screen shows some funny colorful blinking pattern of blocks and lines during s2disk until it powers off. Has the power off maybe something to do with the graphics device or driver or something?
Hi, i just started having very similar problems. Check bug 15698. Same behaviour on a newer kernel...
On the same hardware? Regarding power-off not working with the BenQ S73x, I have given up hope that this will ever work with Linux. I guess the machine has a buggy BIOS and Windows (XP) somehow gets along with it, but Linux doesn't. Torsten
Yakui, any update on this?
I have no idea about this bug. We tried several methods but the box still can't be powered off. Thanks
I am just wondering why it works flawlessly on Windows. Does Windows do some special magic here? Or is the Linux implementation incomplete or broken? Also interesting is that, as already mentioned, power off always works after a hibernate - resume sequence. But well, it is an old machine not used by many people with Linux I suppose and there are probably more important things to fix.
please try booting with "acpi_osi=" and report if any difference. please attach the complete dmesg from the latest stable kernel
Created attachment 45052 [details] Kernel 2.6.37 with acpi_osi= Same behaviour (power-off only works after hibernate-resume cycle) also with acpi_osi=
For the systems where hibernate to disk results in the subsequent poweroff working... What do you see in /sys/power/disk ? Same result if it is set to either "platform" or "shutdown" before the hibernate? Re: why we have this failure Linux is writing the correct value to poweroff the machine. When Linux does it early, per debug tests above, it works. When Linux does it later (in response to poweroff command), it fails. The difference is that some state in the system has changed that confuses the BIOS. It may have nothing at all to do with "correctness". The system enters SMM-mode when we write the poweroff command, and that code was written and debugged with windows running, not Linux... eg. when you said something happened 50% of the time it reminded me of an SMM interaction we had on another system where SMM would run correctly only if run from cpu0 and it would fail if run from cpu1 -- simply b/c windows happened to trigger it that way... This seems like a similar kind of failure -- though the "state" that is different is not that we're running on cpu1 b/c we fail still in uni-processor mode.
Hello, I have the same problem on an ASUS CUSI-FX motherboard, the pc don't poweroff. Message will now halt on screen and power led turned off but the pc is still on. maybe it helps: http://pastebin.com/P97rjB3M http://pastebin.com/unL7ryd4 http://pastebin.com/i9x5wr6g http://pastebin.com/njLscLCq http://pastebin.com/YUg8HzSR http://pastebin.com/mRAsJ9uw tried with debian wheezy and ubuntu dapper. This is the first time I write on pastebin, let me know if I have to do more tests. Sorry for my bad english. bye
It's great that kernel bugzilla is back. can you please verify if the problem still exists in the latest upstream kernel?
:-) Yes, it's great.. :-( Yes, the problem still exists on my system # uname -a Linux server 3.1.0-1-686-pae #1 SMP Tue Jan 10 05:42:54 UTC 2012 i686 GNU/Linux it's a debian wheezy headless PIII 933mhz.. Let me know if you need more infos! Thanks!
To comment #123: dode@linus:~$ cat /sys/power/disk [platform] test testproc shutdown reboot Which value(s) should I put in there to try? The behaviour is still exactly the same for me with 3.0.0-15-generic. I'll see if I can get the latest kernel with reasonable effort and try again. Torsten
https://wiki.ubuntu.com/DebuggingKernelSuspend may be helpful in showing how to go about this.
Anyone still has this problem on latest upstream kernel?
ping...
I got a new laptop (a Lenovo L420 where power-off, standby and suspend works just fine) by now and gave away the BenQ. So the issue is solved for me - and I am sorry I can't give any feedback on this any more.
Sorry I can't help either. I still have the laptop somewhere but the powerconnector is broken, so it's basically useless.
okay. bug closed. please feel free to reopen it once you can reproduce the problem.
Still a bug on 3.2.45 kernel (on SLackware) and on Ubuntu: paolo@pc-paolo:~$ uname -a Linux pc-paolo 3.2.0-48-generic-pae #74-Ubuntu SMP Thu Jun 6 20:05:01 UTC 2013 i686 i686 i386 GNU/Linux
Still a bug on 3.11.0, reproducible on Ubuntu 13.10 (i686).
Couldn't this be a BIOS quirk that Windows has a fix for, since power-off works fine on other machines?