On Wed, Dec 4, 2013 at 10:05 AM, Laszlo Ersek <ler...@redhat.com> wrote: > And, now I have some idea why it happens. I hacked PlatformPei and > S3Resume2Pei to read the CS and log it. (Of course without seeing the > actual GDT entries that these values point to we can't say much, but we > can't say something.)
You could use AsmReadGdtr to dump the GDT in a debug message. Or, possibly add a CpuDeadLoop call, and look at the GDT with the QEMU monitor. > I also added a small count-down loop in gcc inline > assembly that uses LRETQ for the iteration -- I load CS to RAX, push > RAX, compute the RIP in RAX and push that too, then LRETQ. > > In PlatformPei, after cold boot *or* resume, Cs=0x18, and the loop with > LRETQ works. > > In S3Resume2Pei, after resume, Cs=0x0418, and the loop with LRETQ still > works (IOW whatever GDT we use, it has a good entry for the 0x0418 > selector). But, there's this section in S3ResumeExecuteBootScript(): This seems suspicious. I don't think either the firmware or OS will define a selector higher than ~0x40. Are you sure the processor CS has 0x0418? Or is it possible this is just a corruption of the CS on the stack waiting for the lret instruction to load it? Maybe you could add CpuDeadLoop just before the call that causes the reset, and look at 'info registers' in the QEMU monitor. -Jordan ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
