Xen project Mailing List

On 02/01/13 16:46, Ben Guthro wrote:

On Wed, Jan 2, 2013 at 10:31 AM, Ben Guthro <ben@xxxxxxxxxx> wrote:

The actual wakeup vector is wakeup_start in xen/arch/x86/boot/wakeup.S

I'll take a look at this, thanks for the pointer.

I've tried putting a "ud2" instruction at the start of wakeup_start - and the machine doesn't seem to crash.

I also tried a divide by zero in the same place, just for good measure.

It would appear that this wakeup_start is not getting executed on resume.

Presumably, the BIOS is causing the disk, and CDROM LEDs to flash, while enumerating the bus.

A difference between Xen 4.0.y and 4.2.y seems to be the removal of the boot trampoline fixed address, that much of this is calculated as an offset of.

Could an error in this path cause such a behavior?

It seems the trampoline is allocated at a different location in Xen 4.2 (EBDA - 64k instead of 0x7c000). I have attached a quick patch to move the location back to 0x7c000 to see if that helps your system. I have compile and boot tested the patch but not had time to do a S3 test on it. Can you try it on your system?

That patch hard codes it to 0x8c00, I think.

In any case, I tried this, as well as 0x7c00, but neither helped.

I also tried reverting the changeset that introduced this:

http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=46fce9fd2b3557c97e6ce9beec9ed17ad87d6f94

none of this seems to have an effect, that I can see.

I never seem to be reaching wakeup_start upon resume.

I've been trying to trace through the ACPI facs parsing, to see if the math is wrong somewhere...but so far, it all looks correct.

Can you also run the following command as root in dom0:

hexdump -s 0x400 -n 32 /dev/mem

hexdump -s 0x400 -n 32 /dev/mem

0000400 0000 0000 0000 0000 0000 0000 0000 9d80

0000410 0026 7600 0002 0000 0000 001e 001e 0000

0000420

/btg

Malcolm

Re: [Xen-devel] S3 resume issues