Weirdness in arch/i386/kernel/acpi_wakeup.S

Weirdness in arch/i386/kernel/acpi_wakeup.S

[Bjorn Wesen]

Hi!

The acpi.c code in the same directory insists on wakeup_end - wakeup_start 
being less than a page big, but in the .S file, the org statements force 
them to be at least 3 pages apart :)  (2.5.59 with latest ACPI patches)

It seems to work anyway because the relevant _code_ is in the beginning and 
is thus copied into the low page anyway during S3 suspend, but there is a 
reference to a wakeup_stack and it all looks a bit funny, not to mention 
the big warning message "will crash upon attempt to suspend".. can anyone 
say how this code is supposed to work and I'll dive into it :)

(The problem I'm having is that the console VGA is not re-initialized upon 
coming back from an S3 suspend and I am trying to debug that)

/Björn



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Weirdness in arch/i386/kernel/acpi_wakeup.S

[Ducrot Bruno]

On Mon, Feb 10, 2003 at 01:43:54PM +0100, Bjorn Wesen wrote:
> Hi!
> 
> The acpi.c code in the same directory insists on wakeup_end - wakeup_start 
> being less than a page big, but in the .S file, the org statements force 
> them to be at least 3 pages apart :)  (2.5.59 with latest ACPI patches)

Simple.  You can have only one physical page allowed for the wakup code.
If you make something bigger, or point the stack outside, you will
get memory corruption.

I have send some time ago a patch to prevent that.  Don't know why
it is still not included.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Weirdness in arch/i386/kernel/acpi_wakeup.S

[Bjorn Wesen]

On Mon, 10 Feb 2003, Ducrot Bruno wrote:
> On Mon, Feb 10, 2003 at 01:43:54PM +0100, Bjorn Wesen wrote:
> > The acpi.c code in the same directory insists on wakeup_end - wakeup_start 
> > being less than a page big, but in the .S file, the org statements force 
> > them to be at least 3 pages apart :)  (2.5.59 with latest ACPI patches)
> 
> Simple.  You can have only one physical page allowed for the wakup code.
> If you make something bigger, or point the stack outside, you will
> get memory corruption.

That's what I figured, but since the code was so blatantly wrong in that 
case it seemed more probable that I had missed something :) In the 2.4 
series of the ACPI patches, the org's are at 300 and 400 instead of 2000 and 
3000 I think so that made more sense.

> I have send some time ago a patch to prevent that.  Don't know why
> it is still not included.

Maybe it's in the ACPI cvs. I only checked the .tgz release.

Do you know if the S3 resume code is supposed to work wrgds to video 
restoration ?

/Bjorn




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Weirdness in arch/i386/kernel/acpi_wakeup.S

[Pavel Machek]

Hi!

> The acpi.c code in the same directory insists on wakeup_end - wakeup_start 
> being less than a page big, but in the .S file, the org statements force 
> them to be at least 3 pages apart :)  (2.5.59 with latest ACPI patches)
> 
> It seems to work anyway because the relevant _code_ is in the beginning and 
> is thus copied into the low page anyway during S3 suspend, but there is a 
> reference to a wakeup_stack and it all looks a bit funny, not to mention 
> the big warning message "will crash upon attempt to suspend".. can anyone 
> say how this code is supposed to work and I'll dive into it :)

Well, it seems that code needs to get smaller...

> (The problem I'm having is that the console VGA is not re-initialized upon 
> coming back from an S3 suspend and I am trying to debug that)

Have you tried acpi_sleep=s3_bios and acpi_sleep=s3_mode (not yet in
2.5.59, but already in 2.5.59-acpi?)

								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Weirdness in arch/i386/kernel/acpi_wakeup.S

[Bjorn Wesen]

On Mon, 10 Feb 2003, Pavel Machek wrote:
> > (The problem I'm having is that the console VGA is not re-initialized upon 
> > coming back from an S3 suspend and I am trying to debug that)
> 
> Have you tried acpi_sleep=s3_bios and acpi_sleep=s3_mode (not yet in
> 2.5.59, but already in 2.5.59-acpi?)

(tried with 2.5.60 now including the 4096 byte wakeup .org fix, and btw this 
is on an Acer Travelmate 634LC laptop).

Without s3_bios and s3_mode, and without any drivers compiled into the 
kernel, the kernel wakes up after the suspend, and you can execute stuff 
using the keyboard but the VGA never resumes. Close call!

With s3_bios, the display lights up and the cursor starts blinking in the 
upper left corner, but it hangs there (no keyboard input possible). I guess 
the BIOS call succeeded in reinitializing the display but something after 
that hung.

With s3_mode, the display neither lights up nor allows keyboard input :)

Anyway, may I ask what debugging methods are best for tracking down problems 
like this on an i386. I'm used to doing kernel debugging on embedded systems 
but then you have access to logic analysers, LED-lighting etc.. what would 
be an appropriate way to debug such low level code on a PC - I noticed these 
references in acpi_wakeup.S like "movw	$0x0e00 + 'L', %fs:(0x10)" that seem 
to be some kind of debug messages - what do they really do - write to the 
VGA character memory ?

/Bjorn



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Weirdness in arch/i386/kernel/acpi_wakeup.S

[Pavel Machek]

Hi!

> > > (The problem I'm having is that the console VGA is not re-initialized upon 
> > > coming back from an S3 suspend and I am trying to debug that)
> > 
> > Have you tried acpi_sleep=s3_bios and acpi_sleep=s3_mode (not yet in
> > 2.5.59, but already in 2.5.59-acpi?)
> 
> (tried with 2.5.60 now including the 4096 byte wakeup .org fix, and btw this 
> is on an Acer Travelmate 634LC laptop).
> 
> Without s3_bios and s3_mode, and without any drivers compiled into the 
> kernel, the kernel wakes up after the suspend, and you can execute stuff 
> using the keyboard but the VGA never resumes. Close call!

Good.

> With s3_bios, the display lights up and the cursor starts blinking in the 
> upper left corner, but it hangs there (no keyboard input possible). I guess 
> the BIOS call succeeded in reinitializing the display but something after 
> that hung.
> 
> With s3_mode, the display neither lights up nor allows keyboard
> input :)

Do you use vgacon or vesafb or ...?

> Anyway, may I ask what debugging methods are best for tracking down problems 
> like this on an i386. I'm used to doing kernel debugging on embedded systems 
> but then you have access to logic analysers, LED-lighting etc.. what would 
> be an appropriate way to debug such low level code on a PC - I noticed these 
> references in acpi_wakeup.S like "movw	$0x0e00 + 'L', %fs:(0x10)" that seem 
> to be some kind of debug messages - what do they really do - write to the 
> VGA character memory ?

Yes, exactly. I'd suggest 8 leds on printer port as a debugging
trick... [VGA is easier -- when it works. Try moving 'L' just after
"call bios" to see if it ever returns etc.]

								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Weirdness in arch/i386/kernel/acpi_wakeup.S

[Ole Myren Rohne]

Pavel Machek <pavel-AlSwsSmVLrQ@public.gmane.org> writes:

> Yes, exactly. I'd suggest 8 leds on printer port as a debugging
> trick... [VGA is easier -- when it works. Try moving 'L' just after
> "call bios" to see if it ever returns etc.]

I've tried incrementing a byte in nvram, ie something like

        mov $14, %al
        outb %al, $0x70
        mov $1, %al
        outb %al, $0x71 

FWIW, it wasn't very successful on my Fujitsu P2120:

1. I don't know if playing with nvram is dangerous or just stupid...

2. I'm not sure which byte to use, it should be unused and outside
   checksummed areas. IUC, byte 14 is available and shows up as the
   first byte in /dev/nvram

3. Instead of hanging on resume, my machine now spontaneously rebooted
   (like jmp $0xffff,$0x0)

The third point left me with a question of what you can actually
expect of on a S3 resume. As I read the specs, only memory access is
guaranteed and the memory map can be either "boot" or "pre S3".

If access to the VGA fb is through some not-yet powered bridge,
perhaps the tracing could even cause the system to hang? Well,
that's enough speculation for now...

Ole

I append my /sbin/lspci hoping someone will look for suspicious
devices...

00:00.0 Host bridge: Transmeta Corporation LongRun Northbridge (rev 03)
00:00.1 RAM memory: Transmeta Corporation SDRAM controller
00:00.2 RAM memory: Transmeta Corporation BIOS scratchpad
00:02.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
00:04.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 01)
00:06.0 Bridge: ALi Corporation M7101 PMU
00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV]
00:09.0 USB Controller: NEC Corporation USB (rev 41)
00:09.1 USB Controller: NEC Corporation USB (rev 41)
00:09.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
00:0c.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01)
00:0f.0 IDE interface: ALi Corporation M5229 IDE (rev c3)
00:10.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:12.0 Network controller: Harris Semiconductor Prism 2.5 Wavelan chipset (rev 01)
00:13.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)
00:14.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com