Latest working kernel version: 126.96.36.199
Earliest failing kernel version: 2.6.28 [probably]
Hardware Environment: Sony Vaio SR19XN
when the system goes for shutdown it does not poweroff, staying up with console, working switch but not working console [console switch exception excluded]
Steps to reproduce:
- poweroff button
- halt command
Created attachment 19789 [details]
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?
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.
thanks to you =)
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.
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.
Created attachment 19818 [details]
./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?
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 188.8.131.52/2.6.28/2.6.29-rc1?
It is noted that you had better use the command of "poweroff".
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
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 184.108.40.206 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.
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?
Sorry, probably also this time i did'n make it clear.
With kernel 220.127.116.11 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
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?
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
Author: Takashi Iwai <firstname.lastname@example.org>
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.
- Avoid EXPORT_SYMBOL*() when built-in kernel
- Restore __devinit appropriately depending on the condition
Signed-off-by: Takashi Iwai <email@example.com>
: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 ***