acpi double resume and fail

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)

Quoted 3 lines

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.

Quoted 6 lines

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.

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.

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.

Quoted 4 lines · 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.

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

Quoted 7 lines · Jan-Benedict Glaw

Quoted 4 lines · 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.

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

Well, try it; it is too annoying to be unconditional.

Hi.

Quoted 7 lines · Pavel Machek

Quoted 6 lines · Jan-Benedict Glaw

Quoted 4 lines · 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.

Quoted 3 lines

Quoted 1 line

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.

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

Quoted 7 lines

arch/i386/kernel/acpi/wakeup.S +0 -0

@@ -20,6 +35,9 @@ wakeup_code:
 	wakeup_code_start = .
 	.code16
 

arch/i386/kernel/acpi/wakeup.S wakeup_code: · line 39

Quoted 2 lines

arch/i386/kernel/acpi/wakeup.S +2 -0

+# 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

arch/i386/kernel/acpi/wakeup.S wakeup_code: · line 40

Quoted 1 line

arch/i386/kernel/acpi/wakeup.S +1 -0

+	BEEP

1:

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 <[email protected]>

arch/i386/kernel/acpi/wakeup.S +16 -1

index b781b38..cbf136e 100644
@@ -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

On Sat, 9 Jun 2007 15:08:17 +0200
Pavel Machek <[email protected]> wrote:

How does the beep get turned off again?

Quoted 1 line

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

Hi!

(please group reply)

Quoted 4 lines

Quoted 1 line

How does the beep get turned off again?

May be it is turn off by the speaker driver.

Quoted 2 lines

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

Quoted 38 lines

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 <[email protected]>

arch/i386/kernel/acpi/wakeup.S +16 -1

index b781b38..cbf136e 100644
@@ -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
 

arch/i386/kernel/acpi/wakeup.S wakeup_code: · line 43

Quoted 7 lines

arch/i386/kernel/acpi/wakeup.S +3 -0

+# 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)?

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.

Hi,

Quoted 7 lines · Nigel Cunningham

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.

Quoted 1 line

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

I agree. :-)

Quoted 8 lines

Quoted 5 lines

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.

Quoted 3 lines

Quoted 1 line

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.

Hi!

Quoted 12 lines

Quoted 11 lines

Quoted 5 lines

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.

Quoted 1 line

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

I agree. :-)

Quoted 4 lines

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 2 lines

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.

Hi!

Quoted 10 lines

Quoted 7 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

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.

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

Quoted 11 lines

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

Review

Quoted 5 lines

(quoted diff) +0 -5

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

Quoted 16 lines

Quoted 16 lines

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

(quoted diff) +0 -5

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

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)