Bug 8549 - Power-Off works only after a hibernate-resume cycle - BenQ S73U, S73G
Power-Off works only after a hibernate-resume cycle - BenQ S73U, S73G
Status: CLOSED INSUFFICIENT_DATA
Product: ACPI
Classification: Unclassified
Component: Power-Off
i386 Linux
: P2 blocking
Assigned To: ykzhao
:
: 12183 12348 12694 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-29 02:40 UTC by Jan Willies
Modified: 2013-10-28 10:09 UTC (History)
21 users (show)

See Also:
Kernel Version: 3.1.0
Tree: Mainline
Regression: No


Attachments
acpidump output on a BenQ S73U (92.34 KB, application/octet-stream)
2007-07-17 13:56 UTC, Frank Aurich
Details
messages log on a BenQ S73U (86.15 KB, application/octet-stream)
2007-07-17 14:02 UTC, Frank Aurich
Details
acpidump BenQ S73G (97.18 KB, text/plain)
2008-04-17 03:50 UTC, Marcel Hoetter
Details
acpidump_BenQS73U.txt (92.34 KB, text/plain)
2008-04-17 13:59 UTC, Lutz Willek
Details
use the attached tool to read/write some I/O ports (2.47 KB, application/x-gzip)
2008-04-22 00:44 UTC, ykzhao
Details
lspci -vxxx output (4.03 KB, application/x-gzip)
2008-04-23 03:48 UTC, Marcel Hoetter
Details
lscpi -vxxx output on S73U (3.31 KB, application/gzip)
2008-04-23 11:00 UTC, Frank Aurich
Details
comment 59 / b: lspci -vxxx > lspci_acpi_off; (12.98 KB, application/octet-stream)
2008-12-07 06:58 UTC, Christian Herrmann
Details
comment 59 / d: lspci -vxxx > lspci_acpi_trans; (28.42 KB, application/octet-stream)
2008-12-07 07:00 UTC, Christian Herrmann
Details
comment 66 / b: lspci -vxxx > lspci_acpi_off; (28.42 KB, application/octet-stream)
2008-12-20 09:35 UTC, Christian Herrmann
Details
comment 59 / d: lspci -vxxx > lspci_acpi_trans; (28.42 KB, application/octet-stream)
2008-12-20 09:36 UTC, Christian Herrmann
Details
comment 66 / d: lspci -vxxx > lspci_acpi_trans; (28.42 KB, application/octet-stream)
2008-12-20 09:36 UTC, Christian Herrmann
Details
The S5 SLP_TYPE value is written to PM1A control register after acpi full initialization (611 bytes, patch)
2008-12-22 00:54 UTC, ykzhao
Details | Diff
The S5 SLP_TYPE value is written to PM1A control register after scanning pci device (626 bytes, patch)
2008-12-22 00:55 UTC, ykzhao
Details | Diff
ACPI is initialized after scanning pci devices (2.17 KB, patch)
2008-12-22 01:19 UTC, ykzhao
Details | Diff
The S5 SLP_TYP value is written to PM1A control register after building ACPI device tree (631 bytes, patch)
2008-12-24 21:19 UTC, ykzhao
Details | Diff
The S5 SLP_TYP value is written to PM1A control register after initializing EC driver (493 bytes, patch)
2008-12-24 21:26 UTC, ykzhao
Details | Diff
The S5 SLP_TYP value is written to PM1A control register after building ACPI device tree (631 bytes, text/x-patch)
2008-12-25 01:40 UTC, ykzhao
Details
The S5 SLP_TYP value is written to PM1A control register after initializing EC driver (493 bytes, patch)
2008-12-25 01:40 UTC, ykzhao
Details | Diff
call the _WAK object after ACPI full initialization (933 bytes, patch)
2009-03-04 17:43 UTC, ykzhao
Details | Diff
Kernel 2.6.37 with acpi_osi= (84.84 KB, text/plain)
2011-01-24 23:29 UTC, Torsten Römer
Details

Description Jan Willies 2007-05-29 02:40:15 UTC
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)
Comment 1 Zhang Rui 2007-07-05 19:04:08 UTC
Please attach the acpidump output and the content of /var/log/message.
Comment 2 Frank Aurich 2007-07-17 13:56:04 UTC
Created attachment 12068 [details]
acpidump output on a BenQ S73U
Comment 3 Frank Aurich 2007-07-17 14:02:09 UTC
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.
Comment 4 Len Brown 2007-07-18 19:36:38 UTC
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.
Comment 5 Frank Aurich 2007-07-19 11:06:49 UTC
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.
Comment 6 Lutz Willek 2007-07-20 03:28:41 UTC
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
Comment 7 Fu Michael 2007-11-06 22:00:36 UTC
Lutz, Frank, is there any luck with the custom DSDT table? Do you have a chance to try the latest kernel?
Comment 8 Lutz Willek 2007-11-07 05:25:56 UTC
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
Comment 9 Johannes Römer 2007-11-16 09:51:23 UTC
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.
Comment 10 Vladislav Bogdanov 2007-11-28 07:55:37 UTC
Is snd-hda-intel module loaded?
If so, try to remove it before powering off, it may help.
Comment 11 Frank Aurich 2007-11-28 09:10:23 UTC
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.
Comment 12 Sebastian Lammermann 2007-12-10 05:39:36 UTC
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
Comment 13 Lutz Willek 2007-12-10 15:03:06 UTC
I can confirm that the way described above works for me too. Incomprehensible, but it does the job! 

regards
Lutz Willek
Comment 14 Marcel Hoetter 2008-03-12 08:19:56 UTC
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 
Comment 15 ykzhao 2008-04-16 02:51:16 UTC
HI, Marcel
    Will you please attach the output of acpidump?
    thanks.
Comment 16 ykzhao 2008-04-16 03:06:44 UTC
Hi, Marcel
    Will you please confirm whether the windows can be powered off correctly?
    Thanks.
Comment 17 Marcel Hoetter 2008-04-17 03:50:41 UTC
Created attachment 15785 [details]
acpidump BenQ S73G

Thanks for the reply, Yakui!
I've attached the acpidump for my BenQ S73G.
Comment 18 Lutz Willek 2008-04-17 13:59:01 UTC
Created attachment 15793 [details]
acpidump_BenQS73U.txt

same bug with vanilla Kernel 2.6.25
Comment 19 ykzhao 2008-04-17 22:07:43 UTC
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.
Comment 20 Lutz Willek 2008-04-18 01:31:05 UTC
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???
Comment 21 Frank Aurich 2008-04-18 06:26:28 UTC
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.
Comment 22 Marcel Hoetter 2008-04-18 11:15:14 UTC
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...
Comment 23 ykzhao 2008-04-22 00:44:51 UTC
Created attachment 15835 [details]
use the attached tool to read/write some I/O ports
Comment 24 ykzhao 2008-04-22 01:00:24 UTC
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.
Comment 25 Marcel Hoetter 2008-04-22 01:45:12 UTC
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
Comment 26 Frank Aurich 2008-04-22 06:07:31 UTC
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.

Comment 27 ykzhao 2008-04-22 23:53:25 UTC
Thanks for the test.  And what you have done is right.
Comment 28 ykzhao 2008-04-23 02:37:00 UTC
Hi, Frank && Marcel
   Will you please attach the output of lspci -vxxx?
   Thanks.
Comment 29 Marcel Hoetter 2008-04-23 03:48:08 UTC
Created attachment 15858 [details]
lspci -vxxx output
Comment 30 Frank Aurich 2008-04-23 11:00:18 UTC
Created attachment 15865 [details]
lscpi -vxxx output on S73U
Comment 31 ykzhao 2008-04-28 00:24:43 UTC
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.
Comment 32 Marcel Hoetter 2008-04-29 10:05:55 UTC
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.


Comment 33 Frank Aurich 2008-04-29 17:37:56 UTC
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.
Comment 34 ykzhao 2008-04-30 02:39:28 UTC
Hi, Frank
    After running the command of "make menuconfig",you can see the hibernation option in power management menu and select it.
    Thanks.
Comment 35 Frank Aurich 2008-04-30 02:57:52 UTC
Does this mean I have to do a kernel compile? I'm afraid I've never done that before...
Comment 36 Marcel Hoetter 2008-04-30 04:10:23 UTC
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
Comment 37 ykzhao 2008-05-05 02:19:23 UTC
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.
Comment 38 Marcel Hoetter 2008-05-11 01:47:26 UTC
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.
Comment 39 Frank Aurich 2008-05-11 03:55:47 UTC
Same grim news from me. Adding the line to pci.c had no effect, Ubuntu neither shuts down properly nor does standby work.
Comment 40 ykzhao 2008-06-04 20:03:20 UTC
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.
Comment 41 ykzhao 2008-06-04 20:50:10 UTC
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.

    
Comment 42 al 2008-06-11 11:04:53 UTC
Maybe you forget to configure modem.
Comment 43 Frank Aurich 2008-06-11 13:58:31 UTC
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.
Comment 44 ykzhao 2008-08-14 20:50:22 UTC
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.
Comment 45 ykzhao 2008-09-17 19:31:27 UTC
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.
Comment 46 Christian Herrmann 2008-09-19 12:33:47 UTC
[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
Comment 47 Christian Herrmann 2008-09-19 12:37:49 UTC
running Fedora 2.6.25.14-108.fc9.i686, if that does matter.

sry and regards,
chris
Comment 48 Jan Willies 2008-09-19 23:41:11 UTC
reopening because of provided information above
Comment 49 ykzhao 2008-09-20 07:02:32 UTC
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.
Comment 50 Christian Herrmann 2008-09-20 11:43:56 UTC
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 :/
Comment 51 ykzhao 2008-09-21 07:21:40 UTC
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.
Comment 52 Christian Herrmann 2008-09-21 08:17:16 UTC
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?
Comment 53 al 2008-09-21 22:32:47 UTC
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?
Comment 54 ykzhao 2008-09-22 02:31:10 UTC
Hi, Christian
    Please use the command of "poweroff" instead of "halt".
    Thanks.
Comment 55 Christian Herrmann 2008-09-22 03:33:30 UTC
Using "poweroff" instead of "halt" does *not* change the behaviour. No power off.

regards,
chris
Comment 56 ykzhao 2008-09-23 00:29:03 UTC
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.
Comment 57 Christian Herrmann 2008-09-23 09:13:40 UTC
[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.
Comment 58 Christian Herrmann 2008-09-23 09:23:41 UTC
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.
Comment 59 ykzhao 2008-12-02 21:42:30 UTC
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.
Comment 60 ykzhao 2008-12-02 21:47:32 UTC
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.
Comment 61 Christian Herrmann 2008-12-04 10:44:13 UTC
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)
Comment 62 ykzhao 2008-12-07 06:07:39 UTC
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.
Comment 63 Christian Herrmann 2008-12-07 06:58:58 UTC
Created attachment 19192 [details]
comment 59 / b: lspci -vxxx > lspci_acpi_off;
Comment 64 Christian Herrmann 2008-12-07 07:00:00 UTC
Created attachment 19193 [details]
comment 59 / d: lspci -vxxx > lspci_acpi_trans;
Comment 65 Christian Herrmann 2008-12-07 07:03:23 UTC
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.
Comment 66 ykzhao 2008-12-11 02:06:30 UTC
Hi, Christian
    Please attach the output of lspci -vxxx instead of lspci -vxx when doing the test.
    Thanks
Comment 67 ykzhao 2008-12-17 00:51:56 UTC
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.
Comment 68 Christian Herrmann 2008-12-20 09:22:23 UTC
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
Comment 69 Christian Herrmann 2008-12-20 09:33:45 UTC
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
Comment 70 Christian Herrmann 2008-12-20 09:35:22 UTC
Created attachment 19401 [details]
comment 66 / b: lspci -vxxx > lspci_acpi_off;
Comment 71 Christian Herrmann 2008-12-20 09:36:24 UTC
Created attachment 19402 [details]
comment 59 / d: lspci -vxxx > lspci_acpi_trans;
Comment 72 Christian Herrmann 2008-12-20 09:36:35 UTC
Created attachment 19403 [details]
comment 66 / d: lspci -vxxx > lspci_acpi_trans;
Comment 73 ykzhao 2008-12-22 00:54:47 UTC
Created attachment 19419 [details]
The S5 SLP_TYPE value is written to PM1A control register after acpi full initialization
Comment 74 ykzhao 2008-12-22 00:55:51 UTC
Created attachment 19420 [details]
The S5 SLP_TYPE value is written to PM1A control register after scanning pci device
Comment 75 ykzhao 2008-12-22 01:00:54 UTC
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.
    
Comment 76 ykzhao 2008-12-22 01:19:42 UTC
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.
Comment 77 ykzhao 2008-12-22 01:23:56 UTC
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.
Comment 78 Christian Herrmann 2008-12-22 13:33:22 UTC
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
Comment 79 ykzhao 2008-12-22 16:57:07 UTC
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.
    
Comment 80 ykzhao 2008-12-22 22:39:36 UTC
*** Bug 12183 has been marked as a duplicate of this bug. ***
Comment 81 Johannes Römer 2008-12-24 05:48:56 UTC
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?).
Comment 82 ykzhao 2008-12-24 21:19:40 UTC
Created attachment 19478 [details]
The S5 SLP_TYP value is written to PM1A control register after building ACPI device tree
Comment 83 ykzhao 2008-12-24 21:26:37 UTC
Created attachment 19479 [details]
The S5 SLP_TYP value is written to PM1A control register after initializing EC driver
Comment 84 ykzhao 2008-12-24 21:32:18 UTC
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.
Comment 85 ykzhao 2008-12-25 01:40:18 UTC
Created attachment 19480 [details]
The S5 SLP_TYP value is written to PM1A control register after building ACPI device tree
Comment 86 ykzhao 2008-12-25 01:40:38 UTC
Created attachment 19481 [details]
The S5 SLP_TYP value is written to PM1A control register after initializing EC driver
Comment 87 ykzhao 2008-12-25 01:42:37 UTC
Hi, 
   Sorry for the typo:)
   Will you please try the debug patch in comment #85/86 ?
   thanks.
   
Comment 88 Johannes Römer 2008-12-26 06:32:44 UTC
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...).
Comment 89 ykzhao 2008-12-28 22:41:16 UTC
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.
Comment 90 Johannes Römer 2008-12-30 05:21:48 UTC
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.
Comment 91 Pablo 2008-12-30 16:19:22 UTC
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...
Comment 92 Pablo 2008-12-30 16:32:42 UTC
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
Comment 93 ykzhao 2008-12-30 21:12:31 UTC
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.
Comment 94 Pablo 2008-12-31 06:28:21 UTC
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
Comment 95 eujedi 2009-01-05 07:15:56 UTC
If this info does help in any way - FreeBSD comes with the same poweroff problem 
Comment 96 Arkadiusz 2009-02-14 09:40:24 UTC
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
Comment 97 ykzhao 2009-03-04 17:43:21 UTC
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.
Comment 98 ykzhao 2009-03-04 17:46:46 UTC
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.
Comment 99 Arkadiusz 2009-03-05 03:35:24 UTC
Shuld i try #97 patch with patch #73, #85, #86 or without?
Comment 100 Arkadiusz 2009-03-05 10:18:08 UTC
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.
Comment 101 ykzhao 2009-03-05 17:08:36 UTC
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.
Comment 102 Len Brown 2009-04-01 02:44:02 UTC
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.
Comment 103 Arkadiusz 2009-04-02 21:05:36 UTC
if you mean adding maxcpus=1 to menu.lst then it does not make any difference, I checked.
Comment 104 ykzhao 2009-04-10 16:00:19 UTC
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.
Comment 105 Zhang Rui 2009-05-05 06:48:35 UTC
ping ...
Comment 106 Arkadiusz 2009-05-05 12:29:08 UTC
(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 ).
Comment 107 Torsten Römer 2009-05-17 12:23:16 UTC
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
Comment 108 Arkadiusz 2009-05-17 13:54:39 UTC
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.
Comment 109 Torsten Römer 2009-06-08 21:17:27 UTC
Bug is assigned? Great! So can we hope for a patch :-)

Please let me know if I can contribute!

Torsten
Comment 110 ykzhao 2009-06-09 00:38:14 UTC
HI, Torsten
    Sorry that I have no idea about this bug. The status of this bug is changed to assigned from needinfo.
    Thanks.
Comment 111 ykzhao 2009-06-19 01:57:13 UTC
*** Bug 12348 has been marked as a duplicate of this bug. ***
Comment 112 Pablo 2009-06-28 13:47:08 UTC
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,
Comment 113 ykzhao 2009-07-06 01:57:12 UTC
*** Bug 12694 has been marked as a duplicate of this bug. ***
Comment 114 邱焜 2009-07-08 16:14:07 UTC
Sure, im commit for the bug 12694. 
i want to say that grub can halt normoally as push the power button in the end.
Comment 115 Torsten Römer 2009-07-08 20:02:19 UTC
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?
Comment 116 arond 2010-04-11 22:08:06 UTC
Hi, i just started having very similar problems. Check bug 15698. Same behaviour on a newer kernel...
Comment 117 Torsten Römer 2010-04-12 12:18:49 UTC
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
Comment 118 Zhang Rui 2010-09-03 02:11:04 UTC
Yakui, any update on this?
Comment 119 ykzhao 2010-12-28 05:15:42 UTC
I have no idea about this bug. We tried several methods but the box still can't be powered off.

Thanks
Comment 120 Torsten Römer 2010-12-29 10:46:03 UTC
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.
Comment 121 Len Brown 2011-01-18 07:27:51 UTC
please try booting with "acpi_osi="
and report if any difference.

please attach the complete dmesg from the latest stable kernel
Comment 122 Torsten Römer 2011-01-24 23:29:49 UTC
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=
Comment 123 Len Brown 2011-08-01 04:27:00 UTC
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.
Comment 124 camelseller 2011-08-30 17:15:29 UTC
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
Comment 125 Zhang Rui 2012-01-18 01:35:31 UTC
It's great that kernel bugzilla is back.

can you please verify if the problem still exists in the latest upstream kernel?
Comment 126 camelseller 2012-01-18 17:19:16 UTC
:-) 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!
Comment 127 Torsten Römer 2012-01-18 19:45:40 UTC
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
Comment 128 Alan 2012-05-17 14:26:34 UTC
https://wiki.ubuntu.com/DebuggingKernelSuspend

may be helpful in showing how to go about this.
Comment 129 Aaron Lu 2013-03-13 06:33:31 UTC
Anyone still has this problem on latest upstream kernel?
Comment 130 Zhang Rui 2013-04-25 04:31:33 UTC
ping...
Comment 131 Torsten Römer 2013-04-25 12:58:06 UTC
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.
Comment 132 Jan Willies 2013-04-25 13:11:35 UTC
Sorry I can't help either. I still have the laptop somewhere but the powerconnector is broken, so it's basically useless.
Comment 133 Zhang Rui 2013-04-26 08:04:52 UTC
okay.
bug closed.
please feel free to reopen it once you can reproduce the problem.
Comment 134 Paolo Lav 2013-06-17 10:52:30 UTC
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
Comment 135 Horst Schirmeier 2013-10-28 09:05:15 UTC
Still a bug on 3.11.0, reproducible on Ubuntu 13.10 (i686).
Comment 136 Torsten Römer 2013-10-28 10:09:15 UTC
Couldn't this be a BIOS quirk that Windows has a fix for, since power-off works fine on other machines?

Note You need to log in before you can comment on or make changes to this bug.