Re: [Suspend-devel] [rft] Kill junk from s2ram resume paths

2007-08-16 Thread Pavel Machek
Hi! > > > > > > # Running in *copy* of this code, somewhere in low 1MB. > > > > > > > > > > > > - movb$0xa1, %al ; outb %al, $0x80 > > > > > > > > > > Well, what was this for? > > > > > > > > Debugging leds on port 80. I still have that card somewhere > > > > :-). Interesting part

Re: [Suspend-devel] [rft] Kill junk from s2ram resume paths

2007-08-15 Thread Rafael J. Wysocki
On Tuesday, 31 July 2007 16:01, Pavel Machek wrote: > Hi! > > > > > > # Running in *copy* of this code, somewhere in low 1MB. > > > > > > > > > > - movb$0xa1, %al ; outb %al, $0x80 > > > > > > > > Well, what was this for? > > > > > > Debugging leds on port 80. I still have that

Re: [Suspend-devel] [rft] Kill junk from s2ram resume paths

2007-08-01 Thread Stefan Seyfried
On Tue, Jul 31, 2007 at 04:43:34PM +0200, Stefan Seyfried wrote: > On Tue, Jul 31, 2007 at 04:01:40PM +0200, Pavel Machek wrote: > > Hi! > > > > > > > > # Running in *copy* of this code, somewhere in low 1MB. > > > > > > > > > > > > - movb$0xa1, %al ; outb %al, $0x80 > > > > > > >

Re: [Suspend-devel] [rft] Kill junk from s2ram resume paths

2007-07-31 Thread Pavel Machek
Hi! > > > diff --git a/arch/i386/kernel/acpi/wakeup.S > > > b/arch/i386/kernel/acpi/wakeup.S > > > index 1415da1..9cebef7 100644 > > > --- a/arch/i386/kernel/acpi/wakeup.S > > > +++ b/arch/i386/kernel/acpi/wakeup.S > > > @@ -28,21 +28,6 @@ #define BEEP \ > > > movb$15, %al; \ > > >

Re: [Suspend-devel] [rft] Kill junk from s2ram resume paths

2007-07-31 Thread Rafael J. Wysocki
On Tuesday, 31 July 2007 16:43, Stefan Seyfried wrote: > On Tue, Jul 31, 2007 at 04:01:40PM +0200, Pavel Machek wrote: > > Hi! > > > > > > > > # Running in *copy* of this code, somewhere in low 1MB. > > > > > > > > > > > > - movb$0xa1, %al ; outb %al, $0x80 > > > > > > > > > > Well

Re: [Suspend-devel] [rft] Kill junk from s2ram resume paths

2007-07-31 Thread Stefan Seyfried
On Tue, Jul 31, 2007 at 04:01:40PM +0200, Pavel Machek wrote: > Hi! > > > > > > # Running in *copy* of this code, somewhere in low 1MB. > > > > > > > > > > - movb$0xa1, %al ; outb %al, $0x80 > > > > > > > > Well, what was this for? > > > > > > Debugging leds on port 80. I still

Re: [Suspend-devel] [rft] Kill junk from s2ram resume paths

2007-07-31 Thread Pavel Machek
Hi! > > > > # Running in *copy* of this code, somewhere in low 1MB. > > > > > > > > - movb$0xa1, %al ; outb %al, $0x80 > > > > > > Well, what was this for? > > > > Debugging leds on port 80. I still have that card somewhere > > :-). Interesting parties can reinsert it. > > Ah

Re: [Suspend-devel] [rft] Kill junk from s2ram resume paths

2007-07-31 Thread Rafael J. Wysocki
Hi, On Tuesday, 31 July 2007 15:18, Pavel Machek wrote: > Hi! > > > > This removes some stale debugging infrastructure from s2ram > > > paths. Also, there's no need to verify_cpu on x86-64 -- cpu can't > > > change during s2ram, and removed #if 0-ed code. Some testing would be > > > useful, perpa

Re: [Suspend-devel] [rft] Kill junk from s2ram resume paths

2007-07-31 Thread Pavel Machek
Hi! > > This removes some stale debugging infrastructure from s2ram > > paths. Also, there's no need to verify_cpu on x86-64 -- cpu can't > > change during s2ram, and removed #if 0-ed code. Some testing would be > > useful, perpahs it will even fix someone's machine :-). (VGA accesses > > could th

Re: [Suspend-devel] [rft] Kill junk from s2ram resume paths

2007-07-31 Thread Rafael J. Wysocki
Hi, On Tuesday, 31 July 2007 14:12, Pavel Machek wrote: > Hi! > > This removes some stale debugging infrastructure from s2ram > paths. Also, there's no need to verify_cpu on x86-64 -- cpu can't > change during s2ram, and removed #if 0-ed code. Some testing would be > useful, perpahs it will even

[Suspend-devel] [rft] Kill junk from s2ram resume paths

2007-07-31 Thread Pavel Machek
Hi! This removes some stale debugging infrastructure from s2ram paths. Also, there's no need to verify_cpu on x86-64 -- cpu can't change during s2ram, and removed #if 0-ed code. Some testing would be useful, perpahs it will even fix someone's machine :-). (VGA accesses could theoretically hurt if