Bug 12492

Date: Tue, 20 Jan 2009 15:23:12 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Alex Riesen <raa.lkml@gmail.com>
Subject: Re: [Bug #12468] Crash in acpi_cpufreq_init

should be fixed by the pending x86 fixes:

   git pull git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus

does it work fine if you pull that tree?

        Ingo

please ignore comment #1 -- i pasted it into the wrong bug report.

Reply-To: akpm@linux-foundation.org

On Mon, 22 Dec 2008 12:36:30 +0100 Heiko Carstens <heiko.carstens@de.ibm.com> wrote:

> Introduce stop_machine_create/destroy. With this interface subsystems
> that need a non-failing stop_machine environment can create the
> stop_machine machine threads before actually calling stop_machine.
> When the threads aren't needed anymore they can be killed with
> stop_machine_destroy again.
> 
> When stop_machine gets called and the threads aren't present they
> will be created and destroyed automatically. This restores the old
> behaviour of stop_machine.
> 
> This patch also converts cpu hotplug to the new interface since it
> is special: cpu_down calls __stop_machine instead of stop_machine.
> However the kstop threads will only be created when stop_machine
> gets called.
> 
> Changing the code so that the threads would be created automatically
> on __stop_machine is currently not possible: when __stop_machine gets
> called we hold cpu_add_remove_lock, which is the same lock that
> create_rt_workqueue would take. So the workqueue needs to be created
> before the cpu hotplug code locks cpu_add_remove_lock.

In http://bugzilla.kernel.org/show_bug.cgi?id=12492, Thomas (cc'ed
here) reports

  Commit 9ea09af3bd3090e8349ca2899ca2011bd94cda85 introduced a
  regression that caused the kernel to fail to suspend.  The 'sleeping'
  LED on the laptop just keeps blinking and the laptop never shuts
  down.  I think this was eventually fixed because with 2.6.29-rc1 and
  -rc2 the laptop suspends fine, but fails to resume.  When I try to
  resume, all I see is a blinking cursor in the top left corner of the
  screen.

  I'm using acpi_sleep=s3_bios,s3_mode, suspending using a script
  that does: echo mem > /sys/power/state.

The bug introduced with the introduction of stop_machine_create/destroy
was fixed with a0e280e0f33f6c859a235fb69a875ed8f3420388
"stop_machine/cpu hotplug: fix disable_nonboot_cpus".
Must be something else.

Reply-To: akpm@linux-foundation.org

On Tue, 27 Jan 2009 00:04:32 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:

> On Mon, 22 Dec 2008 12:36:30 +0100 Heiko Carstens <heiko.carstens@de.ibm.com>
> wrote:
> 
> > Introduce stop_machine_create/destroy. With this interface subsystems
> > that need a non-failing stop_machine environment can create the
> > stop_machine machine threads before actually calling stop_machine.
> > When the threads aren't needed anymore they can be killed with
> > stop_machine_destroy again.
> > 
> > When stop_machine gets called and the threads aren't present they
> > will be created and destroyed automatically. This restores the old
> > behaviour of stop_machine.
> > 
> > This patch also converts cpu hotplug to the new interface since it
> > is special: cpu_down calls __stop_machine instead of stop_machine.
> > However the kstop threads will only be created when stop_machine
> > gets called.
> > 
> > Changing the code so that the threads would be created automatically
> > on __stop_machine is currently not possible: when __stop_machine gets
> > called we hold cpu_add_remove_lock, which is the same lock that
> > create_rt_workqueue would take. So the workqueue needs to be created
> > before the cpu hotplug code locks cpu_add_remove_lock.
> 
> In http://bugzilla.kernel.org/show_bug.cgi?id=12492, Thomas (cc'ed
> here) reports
> 
>   Commit 9ea09af3bd3090e8349ca2899ca2011bd94cda85 introduced a
>   regression that caused the kernel to fail to suspend.  The 'sleeping'
>   LED on the laptop just keeps blinking and the laptop never shuts
>   down.  I think this was eventually fixed because with 2.6.29-rc1 and
>   -rc2 the laptop suspends fine, but fails to resume.  When I try to
>   resume, all I see is a blinking cursor in the top left corner of the
>   screen.
> 
>   I'm using acpi_sleep=s3_bios,s3_mode, suspending using a script
>   that does: echo mem > /sys/power/state.
> 

hm.  Re-reading this, it seems to be saying that
9ea09af3bd3090e8349ca2899ca2011bd94cda85 might be innocent, and that
some other patch might have caused the resume regression?

On Tue, 27 Jan 2009 01:52:02 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Tue, 27 Jan 2009 00:04:32 -0800 Andrew Morton <akpm@linux-foundation.org>
> wrote:
> >   Commit 9ea09af3bd3090e8349ca2899ca2011bd94cda85 introduced a
> >   regression that caused the kernel to fail to suspend.  The 'sleeping'
> >   LED on the laptop just keeps blinking and the laptop never shuts
> >   down.  I think this was eventually fixed because with 2.6.29-rc1 and
> >   -rc2 the laptop suspends fine, but fails to resume.  When I try to
> >   resume, all I see is a blinking cursor in the top left corner of the
> >   screen.
> > 
> >   I'm using acpi_sleep=s3_bios,s3_mode, suspending using a script
> >   that does: echo mem > /sys/power/state.
> 
> hm.  Re-reading this, it seems to be saying that
> 9ea09af3bd3090e8349ca2899ca2011bd94cda85 might be innocent, and that
> some other patch might have caused the resume regression?

Yes, I already updated the bugzilla entry at kernel.org:

The bug introduced with the introduction of stop_machine_create/destroy
was fixed with a0e280e0f33f6c859a235fb69a875ed8f3420388
"stop_machine/cpu hotplug: fix disable_nonboot_cpus".
Must be something else.

There are at least two known suspend problems affecting thinkpads in -rc2.  Hopefully, they will be fixed before -rc3 (one of them has been fixed already, there's a fix for the other one in the USB tree).

The four patches linked to at http://bugzilla.kernel.org/show_bug.cgi?id=12495#c2 fix STR for me. They appear to be already in linux-2.6.git, so I'm closing this bug.