git-acpi breaks resume-from-ram on the Vaio

git-acpi breaks resume-from-ram on the Vaio

[Andrew Morton]

It suspends OK, then during resume it gets partway through it, then everything
just stops.

Would prefer not to have to bisect this one - I've done enough bisecting this
week to last a lifetime, and bisecting git-acpi is painful due to build bustage
at various points (cpuidle).

Re: git-acpi breaks resume-from-ram on the Vaio

[Andrew Morton]

On Mon, 17 Sep 2007 21:12:13 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> 
> It suspends OK, then during resume it gets partway through it, then everything
> just stops.
> 
> Would prefer not to have to bisect this one - I've done enough bisecting this
> week to last a lifetime, and bisecting git-acpi is painful due to build bustage
> at various points (cpuidle).

And git-acpi breaks suspend-to-disk as well.  It gets up to "Suspending console(s)"
and then the cursor stops blinking at it wedges up.

Re: git-acpi breaks resume-from-ram on the Vaio

[Rafael J. Wysocki]

On Tuesday, 18 September 2007 06:40, Andrew Morton wrote:
> On Mon, 17 Sep 2007 21:12:13 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > 
> > It suspends OK, then during resume it gets partway through it, then everything
> > just stops.
> > 
> > Would prefer not to have to bisect this one - I've done enough bisecting this
> > week to last a lifetime, and bisecting git-acpi is painful due to build bustage
> > at various points (cpuidle).
> 
> And git-acpi breaks suspend-to-disk as well.  It gets up to "Suspending console(s)"
> and then the cursor stops blinking at it wedges up.

Can you please compile with CONFIG_DISABLE_CONSOLE_SUSPEND set and try:

# echo test > /sys/power/disk
# echo disk > /sys/power/state

and if that hangs,

# echo testproc > /sys/power/disk
# echo disk > /sys/power/state

Re: git-acpi breaks resume-from-ram on the Vaio

[Rafael J. Wysocki]

On Tuesday, 18 September 2007 13:54, Rafael J. Wysocki wrote:
> On Tuesday, 18 September 2007 06:40, Andrew Morton wrote:
> > On Mon, 17 Sep 2007 21:12:13 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> > > 
> > > It suspends OK, then during resume it gets partway through it, then everything
> > > just stops.
> > > 
> > > Would prefer not to have to bisect this one - I've done enough bisecting this
> > > week to last a lifetime, and bisecting git-acpi is painful due to build bustage
> > > at various points (cpuidle).
> > 
> > And git-acpi breaks suspend-to-disk as well.  It gets up to "Suspending console(s)"
> > and then the cursor stops blinking at it wedges up.
> 
> Can you please compile with CONFIG_DISABLE_CONSOLE_SUSPEND set and try:

Ah, that's -mm, sorry.  Instead of setting CONFIG_DISABLE_CONSOLE_SUSPEND
(which has been removed) please pass no_console_suspend in the command line.

> # echo test > /sys/power/disk
> # echo disk > /sys/power/state
> 
> and if that hangs,
> 
> # echo testproc > /sys/power/disk
> # echo disk > /sys/power/state

Re: git-acpi breaks resume-from-ram on the Vaio

[Andrew Morton]

On Tue, 18 Sep 2007 13:59:04 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Tuesday, 18 September 2007 13:54, Rafael J. Wysocki wrote:
> > On Tuesday, 18 September 2007 06:40, Andrew Morton wrote:
> > > On Mon, 17 Sep 2007 21:12:13 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > > 
> > > > 
> > > > It suspends OK, then during resume it gets partway through it, then everything
> > > > just stops.
> > > > 
> > > > Would prefer not to have to bisect this one - I've done enough bisecting this
> > > > week to last a lifetime, and bisecting git-acpi is painful due to build bustage
> > > > at various points (cpuidle).
> > > 
> > > And git-acpi breaks suspend-to-disk as well.  It gets up to "Suspending console(s)"
> > > and then the cursor stops blinking at it wedges up.

Bisection shows that the resume-from-ram failure is caused by 

commit 987196fa82d4db52c407e8c9d5dec884ba602183
Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Date:   Thu Feb 22 13:52:57 2007 -0800

    cpuidle take2: Core cpuidle infrastructure
    

Note that this is the patch which *fixed* resume-from-RAM prior to Thomas's
git-hrt merge.  Now it breaks it!?!?!


Also, I'm seeing this, in mainline, when I do echo mem > /sys/power/state

[   26.316685] ipw2200: Failed to send WEP_KEY: Aborted due to RF kill switch.
[   33.044631] ipw2200: Failed to send WEP_KEY: Command timed out.
[   39.862821] ipw2200: Failed to send WEP_KEY: Command timed out.
[   68.962896] PM: Preparing system for mem sleep
[   68.979485] Stopping tasks ... WARNING: at kernel/lockdep.c:2658 check_flags()
[   68.980154]  [<c0104ea4>] show_trace_log_lvl+0x1a/0x2f
[   68.980295]  [<c0105a44>] show_trace+0x12/0x14
[   68.980416]  [<c0105a5b>] dump_stack+0x15/0x17
[   68.980535]  [<c0137276>] check_flags+0x93/0x13d
[   68.980663]  [<c013a8ab>] lock_acquire+0x3a/0x91
[   68.980789]  [<c031948b>] _spin_lock+0x38/0x62
[   68.980913]  [<c0142a4d>] refrigerator+0x13/0xc2
[   68.981040]  [<c01283a2>] get_signal_to_deliver+0x32/0x405
[   68.981188]  [<c01035f4>] do_notify_resume+0x91/0x69f
[   68.981323]  [<c010402d>] work_notifysig+0x13/0x1a
[   68.981453]  =======================
[   68.981542] irq event stamp: 1511
[   68.981624] hardirqs last  enabled at (1511): [<c010408d>] syscall_exit_work+0x11/0x26
[   68.981834] hardirqs last disabled at (1510): [<c0103f63>] syscall_exit+0x9/0x1a
[   68.982031] softirqs last  enabled at (1418): [<c03104c3>] unix_accept+0xe5/0xfb
[   68.982230] softirqs last disabled at (1416): [<c031958d>] _write_lock_bh+0xf/0x67


> > Can you please compile with CONFIG_DISABLE_CONSOLE_SUSPEND set and try:
> 
> Ah, that's -mm, sorry.  Instead of setting CONFIG_DISABLE_CONSOLE_SUSPEND
> (which has been removed) please pass no_console_suspend in the command line.
> 

Didn't appear to change anything.  Bear in mind that e100 netconsole is a
bit busted across resume anyway, and the video display on this machine has
never ever survived resume-from-ram (but the X server can bring it back).

Re: git-acpi breaks resume-from-ram on the Vaio

[Rafael J. Wysocki]

On Wednesday, 19 September 2007 09:27, Andrew Morton wrote:
> On Tue, 18 Sep 2007 13:59:04 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > On Tuesday, 18 September 2007 13:54, Rafael J. Wysocki wrote:
> > > On Tuesday, 18 September 2007 06:40, Andrew Morton wrote:
> > > > On Mon, 17 Sep 2007 21:12:13 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > > > 
> > > > > 
> > > > > It suspends OK, then during resume it gets partway through it, then everything
> > > > > just stops.
> > > > > 
> > > > > Would prefer not to have to bisect this one - I've done enough bisecting this
> > > > > week to last a lifetime, and bisecting git-acpi is painful due to build bustage
> > > > > at various points (cpuidle).
> > > > 
> > > > And git-acpi breaks suspend-to-disk as well.  It gets up to "Suspending console(s)"
> > > > and then the cursor stops blinking at it wedges up.
> 
> Bisection shows that the resume-from-ram failure is caused by 
> 
> commit 987196fa82d4db52c407e8c9d5dec884ba602183
> Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> Date:   Thu Feb 22 13:52:57 2007 -0800
> 
>     cpuidle take2: Core cpuidle infrastructure
>     
> 
> Note that this is the patch which *fixed* resume-from-RAM prior to Thomas's
> git-hrt merge.  Now it breaks it!?!?!

Beats me hands down. :-(

I guess Thomas and Venki should look into it.

> Also, I'm seeing this, in mainline, when I do echo mem > /sys/power/state
> 
> [   26.316685] ipw2200: Failed to send WEP_KEY: Aborted due to RF kill switch.
> [   33.044631] ipw2200: Failed to send WEP_KEY: Command timed out.
> [   39.862821] ipw2200: Failed to send WEP_KEY: Command timed out.
> [   68.962896] PM: Preparing system for mem sleep
> [   68.979485] Stopping tasks ... WARNING: at kernel/lockdep.c:2658 check_flags()
> [   68.980154]  [<c0104ea4>] show_trace_log_lvl+0x1a/0x2f
> [   68.980295]  [<c0105a44>] show_trace+0x12/0x14
> [   68.980416]  [<c0105a5b>] dump_stack+0x15/0x17
> [   68.980535]  [<c0137276>] check_flags+0x93/0x13d
> [   68.980663]  [<c013a8ab>] lock_acquire+0x3a/0x91
> [   68.980789]  [<c031948b>] _spin_lock+0x38/0x62
> [   68.980913]  [<c0142a4d>] refrigerator+0x13/0xc2
> [   68.981040]  [<c01283a2>] get_signal_to_deliver+0x32/0x405
> [   68.981188]  [<c01035f4>] do_notify_resume+0x91/0x69f
> [   68.981323]  [<c010402d>] work_notifysig+0x13/0x1a
> [   68.981453]  =======================
> [   68.981542] irq event stamp: 1511
> [   68.981624] hardirqs last  enabled at (1511): [<c010408d>] syscall_exit_work+0x11/0x26
> [   68.981834] hardirqs last disabled at (1510): [<c0103f63>] syscall_exit+0x9/0x1a
> [   68.982031] softirqs last  enabled at (1418): [<c03104c3>] unix_accept+0xe5/0xfb
> [   68.982230] softirqs last disabled at (1416): [<c031958d>] _write_lock_bh+0xf/0x67

I guess task_lock(current) in refrigerator() triggers this, which probably means that
task_lock(current) has been taken with interrupts disabled somewhere.

I'm not sure if my interpretation is correct, though.

I also don't really know what I'm supposed to do about it ...
 
> > > Can you please compile with CONFIG_DISABLE_CONSOLE_SUSPEND set and try:
> > 
> > Ah, that's -mm, sorry.  Instead of setting CONFIG_DISABLE_CONSOLE_SUSPEND
> > (which has been removed) please pass no_console_suspend in the command line.
> > 
> 
> Didn't appear to change anything.  Bear in mind that e100 netconsole is a
> bit busted across resume anyway, and the video display on this machine has
> never ever survived resume-from-ram (but the X server can bring it back).

s2ram might help here (http://en.opensuse.org/s2ram), but I guess the Vaio is
not on the whitelist ...

Re: git-acpi breaks resume-from-ram on the Vaio

[Thomas Gleixner]

On Wed, 2007-09-19 at 13:53 +0200, Rafael J. Wysocki wrote: 
> > > > > And git-acpi breaks suspend-to-disk as well.  It gets up to "Suspending console(s)"
> > > > > and then the cursor stops blinking at it wedges up.
> > 
> > Bisection shows that the resume-from-ram failure is caused by 
> > 
> > commit 987196fa82d4db52c407e8c9d5dec884ba602183
> > Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> > Date:   Thu Feb 22 13:52:57 2007 -0800
> > 
> >     cpuidle take2: Core cpuidle infrastructure
> >     
> > 
> > Note that this is the patch which *fixed* resume-from-RAM prior to Thomas's
> > git-hrt merge.  Now it breaks it!?!?!
> 
> Beats me hands down. :-(
> 
> I guess Thomas and Venki should look into it.

Yeah, I twisted my brain already. I checked the difference of the
cpuidle stuff, which I have in my 2.6.23-rc6-hrt2 queue (including the
mainline clockevent fixes). It's basically zero.

My own incarnation of a jinxed VAIO is showing the same problem with
-hrt2. rc6-mm1 is not booting at all on that box. 

I'm going back into the dark fishing grounds of suspend resume
debugging.

	tglx

Re: git-acpi breaks resume-from-ram on the Vaio

[Len Brown]

On Tuesday 18 September 2007 00:12, Andrew Morton wrote:
> 
> It suspends OK, then during resume it gets partway through it, then everything
> just stops.

Hmmm, i thought your vaio resume problems were in linus' tree --
did that go away -- or maybe it was in -mm and not in linus' tree all along?

> Would prefer not to have to bisect this one - I've done enough bisecting this
> week to last a lifetime, and bisecting git-acpi is painful due to build bustage
> at various points (cpuidle).

bisecting the acpi git three should work well, because it uses topic branches.
This includes cpuidle.  ie.  unless the breakage is within the cpuidle branch itself,
the whole cpuidle topic can be removed by skipping the single merge commit that
pulls it in.

If you like, I can build the topic branch heads and export plain patches
for you to try.  Also, I'll probably be re-writing the test branch history
later today -- so let me know if you dig into it and i'll delay that until
you're done.

thanks,
-Len

Bissecting acpi merges (was Re: git-acpi breaks resume-from-ram on the Vaio)

[Henrique de Moraes Holschuh]

On Tue, 18 Sep 2007, Len Brown wrote:
> bisecting the acpi git three should work well, because it uses topic branches.
> This includes cpuidle.  ie.  unless the breakage is within the cpuidle branch itself,
> the whole cpuidle topic can be removed by skipping the single merge commit that
> pulls it in.

The issue I had sometimes while bissecting ACPI commits was that the topic
branches are often rooted on much earlier versions of the kernel tree.  So
you are near rcY, and suddenly you are way back to rc(Y-2) while inside one
of the ACPI merges...  depending on what happened in the large number of
non-acpi commits this reverts, that can lead to some annoyance with the
resulting kernel.

I don't recall if those were bissects of acpi-test, or of mainline though.

Maybe my git-fu is simply not up to it, and the above is not a problem for
those with better git skills.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Bissecting acpi merges (was Re: git-acpi breaks resume-from-ram on the Vaio)

[Len Brown]

On Tuesday 18 September 2007 11:47, Henrique de Moraes Holschuh wrote:
> On Tue, 18 Sep 2007, Len Brown wrote:
> > bisecting the acpi git three should work well, because it uses topic branches.
> > This includes cpuidle.  ie.  unless the breakage is within the cpuidle branch itself,
> > the whole cpuidle topic can be removed by skipping the single merge commit that
> > pulls it in.
> 
> The issue I had sometimes while bissecting ACPI commits was that the topic
> branches are often rooted on much earlier versions of the kernel tree.  So
> you are near rcY, and suddenly you are way back to rc(Y-2) while inside one
> of the ACPI merges...  depending on what happened in the large number of
> non-acpi commits this reverts, that can lead to some annoyance with the
> resulting kernel.

yes, that can be a problem when you get pulled down into a topic branch
with an old root.  However, as the topic branches are all pulled into
they tree one after another, it should be very quick to determine which one
of them is the cause.

Topic branches with old roots are also more work for me
b/c upstream diverges and I have to repeat merges.  for this reason
I re-based the cpuidle branch a while back -- as that is by far
the oldest one.

-Len

Re: git-acpi breaks resume-from-ram on the Vaio

[Andrew Morton]

On Tue, 18 Sep 2007 11:21:41 -0400 Len Brown <lenb@kernel.org> wrote:

> On Tuesday 18 September 2007 00:12, Andrew Morton wrote:
> > 
> > It suspends OK, then during resume it gets partway through it, then everything
> > just stops.
> 
> Hmmm, i thought your vaio resume problems were in linus' tree --
> did that go away -- or maybe it was in -mm and not in linus' tree all along?

It got fixed in Linus's tree by tglx's recent timers merge.

This breakage in git-acpi is new, I think.  Four or five days ago, git-acpi
_fixed_ suspend/resume on Linus's tree.  Now it breaks it.

But I don't think there have been changes in got-acpi since then, so
perhaps the breakage is due to interaction with Thomas's recent merge.

> > Would prefer not to have to bisect this one - I've done enough bisecting this
> > week to last a lifetime, and bisecting git-acpi is painful due to build bustage
> > at various points (cpuidle).
> 
> bisecting the acpi git three should work well, because it uses topic branches.
> This includes cpuidle.  ie.  unless the breakage is within the cpuidle branch itself,
> the whole cpuidle topic can be removed by skipping the single merge commit that
> pulls it in.

The breakage is within the cpuidle branch.

> If you like, I can build the topic branch heads and export plain patches
> for you to try.  Also, I'll probably be re-writing the test branch history
> later today -- so let me know if you dig into it and i'll delay that until
> you're done.

I won't be doing anything here for a day or so.

I think what needs to happen is that the commits in the cpuidle code need
to be folded together.  iirc the first couple of commits don't compile, and
the third one fixes them.  Or something like that.

Re: git-acpi breaks resume-from-ram on the Vaio

[Len Brown]

> I think what needs to happen is that the commits in the cpuidle code need
> to be folded together.  iirc the first couple of commits don't compile, and
> the third one fixes them.  Or something like that.

yes, i think the older history has probably outlived its utility
and can be folded entirely if it is okay with adam/venki/shaohua.

cheers,
-Len

Re: git-acpi breaks resume-from-ram on the Vaio

[Len Brown]

On Tuesday 18 September 2007 13:07, Andrew Morton wrote:

> This breakage in git-acpi is new, I think.  Four or five days ago, git-acpi
> _fixed_ suspend/resume on Linus's tree.  Now it breaks it.
> 
> But I don't think there have been changes in got-acpi since then, so
> perhaps the breakage is due to interaction with Thomas's recent merge.

hmmm, maybe.

Perhaps if you are including sony-laptop, you can try excluding it --
since these reverse engineered things are always fraught with peril....

I think the next thing to test is to revert cpuidle --
let me make sure that my cpuidle branch produces a patch
that will revert cleanly...

-Len

Re: git-acpi breaks resume-from-ram on the Vaio

[Andrew Morton]

On Tue, 18 Sep 2007 15:58:18 -0400
Len Brown <lenb@kernel.org> wrote:

> On Tuesday 18 September 2007 13:07, Andrew Morton wrote:
> 
> > This breakage in git-acpi is new, I think.  Four or five days ago, git-acpi
> > _fixed_ suspend/resume on Linus's tree.  Now it breaks it.
> > 
> > But I don't think there have been changes in got-acpi since then, so
> > perhaps the breakage is due to interaction with Thomas's recent merge.
> 
> hmmm, maybe.
> 
> Perhaps if you are including sony-laptop, you can try excluding it --
> since these reverse engineered things are always fraught with peril....
> 
> I think the next thing to test is to revert cpuidle --
> let me make sure that my cpuidle branch produces a patch
> that will revert cleanly...
> 

ho hum.

I still have the git-acpi tree as a quilt series so this
evening I'll bisect these two failures down to a
particular git commit.