Re: [BUG] acpi double resume and fail

Re: [BUG] acpi double resume and fail

[Andrew Morton]

On Fri, 18 May 2007 23:37:01 +0200
Christian Leber <christian@leber.de> wrote:

> Hello,
> 
> i hit a problem with suspend to ram and especially resume.
> Hardware: Dell Latitude D810 (some Intel 915 with Intel Pentium M)
> 
> With 2.6.19.7 suspend to ram works reliable, but with 2.6.20-rc4
> it stopped working reliable.

argh, that sounds like an ACPI regression.

> I still can suspend, but after the first resume it goes back to sleep
> directly again, when resuming again it works.
> After the second suspend it won't resume at all.
> 
> The problem is that i can't try out the kernel versions <rc4, because
> rc1, rc2 and rc3 doesn't boot at all, so git-bisect also won't help.
> 
> Has somebody an idea what i could try out?
> 
> (the distribution is in this case ubuntu feisty)
> 

The fact that bisection broke really does make it hard.  What you would
need to do is to find the patch which fixed that doesn't-boot problem, then
reapply it each time you perform an iteration.  That's all doable, if you
have the time.  Use git-bisect for it.

Have you tested 2.6.21 and/or 2.6.22-rc1?

We had one other report earlier today that 2.6.22-rc1 does an immediate
resume after suspend-to-RAM - perhaps that is related.


Of course the alternative way of debugging this is just to debug it, rather
than the difficult bisecting.  Perhaps an ACPI developer can help with
that.

Re: [BUG] acpi double resume and fail

[Christian Leber]

On Fri, May 18, 2007 at 03:45:07PM -0700, Andrew Morton wrote:

> > I still can suspend, but after the first resume it goes back to sleep
> > directly again, when resuming again it works.
> > After the second suspend it won't resume at all.

I should add, that it goes from the suspend state to "on" and back to
suspend, when i press power again it goes "on", but the screen stays
black, but network doesn't work and most likely linux isn't running,
because the laptop sucks max_power. (2.6.20-rc4)

> > The problem is that i can't try out the kernel versions <rc4, because
> > rc1, rc2 and rc3 doesn't boot at all, so git-bisect also won't help.
> > 
> > Has somebody an idea what i could try out?
> > 
> > (the distribution is in this case ubuntu feisty)
 
> The fact that bisection broke really does make it hard.  What you would
> need to do is to find the patch which fixed that doesn't-boot problem, then
> reapply it each time you perform an iteration.  That's all doable, if you
> have the time.  Use git-bisect for it.

I'll try, unfortunatelly the problem is that PCI doesn't work with this
versions.

> Have you tested 2.6.21 and/or 2.6.22-rc1?

I just have tried 2.6.22-rc2 and it's a bit different, I still have to resume
2 times and X does only work the "first" resume correctly, but it somewhat
works.

> We had one other report earlier today that 2.6.22-rc1 does an immediate
> resume after suspend-to-RAM - perhaps that is related.

no


Regards
Christian Leber

-- 
http://rettetdieti.vde-uni-mannheim.de/

Re: beeping patch for debugging acpi sleep

[Christian Leber]

On Sat, Jun 09, 2007 at 03:08:17PM +0200, Pavel Machek wrote:

> Starting beeper as soon as ACPI sleep returns is very useful in
> debugging "apparently dead" machines. If it beeps at all, it makes
> sense to start playing with CMOS tracer.

thank you very much Pavel

The results are a bit unclear, I took a 2.6.22-rc4 with beep.
Logged into KDE.
(hardware: Dell Latitude D810)

S = successfull resume
D = had to resume 2 times, that means when pressing the power button the
LED goes from blinking to on and after a few seconds it goes back to
blinking, but without a beep in between; after pressing the power button
a second time resume is successfull
F = resume failes, NO beep

-run 1: D D F
-run 2: D D D(some X garbadge) F
-run 3: S S S S S S F
-run 4: S S F
-run 5: D F

Very odd, nothing was changed in between and after each F i switched it
off... because it was dead.

With 2.6.19.7 i have never seen it fail.


Christian Leber

-- 
http://rettetdieti.vde-uni-mannheim.de/

Re: beeping patch for debugging acpi sleep

[Christian Leber]

On Sat, Jun 16, 2007 at 09:46:34PM +0200, Christian Leber wrote:

> The results are a bit unclear, I took a 2.6.22-rc4 with beep.
> Logged into KDE.
> (hardware: Dell Latitude D810)
> 
> S = successfull resume
> D = had to resume 2 times, that means when pressing the power button the
> LED goes from blinking to on and after a few seconds it goes back to
> blinking, but without a beep in between; after pressing the power button
> a second time resume is successfull
> F = resume failes, NO beep
> 
> -run 1: D D F
> -run 2: D D D(some X garbadge) F
> -run 3: S S S S S S F
> -run 4: S S F
> -run 5: D F

I tracked the problem halfway down, with 2.6.20-rc1-ubuntu1 [1] it works
and with 2.6.20-rc2-ubuntu2 [2] not.

The diff is here, unfortunately the acpi changes are about 100kb.
http://debian.christian-leber.de/2.2-3.4.patch

(the problem is a bit different, it suspends, when trying to resume it
goes back to suspend and when i try again it's dead)

For some reason that i don't get vanilla 2.6.20-rc1 doesn't boot because
ata_piix doesn't work "PCI: Unable to reserve I/O region...." no remote
idea why it works with the ubuntu kernel.
So i can't bisect it.


Christian Leber


[1] https://launchpad.net/ubuntu/+source/linux-source-2.6.20/2.6.20-2.2
[2] https://launchpad.net/ubuntu/+source/linux-source-2.6.20/2.6.20-3.4

-- 
http://rettetdieti.vde-uni-mannheim.de/

Re: beeping patch for debugging acpi sleep

[Pavel Machek]

Hi!

> > The results are a bit unclear, I took a 2.6.22-rc4 with beep.
> > Logged into KDE.
> > (hardware: Dell Latitude D810)
> > 
> > S = successfull resume
> > D = had to resume 2 times, that means when pressing the power button the
> > LED goes from blinking to on and after a few seconds it goes back to
> > blinking, but without a beep in between; after pressing the power button
> > a second time resume is successfull
> > F = resume failes, NO beep
> > 
> > -run 1: D D F
> > -run 2: D D D(some X garbadge) F
> > -run 3: S S S S S S F
> > -run 4: S S F
> > -run 5: D F
> 
> I tracked the problem halfway down, with 2.6.20-rc1-ubuntu1 [1] it works
> and with 2.6.20-rc2-ubuntu2 [2] not.
> 
> The diff is here, unfortunately the acpi changes are about 100kb.
> http://debian.christian-leber.de/2.2-3.4.patch
> 
> (the problem is a bit different, it suspends, when trying to resume it
> goes back to suspend and when i try again it's dead)

It may well be different problem :-(. 100KB diff and I'm not an acpi
expert :-(.

I just discovered I have problems with s2ram, too, but it looks like
usermodehelper is responsible.

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: beeping patch for debugging acpi sleep

[Christian Leber]

On Thu, Jun 28, 2007 at 02:08:15PM +0000, Pavel Machek wrote:
> > > The results are a bit unclear, I took a 2.6.22-rc4 with beep.
> > > Logged into KDE.
> > > (hardware: Dell Latitude D810)
> > > 
> > > S = successfull resume
> > > D = had to resume 2 times, that means when pressing the power button the
> > > LED goes from blinking to on and after a few seconds it goes back to
> > > blinking, but without a beep in between; after pressing the power button
> > > a second time resume is successfull
> > > F = resume failes, NO beep
> > > 
> > > -run 1: D D F
> > > -run 2: D D D(some X garbadge) F
> > > -run 3: S S S S S S F
> > > -run 4: S S F
> > > -run 5: D F

[..]

> It may well be different problem :-(. 100KB diff and I'm not an acpi
> expert :-(.
> 
> I just discovered I have problems with s2ram, too, but it looks like
> usermodehelper is responsible.

Now i think it is a userspace problem, more exactly something in KDE.

I got a new laptop(a Dell D830) and
discovered that suspend works with gnome and when i directly run /etc/acpi/sleep.sh.
(with KDE running, from a xterm... but so somehow it can't interact with
the KDE userspace stuff) (i have no remote idea what KDE is doing)

So i tried sleep.sh also on my old laptop (D810) once again and it works
reliable, well at least for 13 times.

Directly afterwards i tried the suspend to ram button again and it
failed again as stated above.


Can someone else with suspend problems and KDE verify this?

i filled a bug against KDE in ubuntu:
https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bug/131855


Christian Leber

-- 
You are searching some interesting studies?
http://www.ziti.uni-heidelberg.de/   :-)