H. Peter Anvin wrote:
Rafael J. Wysocki wrote:
The asm() for making beeps really need to be moved to a function and
cleaned up (redone in C using inb()/outb()) if they are to be
retained at all.
Yes, they are. For some people they're the only tool to debug broken
resume.
That's fine, but
On Sun, Feb 10, 2008 at 10:14:57PM +0100, Pavel Machek wrote:
> On Fri 2008-02-08 16:32:08, H. Peter Anvin wrote:
> > Rafael J. Wysocki wrote:
> >>
> >> Consolidated patch is appended. I'll test it tomorrow on x86-64.
> >>
> >> I'd like to add the cleaned up beeping code to it and perhaps try to p
On Fri 2008-02-08 16:32:08, H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
>>
>> Consolidated patch is appended. I'll test it tomorrow on x86-64.
>>
>> I'd like to add the cleaned up beeping code to it and perhaps try to push it
>> for -mm testing without any further changes. We can still do mo
On Saturday, 9 of February 2008, H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
> >
> > Consolidated patch is appended. I'll test it tomorrow on x86-64.
> >
> > I'd like to add the cleaned up beeping code to it and perhaps try to push it
> > for -mm testing without any further changes. We can
Rafael J. Wysocki wrote:
Consolidated patch is appended. I'll test it tomorrow on x86-64.
I'd like to add the cleaned up beeping code to it and perhaps try to push it
for -mm testing without any further changes. We can still do more cleanups in
followup patches.
The other thing to figure o
On Friday, 8 of February 2008, Pavel Machek wrote:
> On Fri 2008-02-08 23:01:51, Rafael J. Wysocki wrote:
> > On Friday, 8 of February 2008, Pavel Machek wrote:
> > > Hi!
> > >
> > > Rafael, this is for you.
> >
> > Thanks.
> >
> > > My cleanups, relative to your cleanup patch. You may need manu
On Fri 2008-02-08 23:01:51, Rafael J. Wysocki wrote:
> On Friday, 8 of February 2008, Pavel Machek wrote:
> > Hi!
> >
> > Rafael, this is for you.
>
> Thanks.
>
> > My cleanups, relative to your cleanup patch. You may need manual patching
> > around rep/stosd.
>
> OK, I'll try to merge it.
For
On Friday, 8 of February 2008, Pavel Machek wrote:
> Hi!
>
> Rafael, this is for you.
Thanks.
> My cleanups, relative to your cleanup patch. You may need manual patching
> around rep/stosd.
OK, I'll try to merge it.
Rafael
> diff --git a/arch/x86/kernel/acpi/realmode/Makefile
> b/arch/x86/k
On Fri 2008-02-08 22:56:08, Rafael J. Wysocki wrote:
> On Friday, 8 of February 2008, Pavel Machek wrote:
> > On Fri 2008-02-08 13:27:30, H. Peter Anvin wrote:
> > > Pavel Machek wrote:
> > >>
> > >> See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent
> > >> to the list). No probl
On Friday, 8 of February 2008, Pavel Machek wrote:
> On Fri 2008-02-08 13:27:30, H. Peter Anvin wrote:
> > Pavel Machek wrote:
> >>
> >> See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent
> >> to the list). No problem there, but table stored at nonzero
> >> offset. Short jump at
Hi!
Rafael, this is for you. My cleanups, relative to your cleanup
patch. You may need manual patching around rep/stosd.
Pavel
diff --git a/arch/x86/kernel/acpi/realmode/Makefile
b/arch/x86/kernel/acpi/realmode/Makefile
index b239f
Hi!
>> +.section ".header", "a"
>> +
>> +/* This should match the structure in wakeup.h */
>> +.globl wakeup_header
>> +wakeup_header:
>> +video_mode: .short 0 /* Video mode number */
>> +pmode_return: .byte 0x66, 0xea /* ljmpl */
>> +.long 0
Hi!
> I remember that I did about 1500 reboots to try to fix this.
> (According to hard disk's 'smart' statistics)
Poor you.
> Suggestion: the speaker usually is quite loud, thus it can be annoying to use
> for morse code or so.
> Why not to use keyboard leds for this purpose?
> (USB keyboard pr
Hi!
This cleans up .lds, making use of constants...
Pavel
diff --git a/arch/x86/kernel/acpi/realmode/wakeup.h
b/arch/x86/kernel/acpi/realmode/wakeup.h
index 4a26e27..ee7c68b 100644
--- a/arch/x86/kernel/acpi/realmode/wakeup.h
+++ b
On Fri, Feb 08, 2008 at 10:41:45PM +0100, Pavel Machek wrote:
> > Do we never need data from a .h file?
> > If we do name it wakeup.lds.S and kbuild
> > will fix it (assuming we have wakeup.lds
> > as a prerequisite where it is needed.
>
> Ok, I got it to work... but notice the ugly #undef :-(.
Gr
On Friday, 8 February 2008 23:13:46 Pavel Machek wrote:
> Hi!
>
> > > Can you post a delta against my versoin? I do not see any changes from
> > > a quick glance.
> >
> > Appended (plus I removed two hunks, one in arch/x86/Makefile and one in
> > drivers/acpi/sleep/main.c that were unrelated to t
> Do we never need data from a .h file?
> If we do name it wakeup.lds.S and kbuild
> will fix it (assuming we have wakeup.lds
> as a prerequisite where it is needed.
Ok, I got it to work... but notice the ugly #undef :-(.
Pavel
diff --git a
Hi!
> Okay, this uses the iodelay as the timesource... here is the total
> silliness (and totally untested, of course.)
Why untested? Testing suspend is easy ;-). s2ram from suspend.sf.net
tends to just work...
Pavel
> static inlin
Hi!
> And for good measure name it wakeup.lds.
>
> Do we never need data from a .h file?
> If we do name it wakeup.lds.S and kbuild
> will fix it (assuming we have wakeup.lds
> as a prerequisite where it is needed.
This does not work for me. gas (or someone?) puts # comments on the
beggining of
On Thu 2008-02-07 23:28:33, Sam Ravnborg wrote:
> > ===
> > --- /dev/null
> > +++ linux-2.6/arch/x86/kernel/acpi/realmode/wakeup.ld
> > @@ -0,0 +1,51 @@
> > +/*
> > + * wakeup.ld
> > + *
> > + * Linker script for the real-mode wakeup c
On Fri 2008-02-08 13:27:30, H. Peter Anvin wrote:
> Pavel Machek wrote:
>>
>> See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent
>> to the list). No problem there, but table stored at nonzero
>> offset. Short jump at the beggining of table would fix it (ugly).
>>
>
> Ugly, but it
Pavel Machek wrote:
See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent
to the list). No problem there, but table stored at nonzero
offset. Short jump at the beggining of table would fix it (ugly).
Ugly, but it's the standard way to deal. We have it in the bzImage
format,
Hi!
> > > > segments:offsets rear its ugly head here. I need %ds to point to my
> > > > data, and the way to do it is copy it from %cs; that needs start to be
> > > > at 0.
> > >
> > > Hm, why exactly is that necessay?
> >
> > It is not _neccessary_. Try to come up with another method that gets
On Fri, 8 Feb 2008, Pavel Machek wrote:
> > > segments:offsets rear its ugly head here. I need %ds to point to my
> > > data, and the way to do it is copy it from %cs; that needs start to be
> > > at 0.
> >
> > Hm, why exactly is that necessay?
>
> It is not _neccessary_. Try to come up with ano
Pavel Machek wrote:
Indirect call from where?
BIOS jumps to address you provide.
Where is this code?
arch/x86/kernel/acpi/realmode/wakeup.S
BIOS jumps to wakeup_code. With CS=something, IP=0. If wakeup code is
at other address than zero, I'll not be able to easily address data
below it.
Hi!
> > Can you post a delta against my versoin? I do not see any changes from
> > a quick glance.
>
> Appended (plus I removed two hunks, one in arch/x86/Makefile and one in
> drivers/acpi/sleep/main.c that were unrelated to the rest of the patch).
Thanks, applied.
> > This is probably more ac
On Fri 2008-02-08 13:02:57, H. Peter Anvin wrote:
> Pavel Machek wrote:
>> On Fri 2008-02-08 17:23:15, Rafael J. Wysocki wrote:
>>> On Friday, 8 of February 2008, Pavel Machek wrote:
Hi!
>>> Hi,
>>>
>> I really need the entry point to be at offset 0, so that I can get
>> pointers to my
Pavel Machek wrote:
On Fri 2008-02-08 17:23:15, Rafael J. Wysocki wrote:
On Friday, 8 of February 2008, Pavel Machek wrote:
Hi!
Hi,
I really need the entry point to be at offset 0, so
that I can get
pointers to my data. I could not figure out how to do
it any other
way. And if 0 is taken, I
On Fri 2008-02-08 17:23:15, Rafael J. Wysocki wrote:
> On Friday, 8 of February 2008, Pavel Machek wrote:
> > Hi!
>
> Hi,
>
> > > >I really need the entry point to be at offset 0, so
> > > >that I can get
> > > >pointers to my data. I could not figure out how to do
> > > >it any other
> > > >wa
On Friday, 8 of February 2008, Pavel Machek wrote:
> Hi!
Hi,
> > >I really need the entry point to be at offset 0, so
> > >that I can get
> > >pointers to my data. I could not figure out how to do
> > >it any other
> > >way. And if 0 is taken, I thought I'd put header at the
> > >end.
> > >
>
Pavel Machek wrote:
Hi!
I really need the entry point to be at offset 0, so
that I can get
pointers to my data. I could not figure out how to do
it any other
way. And if 0 is taken, I thought I'd put header at the
end.
Why not just put the structure at 0, and put pointers in
the structure
Hi!
> >I really need the entry point to be at offset 0, so
> >that I can get
> >pointers to my data. I could not figure out how to do
> >it any other
> >way. And if 0 is taken, I thought I'd put header at the
> >end.
> >
>
> Why not just put the structure at 0, and put pointers in
> the struc
Pavel Machek wrote:
I really need the entry point to be at offset 0, so that I can get
pointers to my data. I could not figure out how to do it any other
way. And if 0 is taken, I thought I'd put header at the end.
Why not just put the structure at 0, and put pointers in the structure
to eve
Hi!
> > > > > + header = (struct wakeup_header *)(acpi_realmode + 0x3f00);
> > > >
> > > > ... especially not with magic constants like this.
> > >
> > > Yeah. Pavel, what's at 0x3f00, btw?
> >
> > struct wakeup_header.
> >
> > I really need the entry point to be at offset 0, so that I ca
On Friday, 8 of February 2008, Pavel Machek wrote:
> Hi!
Hi,
> > > > - memcpy((void *)acpi_wakeup_address, &wakeup_start,
> > > > - &wakeup_end - &wakeup_start);
> > > > - acpi_copy_wakeup_routine(acpi_wakeup_address);
> > > > + memcpy((void *)acpi_realmode, &wakeup
Hi!
> > > - memcpy((void *)acpi_wakeup_address, &wakeup_start,
> > > -&wakeup_end - &wakeup_start);
> > > - acpi_copy_wakeup_routine(acpi_wakeup_address);
> > > + memcpy((void *)acpi_realmode, &wakeup_code_start, 4*PAGE_SIZE);
> >
> > Using a PAGE_SIZE multiplier here isn't a good thing..
Okay, this uses the iodelay as the timesource... here is the total
silliness (and totally untested, of course.)
-hpa
static inline void io_delay(void)
{
outb(0, 0x80);
}
static void udelay(int loops)
{
while (loops--)
io_delay(); /* Approximately 1 us */
}
static void beep(unsigne
Rafael J. Wysocki wrote:
On Thursday, 7 of February 2008, H. Peter Anvin wrote:
Rafael J. Wysocki wrote:
Index: linux-2.6/arch/x86/kernel/acpi/realmode/wakeup.S
===
--- /dev/null
+++ linux-2.6/arch/x86/kernel/acpi/realmode/wakeup.S
On Thursday, 7 of February 2008, Pavel Machek wrote:
> On Thu 2008-02-07 14:46:25, H. Peter Anvin wrote:
> > Pavel Machek wrote:
> >>
> >> This is probably more acceptable version of beep; but there are
> >> probably even better ways to clean it...
> >>
> >> if (wakeup_header.realmode_flags
On Thursday, 7 of February 2008, H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
> > Index: linux-2.6/arch/x86/kernel/acpi/realmode/wakeup.S
> > ===
> > --- /dev/null
> > +++ linux-2.6/arch/x86/kernel/acpi/realmode/wakeup.S
> > @@ -0,
On Thursday, 7 of February 2008, H. Peter Anvin wrote:
> Pavel Machek wrote:
> >
> > This is probably more acceptable version of beep; but there are
> > probably even better ways to clean it...
> >
> > if (wakeup_header.realmode_flags & 4) {
> > inb(97);
> >
On Thursday, 7 of February 2008, H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
> > - rep; stosl
> > + rep
> > + stosl
>
> Yuck!
>
> Please don't perpetuate the braindamage that this is two instructions.
> It's one instruction with a modifier;
Sure, it is.
> the fact that gas wants a s
On Thu 2008-02-07 14:46:25, H. Peter Anvin wrote:
> Pavel Machek wrote:
>>
>> This is probably more acceptable version of beep; but there are
>> probably even better ways to clean it...
>>
>> if (wakeup_header.realmode_flags & 4) {
>> inb(97);
>> outb(0, 0x80
On Thu 2008-02-07 14:45:35, H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
>
>> ENTRY(wakeup_long64)
>> wakeup_long64:
>> -movqsaved_magic, %rax
>> -movq$0x123456789abcdef0, %rdx
>> -cmpq%rdx, %rax
>> -jne bogus_64_magic
>> +movqsaved_magic, %rax
>> +
Pavel Machek wrote:
This is probably more acceptable version of beep; but there are
probably even better ways to clean it...
if (wakeup_header.realmode_flags & 4) {
inb(97);
outb(0, 0x80);
outb(3, 97);
outb(0, 0x80);
Rafael J. Wysocki wrote:
ENTRY(wakeup_long64)
wakeup_long64:
- movqsaved_magic, %rax
- movq$0x123456789abcdef0, %rdx
- cmpq%rdx, %rax
- jne bogus_64_magic
+ movqsaved_magic, %rax
+ movq$0x123456789abcdef0, %rdx
+ cmpq%rdx, %
Rafael J. Wysocki wrote:
- rep; stosl
+ rep
+ stosl
Yuck!
Please don't perpetuate the braindamage that this is two instructions.
It's one instruction with a modifier; the fact that gas wants a
separator is broken enough as it is.
-hpa
--
To unsubscribe from this l
On Thursday, 7 of February 2008, Pavel Machek wrote:
> Hi!
>
> > > > > This rewrites wakeup code to .c, and it fixes stack (should use movl
> > > > > ,%esp, not movw). Testers wanted. Makefile infrastructure was done by
> > > > > hpa, cleanups by rjw.
> > > >
> > > > I'll test it tomorrow
> > >
Rafael J. Wysocki wrote:
Index: linux-2.6/arch/x86/kernel/acpi/realmode/wakeup.S
===
--- /dev/null
+++ linux-2.6/arch/x86/kernel/acpi/realmode/wakeup.S
@@ -0,0 +1,122 @@
+/*
+ * ACPI wakeup real mode startup stub
+ */
+#include
+#in
Sam Ravnborg wrote:
+
+ . = 0;
+ .text : { *(.text*) }
+
+ . = ALIGN(16);
Why?
It's good practice to have at least paragraph (segment boundary)
alignment between different types of data. In the case of the .bss, it
also allows cleaning with rep;movsl.
It's tech
Hi!
> > > > This rewrites wakeup code to .c, and it fixes stack (should use movl
> > > > ,%esp, not movw). Testers wanted. Makefile infrastructure was done by
> > > > hpa, cleanups by rjw.
> > >
> > > I'll test it tomorrow
> >
> > Works on my nx6325 (good sign, the box is easy to break ;-)).
> >
> ===
> --- /dev/null
> +++ linux-2.6/arch/x86/kernel/acpi/realmode/wakeup.ld
> @@ -0,0 +1,51 @@
> +/*
> + * wakeup.ld
> + *
> + * Linker script for the real-mode wakeup code
> + */
> +OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i
On Thursday, 7 of February 2008, Rafael J. Wysocki wrote:
> On Wednesday, 6 of February 2008, Rafael J. Wysocki wrote:
> > On Tuesday, 5 of February 2008, Pavel Machek wrote:
> > >
> > > This rewrites wakeup code to .c, and it fixes stack (should use movl
> > > ,%esp, not movw). Testers wanted. Ma
On Wednesday, 6 of February 2008, Rafael J. Wysocki wrote:
> On Tuesday, 5 of February 2008, Pavel Machek wrote:
> >
> > This rewrites wakeup code to .c, and it fixes stack (should use movl
> > ,%esp, not movw). Testers wanted. Makefile infrastructure was done by
> > hpa, cleanups by rjw.
>
> I'l
On Tuesday, 5 of February 2008, Pavel Machek wrote:
>
> This rewrites wakeup code to .c, and it fixes stack (should use movl
> ,%esp, not movw). Testers wanted. Makefile infrastructure was done by
> hpa, cleanups by rjw.
>
> Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
>
[--snip--]
> diff --g
On Tue 2008-02-05 17:51:22, H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
>>> The asm() for making beeps really need to be moved to a function and
>>> cleaned up (redone in C using inb()/outb()) if they are to be retained at
>>> all.
>>
>> Yes, they are. For some people they're the only tool
On Wednesday, 6 of February 2008, H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
> >> The asm() for making beeps really need to be moved to a function and
> >> cleaned up (redone in C using inb()/outb()) if they are to be retained
> >> at all.
> >
> > Yes, they are. For some people they're th
Rafael J. Wysocki wrote:
The asm() for making beeps really need to be moved to a function and
cleaned up (redone in C using inb()/outb()) if they are to be retained
at all.
Yes, they are. For some people they're the only tool to debug broken resume.
That's fine, but they should get cleaned
On Wednesday, 6 of February 2008, H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
> > On Tuesday, 5 of February 2008, Pavel Machek wrote:
> >> This rewrites wakeup code to .c, and it fixes stack (should use movl
> >> ,%esp, not movw). Testers wanted. Makefile infrastructure was done by
> >> hpa, c
Rafael J. Wysocki wrote:
On Tuesday, 5 of February 2008, Pavel Machek wrote:
This rewrites wakeup code to .c, and it fixes stack (should use movl
,%esp, not movw). Testers wanted. Makefile infrastructure was done by
hpa, cleanups by rjw.
I'll test it tomorrow and I still have some more cleanup
On Tuesday, 5 of February 2008, Pavel Machek wrote:
>
> This rewrites wakeup code to .c, and it fixes stack (should use movl
> ,%esp, not movw). Testers wanted. Makefile infrastructure was done by
> hpa, cleanups by rjw.
I'll test it tomorrow and I still have some more cleanups (I was distracted
This rewrites wakeup code to .c, and it fixes stack (should use movl
,%esp, not movw). Testers wanted. Makefile infrastructure was done by
hpa, cleanups by rjw.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 8978e98..949b8eb 100644
--- a/
62 matches
Mail list logo
