[coreboot] ACPI S3

Jordan Crouse jordan at cosmicpenguin.net
Wed Nov 26 17:03:26 CET 2008

Feng, Libo wrote:
> Hi, all,
> Thank you, Mr. Peter Stuge, The D bit is the key point. With other
> tricks, the system stepped into the 64bit operating mode, however,
> was lost at the line 224 of wakeup.S, as the below link.
> http://lxr.linux.no/linux+v2.6.18/arch/x86_64/kernel/acpi/wakeup.S
> 222        movw    $0x0e00 + '!', %ds:(0xb801a) 223        movq
> saved_eip, %rax 224        jmp     *%rax
> I think saved_eip is stored prior to sleeping, so, now, I don't know
> where the system jumps into, which is totally random, depending on
> the system state just before sleeping. Now some traces can be sent
> out via serial port, I can't say it is resuming, for the system seems
> not fully working. Now I think resuming the system in the function of
> post_cache_as_ram is not a good idea. Few devices are initialized at
> this point. Rudolf's method is more practicable. I will try it later.
> Thank everyone again.

saved_eip should absolutely not be random - it is saved while the system 
is going down (in save_registers).  You should confirm with HDT that the 
value in saved_eip is somewhat sane (i.e - pointing to somewhere else in 
the kernel code space).

What other indications do you have that the system was "lost"?  Remember 
that you won't get back the video state due to silly behavior on the 
part of the ATI GPU - but you should be seeing kernel activity on your 
serial port, assuming that you have the kernel console enabled on your 
serial port.

Also, any reason why you are using kernel version 2.6.18 sources?  IIRC, 
the images you are using had a newer version of the kernel.

I recommend that you step as far as you can with HDT through the resume 
process until you confirm that the system has re-entered the C functions.


More information about the coreboot mailing list