Created attachment 19789 [details]
kernel 2.6.29-rc1-git3

Created attachment 19790 [details]
dmesg from boot to shutdown

Created attachment 19791 [details]
dmesg from boot to shutdown

Created attachment 19792 [details]
complete dmesg from boot to shutdown

i want to add that the config is quite the same i used on the 2.6.27-7;

i've also tried to use the old 2.6.27-config on the 2.6.29-rc1-git3 doing "make oldconfig" and asking the default values to all questions, but the buolded kernel has the same problem of a faulty poweroff.

are there some test i can do helping you solving the bug?

thanks.

It would be useful to know if 2.6.28 has this regression, please.

thanks andrew =) i remember to had the problem in the 2.6.28 but i dont remember if i had it in all the git

i'm going to test it doing bisect in the 2.6.28.

all right andrew.. it seems a regression for the 2.6.29;

the http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.tar.bz2 it's safe =)

do you need any other information ? 

Nope, that's fine, thanks.

As it's a post-2.6.28 regression it will go into Rafael's list and will
hopefully get more urgent attention.

great.

thanks to you =)

Hi, Giovanni
    From the problem description it seems that this is a regression. Will you please use git-bisect to identify the bad commit which causes this regression?
    Of course please attach the output of acpidump.
    Thanks.

Created attachment 19811 [details]
use the attached I/O port tool to write some I/O port

Will you please do the following test on the kernel of 2.6.29-rc1 and see whether the system can be shutdown?
   > write 0x3C01 to 0x404 I/O port
   How to use the I/O port tool can be found in the readme.
   Thanks.

Created attachment 19818 [details]
acpi dump

./iow --addr 0x404 --width 8 --value 0x3C01

ok with this command it does work !
the system shutdown immediately on the 2.6.29-rc1-git3;

you need some other? 

Hi, Giovanni
    Thanks for the confirm.
    From the test in comment #14 we know that the box can be shutdown by writing the 0x3C01 to PM1A control register. In fact the last step of shutdown(entering S5) is also to write the 0x3C01 to PM1A control register. But unfortunately it can't work on the 2.6.28 kernel.
    Will you please double check whether the box can be shutdown on the 2.6.27.10/2.6.28/2.6.29-rc1? 
    It is noted that you had better use the command of "poweroff".
    Thanks.
    
    

sorry, but i dont understand your question;

on the 2.6.27 the poweroff works doing "halt", and also on the current 2.6.28;
on the 2.6.29-rc1 it dows word with the write you suggest

Hi, Giovanni
    Sorry that I don't make it more clear.
    From the test in comment #14 it seems that the box is shutdown by writing 0x3C01 to PM1A control register directly. But in fact the last step of shutdown is also to write 0x3C01 to PM1A control register, which is done in Linux ACPI.  
    Unfortunately shutdown can't work well on the 2.6.28 kernel.
    Is the above clear?
    Will you please double check it? (Using the command of "poweroff"). 
    

No problem Zhao, probably i didn't make it clear;
fro me on 2.6.27.7 and 2.6.28 it does poweroff using "poweroff", it dowss not work starting from 2.6.29.

i've also re-done a test for the 2.6.28 with "poweroff" command and it does work.

Hi, Giovanni
    Thanks for the confirmation. It seems that it also works well on the 2.6.28 kernel.
    Do you mean it can't work on the 2.6.29-rc1?
    If so, please confirm it. If it can't work, will you please use the git-bisect to identify the first bad commit?
    Thanks. 

Sorry, probably also this time i did'n make it clear.

With kernel 2.6.27.7 and 2.6.28 i can poweroff the laptop using "halt" and using the write ./iow --addr 0x404 --width 32 --value 0x3C01

Using the 2.6.28 rc1 instead i cant only poweroff the laptop using the write.

that being so, what information do you need?

thanks for all

Hi, Giovanni
    thanks for the confirm.
    It seems that the system can't be shutdown by using the command of "poweroff" on the 2.6.29-rc1 kernel. But it can be shutdown by direct I/O write. Right?
    Will you please use the git-bisect to identify the bad commit?
    Thanks.
    

Here is the git response:

it seems not to be an acpi problem! lulz
it's an alsa module problem, related to the hda audio driver!
really really strange ...  probably i've to enter a new bug?

here is the output

1289e9e8b42f973f2ab39e5f4f2239ff826c27e9 is first bad commit
commit 1289e9e8b42f973f2ab39e5f4f2239ff826c27e9
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 27 15:47:11 2008 +0100

    ALSA: hda - Modularize HD-audio driver

    Split the monolithc HD-audio driver into several pieces:
     - snd-hda-intel   HD-audio PCI controller driver; loaded via udev
     - snd-hda-codec   HD-audio codec bus driver
     - snd-hda-codec-* Specific HD-audio codec drivers

    When built as modules, snd-hda-codec (that is invoked by snd-hda-intel)
    looks up the codec vendor ID and loads the corresponding codec module
    automatically via request_module().

    When built in a kernel, each codec drivers are statically hooked up
    before probing the PCI.

    This patch adds appropriate EXPORT_SYMBOL_GPL()'s and the module
    information for each driver, and driver-linking codes between
    codec-bus and codec drivers.

    TODO:
      - Avoid EXPORT_SYMBOL*() when built-in kernel
      - Restore __devinit appropriately depending on the condition

    Signed-off-by: Takashi Iwai <tiwai@suse.de>

:040000 040000 b0a71438bd4110e07491ed00710449532a3dbd15 ebeda50646e1fbea8dd9f31040133b307bf5d8f6 M      sound

It's likely a bug in gentoo alsasound init script.


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