Re: regression in 2.6.23-rc8 - power off failed: solved
On Mon, Oct 08, 2007 at 11:48:40AM -0700, H. Peter Anvin wrote: > > Does your .config file have CONFIG_APM=y? Otherwise, that's your problem > right there (since your old laptop doesn't appear to have ACPI.) no CONFIG_APM and yes, this is my problem. A very hard way to figure this out, and too much noise. Sorry for this. It is not the first time, I had to change my .config to maintain a feature of the kernel after an upgrade. I think, you are aware of this an I have no suggestion for improvement. Now this old laptop is running perfectly again with the latest kernel. Thankyou for this, Wolfgang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed: solved
On Mon, Oct 08, 2007 at 11:48:40AM -0700, H. Peter Anvin wrote: Does your .config file have CONFIG_APM=y? Otherwise, that's your problem right there (since your old laptop doesn't appear to have ACPI.) no CONFIG_APM and yes, this is my problem. A very hard way to figure this out, and too much noise. Sorry for this. It is not the first time, I had to change my .config to maintain a feature of the kernel after an upgrade. I think, you are aware of this an I have no suggestion for improvement. Now this old laptop is running perfectly again with the latest kernel. Thankyou for this, Wolfgang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
On Monday, 1 October 2007 19:55, Alexey Starikovskiy wrote:
> Rafael J. Wysocki wrote:
> > On Saturday, 29 September 2007 22:47, Bill Davidsen wrote:
> >> Alexey Starikovskiy wrote:
> >>
> >>> -static void
> >>> -acpi_power_off (void)
> >>> -{
> >>> - printk("%s called\n",__FUNCTION__);
> >>> - /* Some SMP machines only can poweroff in boot CPU */
> >>> - set_cpus_allowed(current, cpumask_of_cpu(0));
> >>> ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
> >>> Later only comment was left for some reason...
> >>>
> >> Am I midreading that code, or does it really assume that the boot cpu is
> >> always zero? Or just that zero will be able to do the power off?
> >>
> >> In any case I have had an SMP machine which did not have a CPU zero, and
> >> it was discussed here, I believe. Wonder what happens if you set
> >> affinity to a CPU you don't have...
> >
> > Good question, but it also caused other problems to appear, IIRC.
> >
> > IMHO, it's better to call disable_nonboot_cpus() in an appropriate place
> > anyway.
> >
> > Greetings,
> > Rafael
> Ok, here is commit which removed the code in question from acpi_power_off:
>
> commit 6660316cb7a1a2c59a73a52870490c0f782f45c1
> Author: Eric W. Biederman <[EMAIL PROTECTED]>
> Date: Tue Jul 26 12:16:00 2005 -0600
>
> [PATCH] acpi_power_off: Don't switch to the boot cpu
>
> machine_power_off on i386 and x86_64 now switch to the
> boot cpu out of paranoia and because the MP Specification indicates it
> is a good idea on reboot, so for those architectures it is a noop.
> I can't see anything in the acpi spec that requires you to be on
> the boot cpu to power off the system, so this should not be an issue
> for ia64. In addition ia64 has the altix a massive multi-node
> system where switching to the boot cpu sounds insane as we may
> hot removed the boot cpu.
>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
I see. :-)
Anyway, I think we should atually go UP before executing sysdev_shutdown().
How we are going to do that is another matter.
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Rafael J. Wysocki wrote:
On Saturday, 29 September 2007 22:47, Bill Davidsen wrote:
Alexey Starikovskiy wrote:
-static void
-acpi_power_off (void)
-{
- printk("%s called\n",__FUNCTION__);
- /* Some SMP machines only can poweroff in boot CPU */
- set_cpus_allowed(current, cpumask_of_cpu(0));
ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
Later only comment was left for some reason...
Am I midreading that code, or does it really assume that the boot cpu is
always zero? Or just that zero will be able to do the power off?
In any case I have had an SMP machine which did not have a CPU zero, and
it was discussed here, I believe. Wonder what happens if you set
affinity to a CPU you don't have...
Good question, but it also caused other problems to appear, IIRC.
IMHO, it's better to call disable_nonboot_cpus() in an appropriate place
anyway.
Greetings,
Rafael
Ok, here is commit which removed the code in question from acpi_power_off:
commit 6660316cb7a1a2c59a73a52870490c0f782f45c1
Author: Eric W. Biederman <[EMAIL PROTECTED]>
Date: Tue Jul 26 12:16:00 2005 -0600
[PATCH] acpi_power_off: Don't switch to the boot cpu
machine_power_off on i386 and x86_64 now switch to the
boot cpu out of paranoia and because the MP Specification indicates it
is a good idea on reboot, so for those architectures it is a noop.
I can't see anything in the acpi spec that requires you to be on
the boot cpu to power off the system, so this should not be an issue
for ia64. In addition ia64 has the altix a massive multi-node
system where switching to the boot cpu sounds insane as we may
hot removed the boot cpu.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Regards,
Alex.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Rafael J. Wysocki wrote:
On Saturday, 29 September 2007 22:47, Bill Davidsen wrote:
Alexey Starikovskiy wrote:
-static void
-acpi_power_off (void)
-{
- printk(%s called\n,__FUNCTION__);
- /* Some SMP machines only can poweroff in boot CPU */
- set_cpus_allowed(current, cpumask_of_cpu(0));
ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
Later only comment was left for some reason...
Am I midreading that code, or does it really assume that the boot cpu is
always zero? Or just that zero will be able to do the power off?
In any case I have had an SMP machine which did not have a CPU zero, and
it was discussed here, I believe. Wonder what happens if you set
affinity to a CPU you don't have...
Good question, but it also caused other problems to appear, IIRC.
IMHO, it's better to call disable_nonboot_cpus() in an appropriate place
anyway.
Greetings,
Rafael
Ok, here is commit which removed the code in question from acpi_power_off:
commit 6660316cb7a1a2c59a73a52870490c0f782f45c1
Author: Eric W. Biederman [EMAIL PROTECTED]
Date: Tue Jul 26 12:16:00 2005 -0600
[PATCH] acpi_power_off: Don't switch to the boot cpu
machine_power_off on i386 and x86_64 now switch to the
boot cpu out of paranoia and because the MP Specification indicates it
is a good idea on reboot, so for those architectures it is a noop.
I can't see anything in the acpi spec that requires you to be on
the boot cpu to power off the system, so this should not be an issue
for ia64. In addition ia64 has the altix a massive multi-node
system where switching to the boot cpu sounds insane as we may
hot removed the boot cpu.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
Regards,
Alex.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
On Monday, 1 October 2007 19:55, Alexey Starikovskiy wrote:
Rafael J. Wysocki wrote:
On Saturday, 29 September 2007 22:47, Bill Davidsen wrote:
Alexey Starikovskiy wrote:
-static void
-acpi_power_off (void)
-{
- printk(%s called\n,__FUNCTION__);
- /* Some SMP machines only can poweroff in boot CPU */
- set_cpus_allowed(current, cpumask_of_cpu(0));
ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
Later only comment was left for some reason...
Am I midreading that code, or does it really assume that the boot cpu is
always zero? Or just that zero will be able to do the power off?
In any case I have had an SMP machine which did not have a CPU zero, and
it was discussed here, I believe. Wonder what happens if you set
affinity to a CPU you don't have...
Good question, but it also caused other problems to appear, IIRC.
IMHO, it's better to call disable_nonboot_cpus() in an appropriate place
anyway.
Greetings,
Rafael
Ok, here is commit which removed the code in question from acpi_power_off:
commit 6660316cb7a1a2c59a73a52870490c0f782f45c1
Author: Eric W. Biederman [EMAIL PROTECTED]
Date: Tue Jul 26 12:16:00 2005 -0600
[PATCH] acpi_power_off: Don't switch to the boot cpu
machine_power_off on i386 and x86_64 now switch to the
boot cpu out of paranoia and because the MP Specification indicates it
is a good idea on reboot, so for those architectures it is a noop.
I can't see anything in the acpi spec that requires you to be on
the boot cpu to power off the system, so this should not be an issue
for ia64. In addition ia64 has the altix a massive multi-node
system where switching to the boot cpu sounds insane as we may
hot removed the boot cpu.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
I see. :-)
Anyway, I think we should atually go UP before executing sysdev_shutdown().
How we are going to do that is another matter.
Greetings,
Rafael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Wolfgang Erig wrote: > Hi Peter, > > On Sat, Sep 29, 2007 at 11:35:53AM +0200, Wolfgang Erig wrote: >> I start again with a fresh tree and better controlled experiments. > > now the result of bisection seems to be consistent. > > The last good commit is > f2d98ae63dc64dedb00499289e13a50677f771f9 Linker script for the new x86 setup > code > > The first bad commit (no power off) is > 4fd06960f120e02e9abc802a09f9511c400042a5 Use the new x86 setup code for i386 > > Now I try the things written in > http://marc.info/[EMAIL PROTECTED] > OK, that makes more sense. I'll look at this on Monday. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
On Saturday, 29 September 2007 22:47, Bill Davidsen wrote:
> Alexey Starikovskiy wrote:
>
> > -static void
> > -acpi_power_off (void)
> > -{
> > - printk("%s called\n",__FUNCTION__);
> > - /* Some SMP machines only can poweroff in boot CPU */
> > - set_cpus_allowed(current, cpumask_of_cpu(0));
> > ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
> > Later only comment was left for some reason...
> >
> Am I midreading that code, or does it really assume that the boot cpu is
> always zero? Or just that zero will be able to do the power off?
>
> In any case I have had an SMP machine which did not have a CPU zero, and
> it was discussed here, I believe. Wonder what happens if you set
> affinity to a CPU you don't have...
Good question, but it also caused other problems to appear, IIRC.
IMHO, it's better to call disable_nonboot_cpus() in an appropriate place
anyway.
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Alexey Starikovskiy wrote:
-static void
-acpi_power_off (void)
-{
- printk("%s called\n",__FUNCTION__);
- /* Some SMP machines only can poweroff in boot CPU */
- set_cpus_allowed(current, cpumask_of_cpu(0));
ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
Later only comment was left for some reason...
Am I midreading that code, or does it really assume that the boot cpu is
always zero? Or just that zero will be able to do the power off?
In any case I have had an SMP machine which did not have a CPU zero, and
it was discussed here, I believe. Wonder what happens if you set
affinity to a CPU you don't have...
--
Bill Davidsen <[EMAIL PROTECTED]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Hi Peter, On Sat, Sep 29, 2007 at 08:07:21PM +0200, Wolfgang Erig wrote: > > Now I try the things written in > http://marc.info/[EMAIL PROTECTED] I have dumped a memory region which is my understanding what you want to see. The difference between the good and the bad case is only the patch "4fd06960f120e02e9abc802a09f9511c400042a5 Use the new x86 setup code for i386" I modified arch/i386/kernel/setup.c and dumped 4K of /dev/kmem at the address of boot_params. Good case: c0457340 > 00 08 fc ff 00 00 03 50 8c c8 03 00 8e c0 19 01 < ...P c0457350 > 10 00 7c fb fc be 31 00 ac 20 c0 74 09 b4 0e bb < ..|...1.. .t c0457360 > 07 00 cd 10 eb f2 31 c0 cd 16 cd 19 ea f0 ff 00 < ..1. c0457370 > f0 < . c0457371 "Direct booting " c0457380 > 02 01 00 f0 ff 96 00 00 00 f0 40 00 03 00 ff ff < [EMAIL PROTECTED] c0457390 > ff ff ff ff < c0457394 "nger supported." c04573a3 > 0d 0a< .. c04573a5 "Please use a boot loader prp4" c04573c2 > 0f 00 00 00 00 00 08 00 00 00 70 34 3f < ..p4? c04573cf11 * 00 c04573e0 > 08 00 fc 01 00 74 00 00 00 00 < .t c04573ea " key to reboot . . ." c04573fe > 0d 0a< .. c0457400 121 * 00 c0457521 > fc 01 00 00 00 09 00 05 00 00 00 00 00 00 00 00 < c0457531 > 0e 01 00 f4 a4 01 00 00 00 00 0f 02 08 55 aa eb < .U.. c0457541 ":HdrS" c0457546 > 06 02 00 00 00 00 00 10 7f 11 71 81 00 80 00 00 < ..q. c0457556 > 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8e < c0457566 > 00 00 00 90 09 00 ff ff ff 1f 00 00 10 00 00 00 < c0457576 > 00 00 ff 07 00 00 e8 c1 0c 90 < .. c045758099 * 00 c0457619 > fc 09 00 00 00 00 00 01 00 00 00 00 fc 09 00 00 < c0457629 > 00 00 00 00 04 00 00 00 00 00 00 02 00 00 00 3a < ...: c0457639 > 12 0f 00 00 00 00 00 c6 ed 00 00 00 00 00 00 02 < c0457649 > 00 00 00 00 00 10 00 00 00 00 00 00 00 f0 07 00 < c0457659 > 00 00 00 01 00 00 00 3a 12 ff ff 00 00 00 00 c6 < ...: c0457669 > ed 00 00 00 00 00 00 02 < c0457671 bcf * 00 c0458240 > b8 00 15 b2 81 cd 13 8c c8 8e d8 81 3e a5 1b 55 < >..U c0458250 > aa 75 4c 81 3e a7 1b < .uL.>.. c0458257 "ZZuD" c045825b > eb 40 ac 20 c0 74 05 e8 08 00 eb f6 c3 e8 00 00 < [EMAIL PROTECTED] .t.. c045826b > b0 20 50 51 bb 07 00 b9 01 00 b4 0e cd 10 59 58 < . PQ..YX c045827b > c3 b0 07 eb ed < . c0458280 "No setup signature found ..." c045829c > 00 eb 4f 8c c8 83 e8 20 8e d8 30 ff 8a 1e f1 01 < ..O ..0. c04582ac > 83 eb 04 c1 e3 08 89 d9 c1 eb 03 81 c3 00 10 2e < c04582bc > 89 1e 0c 00 bf 00 08 29 f6 0e 07 b8 00 10 8e d8 < ...) c04582cc > f3 a5 8c c8 8e d8 81 3e a5 1b 55 aa 75 0a 81 3e < ...>..U.u..> c04582dc > a7 1b 5a 5a 75 02 eb 0a 8d 36 40 0d e8 72 ff f4 < [EMAIL PROTECTED] c04582ec > eb fd 8c c8 83 e8 20 8e d8 2e f6 06 11 00 01 74 < .. t c04582fc > 2e 2e 80 3e 10 00 00 75 26 0e 1f 8d 36 d0 0d e8 < ...>...u&...6... c045830c > 4f ff eb db < O... c0458310 "Wrong loader, giving up..." c045832a > 00 e8 36 00 66 85 c0 74 61 8c c8 8e d8 8d 36 00 < ..6.f..ta.6. c045833a > 0e e8 1f ff eb fe< .. Bad case: c0457340 > 00 08 00 00 00 00 03 50 00 00 03 00 00 00 19 01 < ...P c0457350 > 10 < . c04573514f * 00 c04573a0 > 80 86 00 00 00 00 00 00 00 00 00 00 < c04573ac "CISG" c04573b030 * 00 c04573e0 > 08 00 fc 01 00 74< .t c04573e6 13e * 00 c0457524 > e0 29 09 00 05 00 00 00 00 00 00 00 00 13 01 00 < .).. c0457534 > fa a4 01 00 00 00 ff ff 02 08 55 aa eb < ..U.. c0457541 ":HdrS" c0457546 > 06 02 00 00 00 00 00 10 3c 23 71 81 00 80 00 00 < <#q. c0457556 > 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8e < c0457566 > 00 00 00 90 09 00 ff ff ff 1f 00 00 10 < . c0457573a6 * 00 c0457619 > fc 09 00 00 00 00 00 01 00 00 00 00 fc 09 00 00 < c0457629 > 00 00 00 00 04 00 00 00 00 00 00 02 00 00 00 3a < ...: c0457639 > 12 0f 00 00 00 00 00 c6 ed 00 00 00 00 00 00 02 < c0457649 > 00 00 00 00 00 10 00 00 00 00 00 00 00 f0 07 00 < c0457659 > 00 00 00 01 00 00 00 3a 12 ff ff 00 00 00 00 c6 < ...: c0457669 > ed 00 00 00 00 00 00 02 < c0457671 ccf * 00 $ cat /proc/cmdline root=/dev/hda1 Wolfgang - To unsubscribe from this list: send
Re: regression in 2.6.23-rc8 - power off failed
Hi Peter, On Sat, Sep 29, 2007 at 11:35:53AM +0200, Wolfgang Erig wrote: > > I start again with a fresh tree and better controlled experiments. now the result of bisection seems to be consistent. The last good commit is f2d98ae63dc64dedb00499289e13a50677f771f9 Linker script for the new x86 setup code The first bad commit (no power off) is 4fd06960f120e02e9abc802a09f9511c400042a5 Use the new x86 setup code for i386 Now I try the things written in http://marc.info/[EMAIL PROTECTED] Wolfgang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Mark Lord wrote:
Wolfgang Erig wrote:
On Sat, Sep 29, 2007 at 01:30:33AM -0700, H. Peter Anvin wrote:
Wolfgang Erig wrote:
Both are bad.
Two different systems and two different bisections.
I sent the last step of each.
$ git bisect good Bisecting: 0 revisions left to test after this
[626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and
main routine for new x86 setup code
OK, so which one is the bad one?
This problem (no power off) persists after pull some minutes ago.
Sorry for the confusion.
I believe there must have been something wrong here (possibly
inconsistent experiments?) This checkin has *zero code changes* from
the previous one (and next one) -- the kernel should have been binarily
identical to the previous one. The code introduced in this checkin
doesn't even get compiled until two checkins later,
4fd06960f120e02e9abc802a09f9511c400042a5.
I have done two bisections simultanously and it was late at night.
I start again with a fresh tree and better controlled experiments.
If this is an SMP system, then you could just be getting random results,
depending upon which CPU is attempting the poweroff.
I have a newish patch in Andrew's tree now to fix SMP poweroff
(has been broken forever), reproduced here below in case you missed it.
* * *
We need to disable all CPUs other than the boot CPU (usually 0)
before attempting to power-off modern SMP machines.
This fixes the hang-on-poweroff issue on my MythTV SMP box,
and also on Thomas Gleixner's new toybox.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
Acked-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
--- linux/kernel/sys.c.orig2007-09-13 09:49:11.0 -0400
+++ linux/kernel/sys.c2007-09-28 15:48:54.0 -0400
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -878,6 +879,7 @@
kernel_shutdown_prepare(SYSTEM_POWER_OFF);
if (pm_power_off_prepare)
pm_power_off_prepare();
+disable_nonboot_cpus();
sysdev_shutdown();
printk(KERN_EMERG "Power down.\n");
machine_power_off();
-static void
-acpi_power_off (void)
-{
- printk("%s called\n",__FUNCTION__);
- /* Some SMP machines only can poweroff in boot CPU */
- set_cpus_allowed(current, cpumask_of_cpu(0));
ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
Later only comment was left for some reason...
Regards,
Alex.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Wolfgang Erig wrote: On Sat, Sep 29, 2007 at 01:30:33AM -0700, H. Peter Anvin wrote: Wolfgang Erig wrote: Both are bad. Two different systems and two different bisections. I sent the last step of each. $ git bisect good Bisecting: 0 revisions left to test after this [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine for new x86 setup code OK, so which one is the bad one? This problem (no power off) persists after pull some minutes ago. Sorry for the confusion. I believe there must have been something wrong here (possibly inconsistent experiments?) This checkin has *zero code changes* from the previous one (and next one) -- the kernel should have been binarily identical to the previous one. The code introduced in this checkin doesn't even get compiled until two checkins later, 4fd06960f120e02e9abc802a09f9511c400042a5. I have done two bisections simultanously and it was late at night. I start again with a fresh tree and better controlled experiments. If this is an SMP system, then you could just be getting random results, depending upon which CPU is attempting the poweroff. I have a newish patch in Andrew's tree now to fix SMP poweroff (has been broken forever), reproduced here below in case you missed it. * * * We need to disable all CPUs other than the boot CPU (usually 0) before attempting to power-off modern SMP machines. This fixes the hang-on-poweroff issue on my MythTV SMP box, and also on Thomas Gleixner's new toybox. Signed-off-by: Mark Lord <[EMAIL PROTECTED]> Acked-by: Thomas Gleixner <[EMAIL PROTECTED]> --- --- linux/kernel/sys.c.orig 2007-09-13 09:49:11.0 -0400 +++ linux/kernel/sys.c 2007-09-28 15:48:54.0 -0400 @@ -32,6 +32,7 @@ #include #include #include +#include #include #include @@ -878,6 +879,7 @@ kernel_shutdown_prepare(SYSTEM_POWER_OFF); if (pm_power_off_prepare) pm_power_off_prepare(); + disable_nonboot_cpus(); sysdev_shutdown(); printk(KERN_EMERG "Power down.\n"); machine_power_off(); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
On Sat, Sep 29, 2007 at 01:30:33AM -0700, H. Peter Anvin wrote: > Wolfgang Erig wrote: > > Both are bad. > > Two different systems and two different bisections. > > I sent the last step of each. > > >>> $ git bisect good > >>> Bisecting: 0 revisions left to test after this > >>> [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main > >>> routine for new x86 setup code > >> OK, so which one is the bad one? > > > > This problem (no power off) persists after pull some minutes ago. > > Sorry for the confusion. > > > > I believe there must have been something wrong here (possibly > inconsistent experiments?) This checkin has *zero code changes* from > the previous one (and next one) -- the kernel should have been binarily > identical to the previous one. The code introduced in this checkin > doesn't even get compiled until two checkins later, > 4fd06960f120e02e9abc802a09f9511c400042a5. I have done two bisections simultanously and it was late at night. I start again with a fresh tree and better controlled experiments. Wolfgang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed on old laptop
On Fri, Sep 28, 2007 at 06:11:16PM -0700, H. Peter Anvin wrote: > Wolfgang Erig wrote: > > Hi, > > > > the latest kernel does not power off my old laptop. > > > > 2.6.22 succeeded > > 2.6.23-rc8 failed > > > > $ git bisect good > > Bisecting: 0 revisions left to test after this > > [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine > > for new x86 setup code > > > > Which more info is needed? > > > > A description of the system, your .config file, kernel messages (old and > new). Laptop (about 10 years old, runs perfectly with 2.6.22) from Siemens Nixdorf, Mobile 710, Pentium MMX 166 $ lspci 00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01) 00:01.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 01) 00:01.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 00:01.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01) 00:06.0 VGA compatible controller: Chips and Technologies F65554 (rev c2) 00:14.0 CardBus bridge: Cirrus Logic PD 6832 PCMCIA/CardBus Ctrlr (rev c1) 00:14.1 CardBus bridge: Cirrus Logic PD 6832 PCMCIA/CardBus Ctrlr (rev c1) The last kernel messages written from the screen: - good case - Deactivating swap...done. Will now halt. Shutdown: hda Power down. (power off) I'm not absolutely shure about the messages because it runs very fast. - bad case - Deactivating swap...done. Will now halt. Shutdown: hda System halted. _ (blinking cursor) .config is attached. Thankyou, Wolfgang # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22 # Sat Sep 29 01:31:40 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_LSF=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set CONFIG_M586MMX=y # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y
Re: regression in 2.6.23-rc8 - power off failed
Wolfgang Erig wrote: > Both are bad. > Two different systems and two different bisections. > I sent the last step of each. >>> $ git bisect good >>> Bisecting: 0 revisions left to test after this >>> [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine >>> for new x86 setup code >> OK, so which one is the bad one? > > This problem (no power off) persists after pull some minutes ago. > Sorry for the confusion. > I believe there must have been something wrong here (possibly inconsistent experiments?) This checkin has *zero code changes* from the previous one (and next one) -- the kernel should have been binarily identical to the previous one. The code introduced in this checkin doesn't even get compiled until two checkins later, 4fd06960f120e02e9abc802a09f9511c400042a5. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Both are bad. Two different systems and two different bisections. I sent the last step of each. On Fri, Sep 28, 2007 at 08:05:15PM -0700, H. Peter Anvin wrote: > Wolfgang Erig wrote: > > Hi, > > > > the latest kernel does not power off my system. > > > > 2.6.22 succeeded > > 2.6.23-rc8 failed > > > > $ git bisect bad > > Bisecting: 0 revisions left to test after this > > [f216cc3748a3a22c2b99390fddcdafa0583791a2] ACPI: suspend: consolidate > > handling of Sx states. This is fixed for me after pulling from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Thankyou and sorry for the noise. > > > > $ git bisect good > > Bisecting: 0 revisions left to test after this > > [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine > > for new x86 setup code > > OK, so which one is the bad one? This problem (no power off) persists after pull some minutes ago. Sorry for the confusion. Wolfgang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Hi, This is known issue. Please try latest rc8-git2, it should contain the fix. Regards, Alex. Wolfgang Erig wrote: Hi, the latest kernel does not power off my system. 2.6.22 succeeded 2.6.23-rc8 failed $ git bisect bad Bisecting: 0 revisions left to test after this [f216cc3748a3a22c2b99390fddcdafa0583791a2] ACPI: suspend: consolidate handling of Sx states. Which more info is needed? Wolfgang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Hi, This is known issue. Please try latest rc8-git2, it should contain the fix. Regards, Alex. Wolfgang Erig wrote: Hi, the latest kernel does not power off my system. 2.6.22 succeeded 2.6.23-rc8 failed $ git bisect bad Bisecting: 0 revisions left to test after this [f216cc3748a3a22c2b99390fddcdafa0583791a2] ACPI: suspend: consolidate handling of Sx states. Which more info is needed? Wolfgang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Both are bad. Two different systems and two different bisections. I sent the last step of each. On Fri, Sep 28, 2007 at 08:05:15PM -0700, H. Peter Anvin wrote: Wolfgang Erig wrote: Hi, the latest kernel does not power off my system. 2.6.22 succeeded 2.6.23-rc8 failed $ git bisect bad Bisecting: 0 revisions left to test after this [f216cc3748a3a22c2b99390fddcdafa0583791a2] ACPI: suspend: consolidate handling of Sx states. This is fixed for me after pulling from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Thankyou and sorry for the noise. $ git bisect good Bisecting: 0 revisions left to test after this [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine for new x86 setup code OK, so which one is the bad one? This problem (no power off) persists after pull some minutes ago. Sorry for the confusion. Wolfgang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Wolfgang Erig wrote: Both are bad. Two different systems and two different bisections. I sent the last step of each. $ git bisect good Bisecting: 0 revisions left to test after this [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine for new x86 setup code OK, so which one is the bad one? This problem (no power off) persists after pull some minutes ago. Sorry for the confusion. I believe there must have been something wrong here (possibly inconsistent experiments?) This checkin has *zero code changes* from the previous one (and next one) -- the kernel should have been binarily identical to the previous one. The code introduced in this checkin doesn't even get compiled until two checkins later, 4fd06960f120e02e9abc802a09f9511c400042a5. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed on old laptop
On Fri, Sep 28, 2007 at 06:11:16PM -0700, H. Peter Anvin wrote: Wolfgang Erig wrote: Hi, the latest kernel does not power off my old laptop. 2.6.22 succeeded 2.6.23-rc8 failed $ git bisect good Bisecting: 0 revisions left to test after this [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine for new x86 setup code Which more info is needed? A description of the system, your .config file, kernel messages (old and new). Laptop (about 10 years old, runs perfectly with 2.6.22) from Siemens Nixdorf, Mobile 710, Pentium MMX 166 $ lspci 00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01) 00:01.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 01) 00:01.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 00:01.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01) 00:06.0 VGA compatible controller: Chips and Technologies F65554 (rev c2) 00:14.0 CardBus bridge: Cirrus Logic PD 6832 PCMCIA/CardBus Ctrlr (rev c1) 00:14.1 CardBus bridge: Cirrus Logic PD 6832 PCMCIA/CardBus Ctrlr (rev c1) The last kernel messages written from the screen: - good case - Deactivating swap...done. Will now halt. Shutdown: hda Power down. (power off) I'm not absolutely shure about the messages because it runs very fast. - bad case - Deactivating swap...done. Will now halt. Shutdown: hda System halted. _ (blinking cursor) .config is attached. Thankyou, Wolfgang # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22 # Sat Sep 29 01:31:40 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_LSF=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set CONFIG_M586MMX=y # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7
Re: regression in 2.6.23-rc8 - power off failed
On Sat, Sep 29, 2007 at 01:30:33AM -0700, H. Peter Anvin wrote: Wolfgang Erig wrote: Both are bad. Two different systems and two different bisections. I sent the last step of each. $ git bisect good Bisecting: 0 revisions left to test after this [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine for new x86 setup code OK, so which one is the bad one? This problem (no power off) persists after pull some minutes ago. Sorry for the confusion. I believe there must have been something wrong here (possibly inconsistent experiments?) This checkin has *zero code changes* from the previous one (and next one) -- the kernel should have been binarily identical to the previous one. The code introduced in this checkin doesn't even get compiled until two checkins later, 4fd06960f120e02e9abc802a09f9511c400042a5. I have done two bisections simultanously and it was late at night. I start again with a fresh tree and better controlled experiments. Wolfgang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Wolfgang Erig wrote: On Sat, Sep 29, 2007 at 01:30:33AM -0700, H. Peter Anvin wrote: Wolfgang Erig wrote: Both are bad. Two different systems and two different bisections. I sent the last step of each. $ git bisect good Bisecting: 0 revisions left to test after this [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine for new x86 setup code OK, so which one is the bad one? This problem (no power off) persists after pull some minutes ago. Sorry for the confusion. I believe there must have been something wrong here (possibly inconsistent experiments?) This checkin has *zero code changes* from the previous one (and next one) -- the kernel should have been binarily identical to the previous one. The code introduced in this checkin doesn't even get compiled until two checkins later, 4fd06960f120e02e9abc802a09f9511c400042a5. I have done two bisections simultanously and it was late at night. I start again with a fresh tree and better controlled experiments. If this is an SMP system, then you could just be getting random results, depending upon which CPU is attempting the poweroff. I have a newish patch in Andrew's tree now to fix SMP poweroff (has been broken forever), reproduced here below in case you missed it. * * * We need to disable all CPUs other than the boot CPU (usually 0) before attempting to power-off modern SMP machines. This fixes the hang-on-poweroff issue on my MythTV SMP box, and also on Thomas Gleixner's new toybox. Signed-off-by: Mark Lord [EMAIL PROTECTED] Acked-by: Thomas Gleixner [EMAIL PROTECTED] --- --- linux/kernel/sys.c.orig 2007-09-13 09:49:11.0 -0400 +++ linux/kernel/sys.c 2007-09-28 15:48:54.0 -0400 @@ -32,6 +32,7 @@ #include linux/getcpu.h #include linux/task_io_accounting_ops.h #include linux/seccomp.h +#include linux/cpu.h #include linux/compat.h #include linux/syscalls.h @@ -878,6 +879,7 @@ kernel_shutdown_prepare(SYSTEM_POWER_OFF); if (pm_power_off_prepare) pm_power_off_prepare(); + disable_nonboot_cpus(); sysdev_shutdown(); printk(KERN_EMERG Power down.\n); machine_power_off(); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Mark Lord wrote:
Wolfgang Erig wrote:
On Sat, Sep 29, 2007 at 01:30:33AM -0700, H. Peter Anvin wrote:
Wolfgang Erig wrote:
Both are bad.
Two different systems and two different bisections.
I sent the last step of each.
$ git bisect good Bisecting: 0 revisions left to test after this
[626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and
main routine for new x86 setup code
OK, so which one is the bad one?
This problem (no power off) persists after pull some minutes ago.
Sorry for the confusion.
I believe there must have been something wrong here (possibly
inconsistent experiments?) This checkin has *zero code changes* from
the previous one (and next one) -- the kernel should have been binarily
identical to the previous one. The code introduced in this checkin
doesn't even get compiled until two checkins later,
4fd06960f120e02e9abc802a09f9511c400042a5.
I have done two bisections simultanously and it was late at night.
I start again with a fresh tree and better controlled experiments.
If this is an SMP system, then you could just be getting random results,
depending upon which CPU is attempting the poweroff.
I have a newish patch in Andrew's tree now to fix SMP poweroff
(has been broken forever), reproduced here below in case you missed it.
* * *
We need to disable all CPUs other than the boot CPU (usually 0)
before attempting to power-off modern SMP machines.
This fixes the hang-on-poweroff issue on my MythTV SMP box,
and also on Thomas Gleixner's new toybox.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
Acked-by: Thomas Gleixner [EMAIL PROTECTED]
---
--- linux/kernel/sys.c.orig2007-09-13 09:49:11.0 -0400
+++ linux/kernel/sys.c2007-09-28 15:48:54.0 -0400
@@ -32,6 +32,7 @@
#include linux/getcpu.h
#include linux/task_io_accounting_ops.h
#include linux/seccomp.h
+#include linux/cpu.h
#include linux/compat.h
#include linux/syscalls.h
@@ -878,6 +879,7 @@
kernel_shutdown_prepare(SYSTEM_POWER_OFF);
if (pm_power_off_prepare)
pm_power_off_prepare();
+disable_nonboot_cpus();
sysdev_shutdown();
printk(KERN_EMERG Power down.\n);
machine_power_off();
-static void
-acpi_power_off (void)
-{
- printk(%s called\n,__FUNCTION__);
- /* Some SMP machines only can poweroff in boot CPU */
- set_cpus_allowed(current, cpumask_of_cpu(0));
ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
Later only comment was left for some reason...
Regards,
Alex.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Hi Peter, On Sat, Sep 29, 2007 at 11:35:53AM +0200, Wolfgang Erig wrote: I start again with a fresh tree and better controlled experiments. now the result of bisection seems to be consistent. The last good commit is f2d98ae63dc64dedb00499289e13a50677f771f9 Linker script for the new x86 setup code The first bad commit (no power off) is 4fd06960f120e02e9abc802a09f9511c400042a5 Use the new x86 setup code for i386 Now I try the things written in http://marc.info/[EMAIL PROTECTED] Wolfgang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Hi Peter, On Sat, Sep 29, 2007 at 08:07:21PM +0200, Wolfgang Erig wrote: Now I try the things written in http://marc.info/[EMAIL PROTECTED] I have dumped a memory region which is my understanding what you want to see. The difference between the good and the bad case is only the patch 4fd06960f120e02e9abc802a09f9511c400042a5 Use the new x86 setup code for i386 I modified arch/i386/kernel/setup.c and dumped 4K of /dev/kmem at the address of boot_params. Good case: c0457340 00 08 fc ff 00 00 03 50 8c c8 03 00 8e c0 19 01 ...P c0457350 10 00 7c fb fc be 31 00 ac 20 c0 74 09 b4 0e bb ..|...1.. .t c0457360 07 00 cd 10 eb f2 31 c0 cd 16 cd 19 ea f0 ff 00 ..1. c0457370 f0. c0457371 Direct booting c0457380 02 01 00 f0 ff 96 00 00 00 f0 40 00 03 00 ff ff [EMAIL PROTECTED] c0457390 ff ff ff ff c0457394 nger supported. c04573a3 0d 0a .. c04573a5 Please use a boot loader prp4 c04573c2 0f 00 00 00 00 00 08 00 00 00 70 34 3f ..p4? c04573cf11 * 00 c04573e0 08 00 fc 01 00 74 00 00 00 00.t c04573ea key to reboot . . . c04573fe 0d 0a .. c0457400 121 * 00 c0457521 fc 01 00 00 00 09 00 05 00 00 00 00 00 00 00 00 c0457531 0e 01 00 f4 a4 01 00 00 00 00 0f 02 08 55 aa eb .U.. c0457541 :HdrS c0457546 06 02 00 00 00 00 00 10 7f 11 71 81 00 80 00 00 ..q. c0457556 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8e c0457566 00 00 00 90 09 00 ff ff ff 1f 00 00 10 00 00 00 c0457576 00 00 ff 07 00 00 e8 c1 0c 90.. c045758099 * 00 c0457619 fc 09 00 00 00 00 00 01 00 00 00 00 fc 09 00 00 c0457629 00 00 00 00 04 00 00 00 00 00 00 02 00 00 00 3a ...: c0457639 12 0f 00 00 00 00 00 c6 ed 00 00 00 00 00 00 02 c0457649 00 00 00 00 00 10 00 00 00 00 00 00 00 f0 07 00 c0457659 00 00 00 01 00 00 00 3a 12 ff ff 00 00 00 00 c6 ...: c0457669 ed 00 00 00 00 00 00 02 c0457671 bcf * 00 c0458240 b8 00 15 b2 81 cd 13 8c c8 8e d8 81 3e a5 1b 55 ..U c0458250 aa 75 4c 81 3e a7 1b .uL... c0458257 ZZuD c045825b eb 40 ac 20 c0 74 05 e8 08 00 eb f6 c3 e8 00 00 [EMAIL PROTECTED] .t.. c045826b b0 20 50 51 bb 07 00 b9 01 00 b4 0e cd 10 59 58 . PQ..YX c045827b c3 b0 07 eb ed. c0458280 No setup signature found ... c045829c 00 eb 4f 8c c8 83 e8 20 8e d8 30 ff 8a 1e f1 01 ..O ..0. c04582ac 83 eb 04 c1 e3 08 89 d9 c1 eb 03 81 c3 00 10 2e c04582bc 89 1e 0c 00 bf 00 08 29 f6 0e 07 b8 00 10 8e d8 ...) c04582cc f3 a5 8c c8 8e d8 81 3e a5 1b 55 aa 75 0a 81 3e .U.u.. c04582dc a7 1b 5a 5a 75 02 eb 0a 8d 36 40 0d e8 72 ff f4 [EMAIL PROTECTED] c04582ec eb fd 8c c8 83 e8 20 8e d8 2e f6 06 11 00 01 74 .. t c04582fc 2e 2e 80 3e 10 00 00 75 26 0e 1f 8d 36 d0 0d e8 ..u...6... c045830c 4f ff eb db O... c0458310 Wrong loader, giving up... c045832a 00 e8 36 00 66 85 c0 74 61 8c c8 8e d8 8d 36 00 ..6.f..ta.6. c045833a 0e e8 1f ff eb fe .. Bad case: c0457340 00 08 00 00 00 00 03 50 00 00 03 00 00 00 19 01 ...P c0457350 10. c04573514f * 00 c04573a0 80 86 00 00 00 00 00 00 00 00 00 00 c04573ac CISG c04573b030 * 00 c04573e0 08 00 fc 01 00 74 .t c04573e6 13e * 00 c0457524 e0 29 09 00 05 00 00 00 00 00 00 00 00 13 01 00 .).. c0457534 fa a4 01 00 00 00 ff ff 02 08 55 aa eb ..U.. c0457541 :HdrS c0457546 06 02 00 00 00 00 00 10 3c 23 71 81 00 80 00 00 #q. c0457556 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8e c0457566 00 00 00 90 09 00 ff ff ff 1f 00 00 10 . c0457573a6 * 00 c0457619 fc 09 00 00 00 00 00 01 00 00 00 00 fc 09 00 00 c0457629 00 00 00 00 04 00 00 00 00 00 00 02 00 00 00 3a ...: c0457639 12 0f 00 00 00 00 00 c6 ed 00 00 00 00 00 00 02 c0457649 00 00 00 00 00 10 00 00 00 00 00 00 00 f0 07 00 c0457659 00 00 00 01 00 00 00 3a 12 ff ff 00 00 00 00 c6 ...: c0457669 ed 00 00 00 00 00 00 02 c0457671 ccf * 00 $ cat /proc/cmdline root=/dev/hda1 Wolfgang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at
Re: regression in 2.6.23-rc8 - power off failed
Alexey Starikovskiy wrote:
-static void
-acpi_power_off (void)
-{
- printk(%s called\n,__FUNCTION__);
- /* Some SMP machines only can poweroff in boot CPU */
- set_cpus_allowed(current, cpumask_of_cpu(0));
ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
Later only comment was left for some reason...
Am I midreading that code, or does it really assume that the boot cpu is
always zero? Or just that zero will be able to do the power off?
In any case I have had an SMP machine which did not have a CPU zero, and
it was discussed here, I believe. Wonder what happens if you set
affinity to a CPU you don't have...
--
Bill Davidsen [EMAIL PROTECTED]
We have more to fear from the bungling of the incompetent than from
the machinations of the wicked. - from Slashdot
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
On Saturday, 29 September 2007 22:47, Bill Davidsen wrote:
Alexey Starikovskiy wrote:
-static void
-acpi_power_off (void)
-{
- printk(%s called\n,__FUNCTION__);
- /* Some SMP machines only can poweroff in boot CPU */
- set_cpus_allowed(current, cpumask_of_cpu(0));
ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
Later only comment was left for some reason...
Am I midreading that code, or does it really assume that the boot cpu is
always zero? Or just that zero will be able to do the power off?
In any case I have had an SMP machine which did not have a CPU zero, and
it was discussed here, I believe. Wonder what happens if you set
affinity to a CPU you don't have...
Good question, but it also caused other problems to appear, IIRC.
IMHO, it's better to call disable_nonboot_cpus() in an appropriate place
anyway.
Greetings,
Rafael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Wolfgang Erig wrote: Hi Peter, On Sat, Sep 29, 2007 at 11:35:53AM +0200, Wolfgang Erig wrote: I start again with a fresh tree and better controlled experiments. now the result of bisection seems to be consistent. The last good commit is f2d98ae63dc64dedb00499289e13a50677f771f9 Linker script for the new x86 setup code The first bad commit (no power off) is 4fd06960f120e02e9abc802a09f9511c400042a5 Use the new x86 setup code for i386 Now I try the things written in http://marc.info/[EMAIL PROTECTED] OK, that makes more sense. I'll look at this on Monday. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
regression in 2.6.23-rc8 - power off failed
My apologies for the two bogus addresses in the "To" of my previous message. Script error, won't happen again. Frans Pop - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
regression in 2.6.23-rc8 - power off failed
Wolfgang Erig wrote: > the latest kernel does not power off my system. This is a known regression in rc8. See this mail and thread for details: http://lkml.org/lkml/2007/9/25/239 The issue has already been fixed in Linus' git tree. Please try again with that, or apply the patches included in the posts referenced in the message linked above. Cheers, Frans Pop - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed on old laptop
Wolfgang Erig wrote: > Hi, > > the latest kernel does not power off my old laptop. > > 2.6.22 succeeded > 2.6.23-rc8 failed > > $ git bisect good > Bisecting: 0 revisions left to test after this > [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine > for new x86 setup code > > Which more info is needed? > Okay, I just went back and looked at it... this particular checkin had *zero* code impact (code not yet turned on), as did any of the checkins immediately surrounding it. Since your other email points to f216cc3748a3a22c2b99390fddcdafa0583791a2, which is a *much* later checkin, and which seems to actually have something to do with power states, that the above is a red herring? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Wolfgang Erig wrote: > Hi, > > the latest kernel does not power off my system. > > 2.6.22 succeeded > 2.6.23-rc8 failed > > $ git bisect bad > Bisecting: 0 revisions left to test after this > [f216cc3748a3a22c2b99390fddcdafa0583791a2] ACPI: suspend: consolidate > handling of Sx states. > > $ git bisect good > Bisecting: 0 revisions left to test after this > [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine > for new x86 setup code OK, so which one is the bad one? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed on old laptop
Wolfgang Erig wrote: > Hi, > > the latest kernel does not power off my old laptop. > > 2.6.22 succeeded > 2.6.23-rc8 failed > > $ git bisect good > Bisecting: 0 revisions left to test after this > [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine > for new x86 setup code > > Which more info is needed? > A description of the system, your .config file, kernel messages (old and new). Also see http://marc.info/[EMAIL PROTECTED] for a highly useful debugging step, especially if you can dump both before & after. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
regression in 2.6.23-rc8 - power off failed on old laptop
Hi, the latest kernel does not power off my old laptop. 2.6.22 succeeded 2.6.23-rc8 failed $ git bisect good Bisecting: 0 revisions left to test after this [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine for new x86 setup code Which more info is needed? Wolfgang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
regression in 2.6.23-rc8 - power off failed
Hi, the latest kernel does not power off my system. 2.6.22 succeeded 2.6.23-rc8 failed $ git bisect bad Bisecting: 0 revisions left to test after this [f216cc3748a3a22c2b99390fddcdafa0583791a2] ACPI: suspend: consolidate handling of Sx states. Which more info is needed? Wolfgang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
regression in 2.6.23-rc8 - power off failed
Hi, the latest kernel does not power off my system. 2.6.22 succeeded 2.6.23-rc8 failed $ git bisect bad Bisecting: 0 revisions left to test after this [f216cc3748a3a22c2b99390fddcdafa0583791a2] ACPI: suspend: consolidate handling of Sx states. Which more info is needed? Wolfgang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
regression in 2.6.23-rc8 - power off failed on old laptop
Hi, the latest kernel does not power off my old laptop. 2.6.22 succeeded 2.6.23-rc8 failed $ git bisect good Bisecting: 0 revisions left to test after this [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine for new x86 setup code Which more info is needed? Wolfgang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed on old laptop
Wolfgang Erig wrote: Hi, the latest kernel does not power off my old laptop. 2.6.22 succeeded 2.6.23-rc8 failed $ git bisect good Bisecting: 0 revisions left to test after this [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine for new x86 setup code Which more info is needed? A description of the system, your .config file, kernel messages (old and new). Also see http://marc.info/[EMAIL PROTECTED] for a highly useful debugging step, especially if you can dump both before after. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed
Wolfgang Erig wrote: Hi, the latest kernel does not power off my system. 2.6.22 succeeded 2.6.23-rc8 failed $ git bisect bad Bisecting: 0 revisions left to test after this [f216cc3748a3a22c2b99390fddcdafa0583791a2] ACPI: suspend: consolidate handling of Sx states. $ git bisect good Bisecting: 0 revisions left to test after this [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine for new x86 setup code OK, so which one is the bad one? -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 2.6.23-rc8 - power off failed on old laptop
Wolfgang Erig wrote: Hi, the latest kernel does not power off my old laptop. 2.6.22 succeeded 2.6.23-rc8 failed $ git bisect good Bisecting: 0 revisions left to test after this [626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and main routine for new x86 setup code Which more info is needed? Okay, I just went back and looked at it... this particular checkin had *zero* code impact (code not yet turned on), as did any of the checkins immediately surrounding it. Since your other email points to f216cc3748a3a22c2b99390fddcdafa0583791a2, which is a *much* later checkin, and which seems to actually have something to do with power states, that the above is a red herring? -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
regression in 2.6.23-rc8 - power off failed
Wolfgang Erig wrote: the latest kernel does not power off my system. This is a known regression in rc8. See this mail and thread for details: http://lkml.org/lkml/2007/9/25/239 The issue has already been fixed in Linus' git tree. Please try again with that, or apply the patches included in the posts referenced in the message linked above. Cheers, Frans Pop - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
regression in 2.6.23-rc8 - power off failed
My apologies for the two bogus addresses in the To of my previous message. Script error, won't happen again. Frans Pop - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
