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
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
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
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 push
it
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 more
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
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 still do
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
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
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.
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
>
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
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
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
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
+++
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 :-(.
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
> 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
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
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
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
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
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
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
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,
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
> > >
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.
> > >
>
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
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 :-(.
Great.
We
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 the beggining
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 problem there, but
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 manual patching
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
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
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,
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 acceptable
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.
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 data. I could not figure
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
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
+++
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 the rest 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 code
+ */
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's the
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
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 another method
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 inline
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
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 the record,
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,
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
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
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
On Friday, 8 of February 2008, Pavel Machek wrote:
> Hi!
Hi,
> > > > - memcpy((void *)acpi_wakeup_address, _start,
> > > > - _end - _start);
> > > > - acpi_copy_wakeup_routine(acpi_wakeup_address);
> > > > + memcpy((void *)acpi_realmode, _code_start, 4*PAGE_SIZE);
Hi!
> > > - memcpy((void *)acpi_wakeup_address, _start,
> > > -_end - _start);
> > > - acpi_copy_wakeup_routine(acpi_wakeup_address);
> > > + memcpy((void *)acpi_realmode, _code_start, 4*PAGE_SIZE);
> >
> > Using a PAGE_SIZE multiplier here isn't a good thing...
>
> Yes, I'll fix that
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
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
+++
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
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, 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
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,
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
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
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
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",
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.
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,
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);
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
+movq
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 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 separator is
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);
outb(0,
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 ;-)).
and I still have
===
--- /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-i386)
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,0 +1,122
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 4) {
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
+++
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
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
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...
Yes, I'll fix
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_code_start,
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 can get
pointers to my
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
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 to
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
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.
>
>
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
1 - 100 of 115 matches
Mail list logo
