Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: Resume from Suspend to RAM))

[dagit-LP0vGzdgvNwj5TC/SZClsA@public.gmane.org]

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

> Hi!
>
>> >> > You got this wrong. It is three illegal instructions but
>> >> > *nested*. Like error, error in fault handler, error in doublefault
>> >> > handler.
>> >> 
>> >> Ah.  Yeah, this isn't an area I know much about :)  Thanks for the
>> >> correction. 
>> >> 
>> >> > Try replacing flags manipulation with any stack manipulation to see
>> >> > what is wrong.
>> >> 
>> >> Do you mean try something like this? Replace the push 0 with push
>> >> 0x1234 ; push 0x1234 ; pop ; pop and try to figure out which line
>> >> causes the reboot?
>> >
>> > Yep, try pushl $0, popl %eax; if that causes problems, something is
>> > seriously wrong with stack, otherwise changing flags hurts.
>> 
>> pushl $0, popl %eax gets the reboot.  So it's changing the flags that
>> is bad?
>> 
>> What should we try next?
>
> ??? You wanted it to reboot? If not, something is wrong with
> stack. Not sure whats next.

I don't want it to reboot, I guess I got confused.  As you say, maybe
something is wrong with the stack.  It's weird that something would be
wrong with the stack, because the other test to check the
suspend/resume code path works like a charm, the machine will do the
fake suspend/resume just fine.

So the bios must be messing up the stack right?  Is there a way to
examine or dump the stack so that we can compare the stack when
windows does the suspend/resume compared to when linux does it?

thanks,
Jason



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click