[BUG] acpi double resume and fail

[BUG] acpi double resume and fail

[Christian Leber]

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.
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)

Regards
Christian Leber

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

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: [BUG] acpi double resume and fail

[Pavel Machek]

Hi!

> 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.
> 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.

Try with minimal modules. Try beeping patch to see if we reach linux
on second resume.

Andrew: I have debugging hack that beeps the speaker as the first
thing in acpi resume (real mode) routine. It provides some useful
info. Maybe it is even worth including in mainline?
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

beeping patch for debugging acpi sleep

[Pavel Machek]

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.

Signed-off-by: Pavel Machek <pavel@suse.cz>

diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S
index b781b38..cbf136e 100644
--- a/arch/i386/kernel/acpi/wakeup.S
+++ b/arch/i386/kernel/acpi/wakeup.S
@@ -11,7 +11,22 @@ # Do we need to deal with A20? It is oka
 #
 # If physical address of wakeup_code is 0x12345, BIOS should call us with
 # cs = 0x1234, eip = 0x05
-# 
+#
+
+#define BEEP \
+	inb	$97, %al; 	\
+	outb	%al, $0x80; 	\
+	movb	$3, %al; 	\
+	outb	%al, $97; 	\
+	outb	%al, $0x80; 	\
+	movb	$-74, %al; 	\
+	outb	%al, $67; 	\
+	outb	%al, $0x80; 	\
+	movb	$-119, %al; 	\
+	outb	%al, $66; 	\
+	outb	%al, $0x80; 	\
+	movb	$15, %al; 	\
+	outb	%al, $66;
 
 ALIGN
 	.align	4096
@@ -20,6 +35,9 @@ wakeup_code:
 	wakeup_code_start = .
 	.code16
 
+# Uncomment this to make your computer start producing ugly noise as soon
+# as BIOS returns to this real-mode entry point.
+#	BEEP
  	movw	$0xb800, %ax
 	movw	%ax,%fs
 	movw	$0x0e00 + 'L', %fs:(0x10)

-- 
(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

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

On Sat, 2007-06-09 15:08:17 +0200, Pavel Machek <pavel@ucw.cz> 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.

I'd even go so far and implement it unconditionally.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:                     Eine Freie Meinung in einem Freien Kopf
the second  :                   für einen Freien Staat voll Freier Bürger.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: beeping patch for debugging acpi sleep

[Pavel Machek]

On Sat 2007-06-09 15:16:04, Jan-Benedict Glaw wrote:
> On Sat, 2007-06-09 15:08:17 +0200, Pavel Machek <pavel@ucw.cz> 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.
> 
> I'd even go so far and implement it unconditionally.

Well, try it; it is too annoying to be unconditional.
									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

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

Hi.

On Sun, 2007-06-10 at 00:54 +0200, Pavel Machek wrote:
> On Sat 2007-06-09 15:16:04, Jan-Benedict Glaw wrote:
> > On Sat, 2007-06-09 15:08:17 +0200, Pavel Machek <pavel@ucw.cz> 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.
> > 
> > I'd even go so far and implement it unconditionally.
> 
> Well, try it; it is too annoying to be unconditional.

Could you modify the pitch or the length then, to make it less annoying?
It sounds like a really good idea to me.

Regards,

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: beeping patch for debugging acpi sleep

[Pavel Machek]

On Sun 2007-06-10 09:27:55, Nigel Cunningham wrote:
> Hi.
> 
> On Sun, 2007-06-10 at 00:54 +0200, Pavel Machek wrote:
> > On Sat 2007-06-09 15:16:04, Jan-Benedict Glaw wrote:
> > > On Sat, 2007-06-09 15:08:17 +0200, Pavel Machek <pavel@ucw.cz> 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.
> > > 
> > > I'd even go so far and implement it unconditionally.
> > 
> > Well, try it; it is too annoying to be unconditional.
> 
> Could you modify the pitch or the length then, to make it less annoying?
> It sounds like a really good idea to me.

Modifying length is non-trivial, AFAICT, but feel free to submit a
patch...

Actually, *any* tone will be annoying in quiet room, and kernel should
not really be making sounds on its own, so scratch that idea.

									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

[Stefan Seyfried]

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

How about (WARNING! I never have written i386 assembly, my last assembly
experience was 20 years ago on Z80, so this is basically just copy'n paste,
but i hope you get the idea):

> --- a/arch/i386/kernel/acpi/wakeup.S
> +++ b/arch/i386/kernel/acpi/wakeup.S

> @@ -20,6 +35,9 @@ wakeup_code:
>  	wakeup_code_start = .
>  	.code16
>  
> +# Uncomment this to make your computer start producing ugly noise as soon
> +# as BIOS returns to this real-mode entry point.

        testl   $4, video_flags - wakeup_code
        jz      1f
> +	BEEP
   1:
>   	movw	$0xb800, %ax
>  	movw	%ax,%fs
>  	movw	$0x0e00 + 'L', %fs:(0x10)

IIUC, then this should make "echo 4 > /proc/sys/kernel/acpi_video_flags"
enable the beep at run-time.

Yes, i know, it is not a video flag. And not ACPI. Just add another
sysctl if you care.
-- 
Stefan Seyfried
QA / R&D Team Mobile Devices        |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: beeping patch for debugging acpi sleep

[Pavel Machek]

Hi!

> How about (WARNING! I never have written i386 assembly, my last assembly
> experience was 20 years ago on Z80, so this is basically just copy'n paste,
> but i hope you get the idea):

We probably can do that, if there's big enough demand.

> > --- a/arch/i386/kernel/acpi/wakeup.S
> > +++ b/arch/i386/kernel/acpi/wakeup.S
> 
> > @@ -20,6 +35,9 @@ wakeup_code:
> >  	wakeup_code_start = .
> >  	.code16
> >  
> > +# Uncomment this to make your computer start producing ugly noise as soon
> > +# as BIOS returns to this real-mode entry point.
> 
>         testl   $4, video_flags - wakeup_code
>         jz      1f
> > +	BEEP
>    1:

Heh, I'd say you learn quickly :-). But for now, I'd like to have
basic patch in, and as reliable as possible.
								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

[Andrew Morton]

On Sat, 9 Jun 2007 15:08:17 +0200
Pavel Machek <pavel@ucw.cz> 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.
> 
> Signed-off-by: Pavel Machek <pavel@suse.cz>
> 
> diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S
> index b781b38..cbf136e 100644
> --- a/arch/i386/kernel/acpi/wakeup.S
> +++ b/arch/i386/kernel/acpi/wakeup.S
> @@ -11,7 +11,22 @@ # Do we need to deal with A20? It is oka
>  #
>  # If physical address of wakeup_code is 0x12345, BIOS should call us with
>  # cs = 0x1234, eip = 0x05
> -# 
> +#
> +
> +#define BEEP \
> +	inb	$97, %al; 	\
> +	outb	%al, $0x80; 	\
> +	movb	$3, %al; 	\
> +	outb	%al, $97; 	\
> +	outb	%al, $0x80; 	\
> +	movb	$-74, %al; 	\
> +	outb	%al, $67; 	\
> +	outb	%al, $0x80; 	\
> +	movb	$-119, %al; 	\
> +	outb	%al, $66; 	\
> +	outb	%al, $0x80; 	\
> +	movb	$15, %al; 	\
> +	outb	%al, $66;
>  
>  ALIGN
>  	.align	4096
> @@ -20,6 +35,9 @@ wakeup_code:
>  	wakeup_code_start = .
>  	.code16
>  
> +# Uncomment this to make your computer start producing ugly noise as soon
> +# as BIOS returns to this real-mode entry point.
> +#	BEEP
>   	movw	$0xb800, %ax
>  	movw	%ax,%fs
>  	movw	$0x0e00 + 'L', %fs:(0x10)
> 

How does the beep get turned off again?

Should the BEEP line be uncommented (in -mm at least)?

Re: beeping patch for debugging acpi sleep

[Matthieu CASTET]

Hi,

On Mon, 11 Jun 2007 12:00:34 -0700, Andrew Morton wrote:

> On Sat, 9 Jun 2007 15:08:17 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
> 
> 

> How does the beep get turned off again?
May be it is turn off by the speaker driver.


BTW can't we do something with led ? This way it can be always enabled 
without anoying people


Matthieu

Re: beeping patch for debugging acpi sleep

[Pavel Machek]

Hi!

(please group reply)

> > How does the beep get turned off again?
> May be it is turn off by the speaker driver.
> 
> 
> BTW can't we do something with led ? This way it can be always enabled 
> without anoying people

It would be more complex code, afaict, and ps/2 keyboard may be
absent. But feel free to try, I'm not even sure beeping works
everywhere, so another hack would be nice...

							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

[Stefan Seyfried]

On Tue, Jun 12, 2007 at 03:12:57PM +0000, Pavel Machek wrote:
> Hi!
> 
> (please group reply)
> 
> > > How does the beep get turned off again?
> > May be it is turn off by the speaker driver.
> > 
> > 
> > BTW can't we do something with led ? This way it can be always enabled 
> > without anoying people
> 
> It would be more complex code, afaict, and ps/2 keyboard may be
> absent. But feel free to try, I'm not even sure beeping works
> everywhere, so another hack would be nice...

Many machines / keyboards blink the LEDs on power up and on resume anyway,
so it is hard to see if the blink was from the BIOS or from Linux.
And don't we need to resume the keyboard controller before we can start
blinking the LEDs?
-- 
Stefan Seyfried
QA / R&D Team Mobile Devices        |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: beeping patch for debugging acpi sleep

[Pavel Machek]

Hi!

> > 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.
> > 
> > Signed-off-by: Pavel Machek <pavel@suse.cz>
> > 
> > diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S
> > index b781b38..cbf136e 100644
> > --- a/arch/i386/kernel/acpi/wakeup.S
> > +++ b/arch/i386/kernel/acpi/wakeup.S
> > @@ -11,7 +11,22 @@ # Do we need to deal with A20? It is oka
> >  #
> >  # If physical address of wakeup_code is 0x12345, BIOS should call us with
> >  # cs = 0x1234, eip = 0x05
> > -# 
> > +#
> > +
> > +#define BEEP \
> > +	inb	$97, %al; 	\
> > +	outb	%al, $0x80; 	\
> > +	movb	$3, %al; 	\
> > +	outb	%al, $97; 	\
> > +	outb	%al, $0x80; 	\
> > +	movb	$-74, %al; 	\
> > +	outb	%al, $67; 	\
> > +	outb	%al, $0x80; 	\
> > +	movb	$-119, %al; 	\
> > +	outb	%al, $66; 	\
> > +	outb	%al, $0x80; 	\
> > +	movb	$15, %al; 	\
> > +	outb	%al, $66;
> >  
> >  ALIGN
> >  	.align	4096
> > @@ -20,6 +35,9 @@ wakeup_code:
> >  	wakeup_code_start = .
> >  	.code16
> >  
> > +# Uncomment this to make your computer start producing ugly noise as soon
> > +# as BIOS returns to this real-mode entry point.
> > +#	BEEP
> >   	movw	$0xb800, %ax
> >  	movw	%ax,%fs
> >  	movw	$0x0e00 + 'L', %fs:(0x10)
> > 
> 
> How does the beep get turned off again?

Typically, pcmcia beeps after resume, making it quiet. If not, echo ^G
does it.

> Should the BEEP line be uncommented (in -mm at least)?

It's too gross a hack, I'd say. It is only ever useful if machine is
completely dead after s2ram.
									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

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

Hi.

Wouldn't it be much more useful if it was unconditionally compiled in
and controlled instead by a sysfs entry? That way it will be far more
useful to $user who doesn't know or want to know how to compile and
install a kernel, but wants to do what they can to get provide helpful
debugging info and perhaps even get it going.

Yes, Pavel, I'll supply a patch if you (plural) agree.

Regards,

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: beeping patch for debugging acpi sleep

[Rafael J. Wysocki]

Hi,

On Tuesday, 12 June 2007 00:42, Nigel Cunningham wrote:
> Hi.
> 
> Wouldn't it be much more useful if it was unconditionally compiled in
> and controlled instead by a sysfs entry? That way it will be far more
> useful to $user who doesn't know or want to know how to compile and
> install a kernel, but wants to do what they can to get provide helpful
> debugging info and perhaps even get it going.

I like this idea.

> Yes, Pavel, I'll supply a patch if you (plural) agree.

I agree.  :-)

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: beeping patch for debugging acpi sleep

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

Hi.

On Tue, 2007-06-12 at 14:11 +0200, Rafael J. Wysocki wrote:
> Hi,
> 
> On Tuesday, 12 June 2007 00:42, Nigel Cunningham wrote:
> > Hi.
> > 
> > Wouldn't it be much more useful if it was unconditionally compiled in
> > and controlled instead by a sysfs entry? That way it will be far more
> > useful to $user who doesn't know or want to know how to compile and
> > install a kernel, but wants to do what they can to get provide helpful
> > debugging info and perhaps even get it going.
> 
> I like this idea.
> 
> > Yes, Pavel, I'll supply a patch if you (plural) agree.
> 
> I agree.  :-)

Ok. I'll take Pavel's silence as agreement too. I'll be a little slow
(as usual, nowadays!), but will try to get it done next week. I think I
can in clear conscience do it on Redhat time if I don't manage it
beforehand.

Regards,

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: beeping patch for debugging acpi sleep

[Pavel Machek]

Hi!

> > > Wouldn't it be much more useful if it was unconditionally compiled in
> > > and controlled instead by a sysfs entry? That way it will be far more
> > > useful to $user who doesn't know or want to know how to compile and
> > > install a kernel, but wants to do what they can to get provide helpful
> > > debugging info and perhaps even get it going.
> > 
> > I like this idea.
> > 
> > > Yes, Pavel, I'll supply a patch if you (plural) agree.
> > 
> > I agree.  :-)
> 
> Ok. I'll take Pavel's silence as agreement too. I'll be a little slow
> (as usual, nowadays!), but will try to get it done next week. I think I
> can in clear conscience do it on Redhat time if I don't manage it
> beforehand.

Well, everyone wants it so what can I do... Stefan basically posted 3
liner to do that, and that one will probably work... so just test it.

Oh, and please keep the macro, so it can be moved around .S file for
finding out where it crashes.
									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

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

Hi.

On Wed, 2007-06-13 at 10:24 +0200, Pavel Machek wrote:
> Hi!
> 
> > > > Wouldn't it be much more useful if it was unconditionally compiled in
> > > > and controlled instead by a sysfs entry? That way it will be far more
> > > > useful to $user who doesn't know or want to know how to compile and
> > > > install a kernel, but wants to do what they can to get provide helpful
> > > > debugging info and perhaps even get it going.
> > > 
> > > I like this idea.
> > > 
> > > > Yes, Pavel, I'll supply a patch if you (plural) agree.
> > > 
> > > I agree.  :-)
> > 
> > Ok. I'll take Pavel's silence as agreement too. I'll be a little slow
> > (as usual, nowadays!), but will try to get it done next week. I think I
> > can in clear conscience do it on Redhat time if I don't manage it
> > beforehand.
> 
> Well, everyone wants it so what can I do... Stefan basically posted 3
> liner to do that, and that one will probably work... so just test it.

As he admitted, it's a quick and dirty hack. I'd like to try something
nicer.

> Oh, and please keep the macro, so it can be moved around .S file for
> finding out where it crashes.

Are there other points you'd like to nominate? It would defeat the logic
for implementing a nice interface if you still have to recompile your
kernel to test beeping in another place.

Regards,

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: beeping patch for debugging acpi sleep

[Pavel Machek]

Hi!

> > > Ok. I'll take Pavel's silence as agreement too. I'll be a little slow
> > > (as usual, nowadays!), but will try to get it done next week. I think I
> > > can in clear conscience do it on Redhat time if I don't manage it
> > > beforehand.
> > 
> > Well, everyone wants it so what can I do... Stefan basically posted 3
> > liner to do that, and that one will probably work... so just test it.
> 
> As he admitted, it's a quick and dirty hack. I'd like to try something
> nicer.

Well, his hack + rename one variable and there's one very nice solution.

> > Oh, and please keep the macro, so it can be moved around .S file for
> > finding out where it crashes.
> 
> Are there other points you'd like to nominate? It would defeat the logic
> for implementing a nice interface if you still have to recompile your
> kernel to test beeping in another place.

Just before entering C would be another interesting point.
									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

[Rafael J. Wysocki]

On Wednesday, 13 June 2007 14:28, Pavel Machek wrote:
> Hi!
> 
> > > > Ok. I'll take Pavel's silence as agreement too. I'll be a little slow
> > > > (as usual, nowadays!), but will try to get it done next week. I think I
> > > > can in clear conscience do it on Redhat time if I don't manage it
> > > > beforehand.
> > > 
> > > Well, everyone wants it so what can I do... Stefan basically posted 3
> > > liner to do that, and that one will probably work... so just test it.
> > 
> > As he admitted, it's a quick and dirty hack. I'd like to try something
> > nicer.
> 
> Well, his hack + rename one variable and there's one very nice solution.
> 
> > > Oh, and please keep the macro, so it can be moved around .S file for
> > > finding out where it crashes.
> > 
> > Are there other points you'd like to nominate? It would defeat the logic
> > for implementing a nice interface if you still have to recompile your
> > kernel to test beeping in another place.
> 
> Just before entering C would be another interesting point.

Well, x86_64 version would be nice to have too. ;-)

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

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/   :-)

Re: [BUG] acpi double resume and fail

[Mark Lord]

Christian Leber 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.
> 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)

I had that problem here with Feisty on a Dell i9300 (and on a Dell i9400).
We fixed it by replacing the /etc/acpi/* scripts with my own script.

-ml