Hi all
Here's what I have after today's work.
I haven't yet been able to test on x86, but can confirm that it works okay on x86_64. I'm currently working towards testing it on my old Omnibook. My P4 desktop won't resume from suspend to ram at all, and hasn't produced any beeps.
I needed to move the BEEP invocation to after the data segment is reloaded, so that the test could access the variable. That was pretty tricky to find - no oops or anything bad prior, it just didn't beep when expected.
A couple of notes:
- I'd like to put the BEEP macro somewhere that can be shared by x86 32 and 64. If that's a good idea, any suggestions on where? Nothing occurs to me straight off.
- I've just switched from Evo to Kmail. Please let me know if there's any mangling of the patch.
Regards,
Nigel
arch/i386/kernel/acpi/wakeup.S | 29 ++++++++++++++++++++++++++++-
arch/x86_64/kernel/acpi/wakeup.S | 25 +++++++++++++++++++++++++
include/linux/acpi.h | 1 +
kernel/power/main.c | 23 +++++++++++++++++++++++
4 files changed, 77 insertions(+), 1 deletion(-)
diff -ruNp 970-str-beep.patch-old/arch/i386/kernel/acpi/wakeup.S 970-str-beep.patch-new/arch/i386/kernel/acpi/wakeup.S
--- 970-str-beep.patch-old/arch/i386/kernel/acpi/wakeup.S 2007-06-19 12:15:25.000000000 +1000
+++ 970-str-beep.patch-new/arch/i386/kernel/acpi/wakeup.S 2007-06-19 21:14:49.000000000 +1000
@@ -11,7 +11,22 @@
#
# 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
@@ -31,6 +46,11 @@ wakeup_code:
movw %cs, %ax
movw %ax, %ds # Make ds:0 point to wakeup_start
movw %ax, %ss
+
+ testl $1, beep_flags - wakeup_code
+ jz 1f
+ BEEP
+1:
mov $(wakeup_stack - wakeup_code), %sp # Private stack is needed for ASUS board
movw $0x0e00 + 'S', %fs:(0x12)
@@ -88,6 +108,10 @@ wakeup_code:
cmpl $0x12345678, %eax
jne bogus_real_magic
+ testl $2, beep_flags - wakeup_code
+ jz 1f
+ BEEP
+1:
ljmpl $__KERNEL_CS,$wakeup_pmode_return
real_save_gdt: .word 0
@@ -98,6 +122,7 @@ real_save_cr4: .long 0
real_magic: .long 0
video_mode: .long 0
video_flags: .long 0
+beep_flags: .long 0
real_efer_save_restore: .long 0
real_save_efer_edx: .long 0
real_save_efer_eax: .long 0
@@ -261,6 +286,8 @@ ENTRY(acpi_copy_wakeup_routine)
movl %edx, video_mode - wakeup_start (%eax)
movl acpi_video_flags, %edx
movl %edx, video_flags - wakeup_start (%eax)
+ movl s2ram_beep, %edx
+ movl %edx, beep_flags - wakeup_start (%eax)
movl $0x12345678, real_magic - wakeup_start (%eax)
movl $0x12345678, saved_magic
ret
diff -ruNp 970-str-beep.patch-old/arch/x86_64/kernel/acpi/wakeup.S 970-str-beep.patch-new/arch/x86_64/kernel/acpi/wakeup.S
--- 970-str-beep.patch-old/arch/x86_64/kernel/acpi/wakeup.S 2007-06-19 12:15:28.000000000 +1000
+++ 970-str-beep.patch-new/arch/x86_64/kernel/acpi/wakeup.S 2007-06-19 21:14:49.000000000 +1000
@@ -16,6 +16,21 @@
# 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 16
@@ -33,6 +48,13 @@ wakeup_code:
movw %cs, %ax
movw %ax, %ds # Make ds:0 point to wakeup_start
movw %ax, %ss
+
+ # Data segment must be set up before we can see whether to beep.
+ testl $1, beep_flags - wakeup_code
+ jz 1f
+ BEEP
+1:
+
# Private stack is needed for ASUS board
mov $(wakeup_stack - wakeup_code), %sp
@@ -229,6 +251,7 @@ gdt_48a:
.long gdta - wakeup_code # gdt base (relocated in later)
real_magic: .quad 0
+beep_flags: .quad 0
video_mode: .quad 0
video_flags: .quad 0
@@ -344,6 +367,8 @@ ENTRY(acpi_copy_wakeup_routine)
pushq %rax
pushq %rdx
+ movl s2ram_beep, %edx
+ movl %edx, beep_flags - wakeup_start (,%rdi)
movl saved_video_mode, %edx
movl %edx, video_mode - wakeup_start (,%rdi)
movl acpi_video_flags, %edx
diff -ruNp 970-str-beep.patch-old/include/linux/acpi.h 970-str-beep.patch-new/include/linux/acpi.h
--- 970-str-beep.patch-old/include/linux/acpi.h 2007-06-19 21:15:08.000000000 +1000
+++ 970-str-beep.patch-new/include/linux/acpi.h 2007-06-19 21:14:49.000000000 +1000
@@ -123,6 +123,7 @@ extern int pci_mmcfg_config_num;
extern int sbf_port;
extern unsigned long acpi_video_flags;
+extern unsigned long s2ram_beep;
#else /* !CONFIG_ACPI */
diff -ruNp 970-str-beep.patch-old/kernel/power/main.c 970-str-beep.patch-new/kernel/power/main.c
--- 970-str-beep.patch-old/kernel/power/main.c 2007-06-19 12:15:55.000000000 +1000
+++ 970-str-beep.patch-new/kernel/power/main.c 2007-06-19 21:14:49.000000000 +1000
@@ -308,6 +308,27 @@ static ssize_t state_store(struct kset *
power_attr(state);
+unsigned long s2ram_beep = 0;
+
+static ssize_t s2ram_beep_show(struct kset *kset, char *buf)
+{
+ return sprintf(buf, "%d\n", s2ram_beep);
+}
+
+static ssize_t
+s2ram_beep_store(struct kset *kset, const char *buf, size_t n)
+{
+ int val;
+
+ if (sscanf(buf, "%d", &val) > 0) {
+ s2ram_beep = val;
+ return n;
+ }
+ return -EINVAL;
+}
+
+power_attr(s2ram_beep);
+
#ifdef CONFIG_PM_TRACE
int pm_trace_enabled;
@@ -333,11 +354,13 @@ power_attr(pm_trace);
static struct attribute * g[] = {
&state_attr.attr,
&pm_trace_attr.attr,
+ &s2ram_beep_attr.attr,
NULL,
};
#else
static struct attribute * g[] = {
&state_attr.attr,
+ &s2ram_beep_attr.attr,
NULL,
};
#endif /* CONFIG_PM_TRACE */
--
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia
Hi Nigel,
On Tuesday, 19 June 2007 13:18, Nigel Cunningham wrote:
> Hi all
>
> Here's what I have after today's work.
>
> I haven't yet been able to test on x86, but can confirm that it works okay on
> x86_64. I'm currently working towards testing it on my old Omnibook. My P4
> desktop won't resume from suspend to ram at all, and hasn't produced any
> beeps.
>
> I needed to move the BEEP invocation to after the data segment is reloaded,
> so that the test could access the variable. That was pretty tricky to find -
> no oops or anything bad prior, it just didn't beep when expected.
>
> A couple of notes:
>
> - I'd like to put the BEEP macro somewhere that can be shared by x86 32 and
> 64. If that's a good idea, any suggestions on where? Nothing occurs to me
> straight off.
I don't know either. I think Andi is the right person to ask (CC added).
> - I've just switched from Evo to Kmail. Please let me know if there's any
> mangling of the patch.
The patch looks good to me. I'll try to run it on an i386 tomorrow.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
Hi,
On Tuesday, 19 June 2007 23:33, Rafael J. Wysocki wrote:
> On Tuesday, 19 June 2007 13:18, Nigel Cunningham wrote:
> > Hi all
> >
> > Here's what I have after today's work.
> >
> > I haven't yet been able to test on x86, but can confirm that it works okay on
> > x86_64. I'm currently working towards testing it on my old Omnibook. My P4
> > desktop won't resume from suspend to ram at all, and hasn't produced any
> > beeps.
> >
> > I needed to move the BEEP invocation to after the data segment is reloaded,
> > so that the test could access the variable. That was pretty tricky to find -
> > no oops or anything bad prior, it just didn't beep when expected.
> >
> > A couple of notes:
> >
> > - I'd like to put the BEEP macro somewhere that can be shared by x86 32 and
> > 64. If that's a good idea, any suggestions on where? Nothing occurs to me
> > straight off.
>
> I don't know either. I think Andi is the right person to ask (CC added).
>
> > - I've just switched from Evo to Kmail. Please let me know if there's any
> > mangling of the patch.
Unfortunately, the message is encoded as "quoted printable" which results in
the whitespace being mangled.
> The patch looks good to me. I'll try to run it on an i386 tomorrow.
I've recoded it and rediffed against -rc5 with the hibernation and suspend
patchset. The resut is at
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc5/patches/29-Optional-Beeping-During-Resume-From-RAM.patch
Well, my i386 test box doesn't seem to be able to beep at all. I'll have to
look for another one ...
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
Hi.
On Thursday 21 June 2007 08:09:26 Rafael J. Wysocki wrote:
> Hi,
>
> On Tuesday, 19 June 2007 23:33, Rafael J. Wysocki wrote:
> > On Tuesday, 19 June 2007 13:18, Nigel Cunningham wrote:
> > > Hi all
> > >
> > > Here's what I have after today's work.
> > >
> > > I haven't yet been able to test on x86, but can confirm that it works okay on
> > > x86_64. I'm currently working towards testing it on my old Omnibook. My P4
> > > desktop won't resume from suspend to ram at all, and hasn't produced any
> > > beeps.
> > >
> > > I needed to move the BEEP invocation to after the data segment is reloaded,
> > > so that the test could access the variable. That was pretty tricky to find -
> > > no oops or anything bad prior, it just didn't beep when expected.
> > >
> > > A couple of notes:
> > >
> > > - I'd like to put the BEEP macro somewhere that can be shared by x86 32 and
> > > 64. If that's a good idea, any suggestions on where? Nothing occurs to me
> > > straight off.
> >
> > I don't know either. I think Andi is the right person to ask (CC added).
> >
> > > - I've just switched from Evo to Kmail. Please let me know if there's any
> > > mangling of the patch.
>
> Unfortunately, the message is encoded as "quoted printable" which results in
> the whitespace being mangled.
>
> > The patch looks good to me. I'll try to run it on an i386 tomorrow.
>
> I've recoded it and rediffed against -rc5 with the hibernation and suspend
> patchset. The resut is at
>
> http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc5/patches/29-Optional-Beeping-During-Resume-From-RAM.patch
>
> Well, my i386 test box doesn't seem to be able to beep at all. I'll have to
> look for another one ...
Ok. No success with the Omnibook yet, though I did see it mentioned in Documentation/... as needing a vbepost.
Think I found the right option. Does this patch come through better?
Nigel
arch/i386/kernel/acpi/wakeup.S | 29 ++++++++++++++++++++++++++++-
arch/x86_64/kernel/acpi/wakeup.S | 25 +++++++++++++++++++++++++
include/linux/acpi.h | 1 +
kernel/power/main.c | 23 +++++++++++++++++++++++
4 files changed, 77 insertions(+), 1 deletion(-)
diff -ruNp 970-str-beep.patch-old/arch/i386/kernel/acpi/wakeup.S 970-str-beep.patch-new/arch/i386/kernel/acpi/wakeup.S
--- 970-str-beep.patch-old/arch/i386/kernel/acpi/wakeup.S 2007-06-19 12:15:25.000000000 +1000
+++ 970-str-beep.patch-new/arch/i386/kernel/acpi/wakeup.S 2007-06-19 21:14:49.000000000 +1000
@@ -11,7 +11,22 @@
#
# 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
@@ -31,6 +46,11 @@ wakeup_code:
movw %cs, %ax
movw %ax, %ds # Make ds:0 point to wakeup_start
movw %ax, %ss
+
+ testl $1, beep_flags - wakeup_code
+ jz 1f
+ BEEP
+1:
mov $(wakeup_stack - wakeup_code), %sp # Private stack is needed for ASUS board
movw $0x0e00 + 'S', %fs:(0x12)
@@ -88,6 +108,10 @@ wakeup_code:
cmpl $0x12345678, %eax
jne bogus_real_magic
+ testl $2, beep_flags - wakeup_code
+ jz 1f
+ BEEP
+1:
ljmpl $__KERNEL_CS,$wakeup_pmode_return
real_save_gdt: .word 0
@@ -98,6 +122,7 @@ real_save_cr4: .long 0
real_magic: .long 0
video_mode: .long 0
video_flags: .long 0
+beep_flags: .long 0
real_efer_save_restore: .long 0
real_save_efer_edx: .long 0
real_save_efer_eax: .long 0
@@ -261,6 +286,8 @@ ENTRY(acpi_copy_wakeup_routine)
movl %edx, video_mode - wakeup_start (%eax)
movl acpi_video_flags, %edx
movl %edx, video_flags - wakeup_start (%eax)
+ movl s2ram_beep, %edx
+ movl %edx, beep_flags - wakeup_start (%eax)
movl $0x12345678, real_magic - wakeup_start (%eax)
movl $0x12345678, saved_magic
ret
diff -ruNp 970-str-beep.patch-old/arch/x86_64/kernel/acpi/wakeup.S 970-str-beep.patch-new/arch/x86_64/kernel/acpi/wakeup.S
--- 970-str-beep.patch-old/arch/x86_64/kernel/acpi/wakeup.S 2007-06-19 12:15:28.000000000 +1000
+++ 970-str-beep.patch-new/arch/x86_64/kernel/acpi/wakeup.S 2007-06-19 21:14:49.000000000 +1000
@@ -16,6 +16,21 @@
# 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 16
@@ -33,6 +48,13 @@ wakeup_code:
movw %cs, %ax
movw %ax, %ds # Make ds:0 point to wakeup_start
movw %ax, %ss
+
+ # Data segment must be set up before we can see whether to beep.
+ testl $1, beep_flags - wakeup_code
+ jz 1f
+ BEEP
+1:
+
# Private stack is needed for ASUS board
mov $(wakeup_stack - wakeup_code), %sp
@@ -229,6 +251,7 @@ gdt_48a:
.long gdta - wakeup_code # gdt base (relocated in later)
real_magic: .quad 0
+beep_flags: .quad 0
video_mode: .quad 0
video_flags: .quad 0
@@ -344,6 +367,8 @@ ENTRY(acpi_copy_wakeup_routine)
pushq %rax
pushq %rdx
+ movl s2ram_beep, %edx
+ movl %edx, beep_flags - wakeup_start (,%rdi)
movl saved_video_mode, %edx
movl %edx, video_mode - wakeup_start (,%rdi)
movl acpi_video_flags, %edx
diff -ruNp 970-str-beep.patch-old/include/linux/acpi.h 970-str-beep.patch-new/include/linux/acpi.h
--- 970-str-beep.patch-old/include/linux/acpi.h 2007-06-19 21:15:08.000000000 +1000
+++ 970-str-beep.patch-new/include/linux/acpi.h 2007-06-19 21:14:49.000000000 +1000
@@ -123,6 +123,7 @@ extern int pci_mmcfg_config_num;
extern int sbf_port;
extern unsigned long acpi_video_flags;
+extern unsigned long s2ram_beep;
#else /* !CONFIG_ACPI */
diff -ruNp 970-str-beep.patch-old/kernel/power/main.c 970-str-beep.patch-new/kernel/power/main.c
--- 970-str-beep.patch-old/kernel/power/main.c 2007-06-19 12:15:55.000000000 +1000
+++ 970-str-beep.patch-new/kernel/power/main.c 2007-06-19 21:14:49.000000000 +1000
@@ -308,6 +308,27 @@ static ssize_t state_store(struct kset *
power_attr(state);
+unsigned long s2ram_beep = 0;
+
+static ssize_t s2ram_beep_show(struct kset *kset, char *buf)
+{
+ return sprintf(buf, "%d\n", s2ram_beep);
+}
+
+static ssize_t
+s2ram_beep_store(struct kset *kset, const char *buf, size_t n)
+{
+ int val;
+
+ if (sscanf(buf, "%d", &val) > 0) {
+ s2ram_beep = val;
+ return n;
+ }
+ return -EINVAL;
+}
+
+power_attr(s2ram_beep);
+
#ifdef CONFIG_PM_TRACE
int pm_trace_enabled;
@@ -333,11 +354,13 @@ power_attr(pm_trace);
static struct attribute * g[] = {
&state_attr.attr,
&pm_trace_attr.attr,
+ &s2ram_beep_attr.attr,
NULL,
};
#else
static struct attribute * g[] = {
&state_attr.attr,
+ &s2ram_beep_attr.attr,
NULL,
};
#endif /* CONFIG_PM_TRACE */
--
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia
Hi,
On Thursday, 21 June 2007 00:24, Nigel Cunningham wrote:
> On Thursday 21 June 2007 08:09:26 Rafael J. Wysocki wrote:
> > On Tuesday, 19 June 2007 23:33, Rafael J. Wysocki wrote:
> > > On Tuesday, 19 June 2007 13:18, Nigel Cunningham wrote:
> > > > Hi all
> > > >
> > > > Here's what I have after today's work.
> > > >
> > > > I haven't yet been able to test on x86, but can confirm that it works okay on
> > > > x86_64. I'm currently working towards testing it on my old Omnibook. My P4
> > > > desktop won't resume from suspend to ram at all, and hasn't produced any
> > > > beeps.
> > > >
> > > > I needed to move the BEEP invocation to after the data segment is reloaded,
> > > > so that the test could access the variable. That was pretty tricky to find -
> > > > no oops or anything bad prior, it just didn't beep when expected.
> > > >
> > > > A couple of notes:
> > > >
> > > > - I'd like to put the BEEP macro somewhere that can be shared by x86 32 and
> > > > 64. If that's a good idea, any suggestions on where? Nothing occurs to me
> > > > straight off.
> > >
> > > I don't know either. I think Andi is the right person to ask (CC added).
> > >
> > > > - I've just switched from Evo to Kmail. Please let me know if there's any
> > > > mangling of the patch.
> >
> > Unfortunately, the message is encoded as "quoted printable" which results in
> > the whitespace being mangled.
> >
> > > The patch looks good to me. I'll try to run it on an i386 tomorrow.
> >
> > I've recoded it and rediffed against -rc5 with the hibernation and suspend
> > patchset. The resut is at
> >
> > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc5/patches/29-Optional-Beeping-During-Resume-From-RAM.patch
> >
> > Well, my i386 test box doesn't seem to be able to beep at all. I'll have to
> > look for another one ...
>
> Ok. No success with the Omnibook yet, though I did see it mentioned in Documentation/... as needing a vbepost.
>
> Think I found the right option. Does this patch come through better?
No, it's still "quoted printable", at least on my system (but I use Kmail too).
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
Hi!
> Hi all
>
> Here's what I have after today's work.
>
> I haven't yet been able to test on x86, but can confirm that it works okay on x86_64. I'm currently working towards testing it on my old Omnibook. My P4 desktop won't resume from suspend to ram at all, and hasn't produced any beeps.
>
> I needed to move the BEEP invocation to after the data segment is reloaded, so that the test could access the variable. That was pretty tricky to find - no oops or anything bad prior, it just didn't beep when expected.
>
> A couple of notes:
>
> - I'd like to put the BEEP macro somewhere that can be shared by x86 32 and 64. If that's a good idea, any suggestions on where? Nothing occurs to me straight off.
> - I've just switched from Evo to Kmail. Please let me know if there's any mangling of the patch.
>
> Regards,
>
> Nigel
>
> arch/i386/kernel/acpi/wakeup.S | 29 ++++++++++++++++++++++++++++-
> arch/x86_64/kernel/acpi/wakeup.S | 25 +++++++++++++++++++++++++
> include/linux/acpi.h | 1 +
> kernel/power/main.c | 23 +++++++++++++++++++++++
> 4 files changed, 77 insertions(+), 1 deletion(-)
> diff -ruNp 970-str-beep.patch-old/arch/i386/kernel/acpi/wakeup.S 970-str-beep.patch-new/arch/i386/kernel/acpi/wakeup.S
> --- 970-str-beep.patch-old/arch/i386/kernel/acpi/wakeup.S 2007-06-19 12:15:25.000000000 +1000
> +++ 970-str-beep.patch-new/arch/i386/kernel/acpi/wakeup.S 2007-06-19 21:14:49.000000000 +1000
> @@ -11,7 +11,22 @@
> #
> # 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
> @@ -31,6 +46,11 @@ wakeup_code:
> movw %cs, %ax
> movw %ax, %ds # Make ds:0 point to wakeup_start
> movw %ax, %ss
> +
> + testl $1, beep_flags - wakeup_code
> + jz 1f
> + BEEP
> +1:
Can we rename/reuse existing flag variable?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi.
On Friday 29 June 2007 00:25:32 Pavel Machek wrote:
> Hi!
>
> > Hi all
> >
> > Here's what I have after today's work.
> >
> > I haven't yet been able to test on x86, but can confirm that it works okay
on x86_64. I'm currently working towards testing it on my old Omnibook. My P4
desktop won't resume from suspend to ram at all, and hasn't produced any
beeps.
> >
> > I needed to move the BEEP invocation to after the data segment is
reloaded, so that the test could access the variable. That was pretty tricky
to find - no oops or anything bad prior, it just didn't beep when expected.
> >
> > A couple of notes:
> >
> > - I'd like to put the BEEP macro somewhere that can be shared by x86 32
and 64. If that's a good idea, any suggestions on where? Nothing occurs to me
straight off.
> > - I've just switched from Evo to Kmail. Please let me know if there's any
mangling of the patch.
> >
> > Regards,
> >
> > Nigel
> >
> > arch/i386/kernel/acpi/wakeup.S | 29 ++++++++++++++++++++++++++++-
> > arch/x86_64/kernel/acpi/wakeup.S | 25 +++++++++++++++++++++++++
> > include/linux/acpi.h | 1 +
> > kernel/power/main.c | 23 +++++++++++++++++++++++
> > 4 files changed, 77 insertions(+), 1 deletion(-)
> > diff -ruNp 970-str-beep.patch-old/arch/i386/kernel/acpi/wakeup.S
970-str-beep.patch-new/arch/i386/kernel/acpi/wakeup.S
> > --- 970-str-beep.patch-old/arch/i386/kernel/acpi/wakeup.S 2007-06-19
12:15:25.000000000 +1000
> > +++ 970-str-beep.patch-new/arch/i386/kernel/acpi/wakeup.S 2007-06-19
21:14:49.000000000 +1000
> > @@ -11,7 +11,22 @@
> > #
> > # 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
> > @@ -31,6 +46,11 @@ wakeup_code:
> > movw %cs, %ax
> > movw %ax, %ds # Make ds:0 point to wakeup_start
> > movw %ax, %ss
> > +
> > + testl $1, beep_flags - wakeup_code
> > + jz 1f
> > + BEEP
> > +1:
>
> Can we rename/reuse existing flag variable?
Sorry, but I can't resist the opportunity to say "Send a patch!" :)
Seriously, though, I'd prefer not to. If we rename that acpi video flags
variable (I assume this is what you're thinking of), we only create cause for
confusion. A variable should for debugging or for controlling quirks, not for
both at the same time.
Regards,
Nigel
--
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia
On Fri, Jun 29, 2007 at 08:27:12AM +1000, Nigel Cunningham wrote:
> > Can we rename/reuse existing flag variable?
>
> Sorry, but I can't resist the opportunity to say "Send a patch!" :)
>
> Seriously, though, I'd prefer not to. If we rename that acpi video flags
> variable (I assume this is what you're thinking of), we only create cause for
> confusion. A variable should for debugging or for controlling quirks, not for
> both at the same time.
I agree. And video_flags is something totally different :-)
I just used that one in my ad-hoc hack (which actually was only to illustrate
the idea) because a) it was enough to show the intent and b) i did not know
how to do it better ;-)
--
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!
> > > ALIGN
> > > .align 4096
> > > @@ -31,6 +46,11 @@ wakeup_code:
> > > movw %cs, %ax
> > > movw %ax, %ds # Make ds:0 point to wakeup_start
> > > movw %ax, %ss
> > > +
> > > + testl $1, beep_flags - wakeup_code
> > > + jz 1f
> > > + BEEP
> > > +1:
> >
> > Can we rename/reuse existing flag variable?
>
> Sorry, but I can't resist the opportunity to say "Send a patch!" :)
>
> Seriously, though, I'd prefer not to. If we rename that acpi video flags
> variable (I assume this is what you're thinking of), we only create cause for
> confusion. A variable should for debugging or for controlling quirks, not for
> both at the same time.
Cause for confusion? We are currently using 2 bits of that variable,
and we want to add one more bit. I seriously doubt that can confuse
anyone.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
On Saturday, 30 June 2007 00:35, Pavel Machek wrote:
> Hi!
>
> > > > ALIGN
> > > > .align 4096
> > > > @@ -31,6 +46,11 @@ wakeup_code:
> > > > movw %cs, %ax
> > > > movw %ax, %ds # Make ds:0 point to wakeup_start
> > > > movw %ax, %ss
> > > > +
> > > > + testl $1, beep_flags - wakeup_code
> > > > + jz 1f
> > > > + BEEP
> > > > +1:
> > >
> > > Can we rename/reuse existing flag variable?
> >
> > Sorry, but I can't resist the opportunity to say "Send a patch!" :)
> >
> > Seriously, though, I'd prefer not to. If we rename that acpi video flags
> > variable (I assume this is what you're thinking of), we only create cause for
> > confusion. A variable should for debugging or for controlling quirks, not for
> > both at the same time.
>
> Cause for confusion? We are currently using 2 bits of that variable,
> and we want to add one more bit. I seriously doubt that can confuse
> anyone.
Well, indeed it would be more elegant to rename the existing flags variable
and use another bit out of it, but I personally don't think it's _that_
important. At least, I don't think we should block the patch because of that.
BTW, has anyone confirmed that it works on i386?
BTW2, Nigel, please fix the formats in s2ram_beep_show()/_store(), they
cause gcc to spit ugly warnings on some architectures.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
Hi!
> > > Sorry, but I can't resist the opportunity to say "Send a patch!" :)
> > >
> > > Seriously, though, I'd prefer not to. If we rename that acpi video flags
> > > variable (I assume this is what you're thinking of), we only create cause for
> > > confusion. A variable should for debugging or for controlling quirks, not for
> > > both at the same time.
> >
> > Cause for confusion? We are currently using 2 bits of that variable,
> > and we want to add one more bit. I seriously doubt that can confuse
> > anyone.
>
> Well, indeed it would be more elegant to rename the existing flags variable
> and use another bit out of it, but I personally don't think it's _that_
> important. At least, I don't think we should block the patch
> because of that.
It is not _that_ important.
> BTW, has anyone confirmed that it works on i386?
If you have patch somewhere nearby, I can test it on i386 and make it
use just one flags variable.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
On Saturday, 30 June 2007 12:11, Pavel Machek wrote:
> Hi!
>
> > > > Sorry, but I can't resist the opportunity to say "Send a patch!" :)
> > > >
> > > > Seriously, though, I'd prefer not to. If we rename that acpi video flags
> > > > variable (I assume this is what you're thinking of), we only create cause for
> > > > confusion. A variable should for debugging or for controlling quirks, not for
> > > > both at the same time.
> > >
> > > Cause for confusion? We are currently using 2 bits of that variable,
> > > and we want to add one more bit. I seriously doubt that can confuse
> > > anyone.
> >
> > Well, indeed it would be more elegant to rename the existing flags variable
> > and use another bit out of it, but I personally don't think it's _that_
> > important. At least, I don't think we should block the patch
> > because of that.
>
> It is not _that_ important.
>
> > BTW, has anyone confirmed that it works on i386?
>
> If you have patch somewhere nearby, I can test it on i386 and make it
> use just one flags variable.
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc6/patches/28-Optional-Beeping-During-Resume-From-RAM.patch
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth