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

[dagit]

Pavel Machek <pavel@xxxxxxx> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/