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]>
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
On Sat, 2007-06-09 15:08:17 +0200, Pavel Machek <[email protected]> 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 [email protected] +49-172-7608481
Signature of: Eine Freie Meinung in einem Freien Kopf
the second : für einen Freien Staat voll Freier Bürger.
On Sat 2007-06-09 15:16:04, Jan-Benedict Glaw wrote:
> On Sat, 2007-06-09 15:08:17 +0200, Pavel Machek <[email protected]> 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
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 <[email protected]> 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
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 <[email protected]> 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
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)
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
On Sat, 9 Jun 2007 15:08:17 +0200
Pavel Machek <[email protected]> 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 <[email protected]>
>
> 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)?
Hi,
On Mon, 11 Jun 2007 12:00:34 -0700, Andrew Morton wrote:
> On Sat, 9 Jun 2007 15:08:17 +0200
> Pavel Machek <[email protected]> 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
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 <[email protected]>
> >
> > 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
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
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
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
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
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
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
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
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
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)
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/
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/
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
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/ :-)