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.
Jordan -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
