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

[dagit@codersbase.com]

Pavel Machek <pavel@suse.cz> writes:

> Hi!
>
>> >> >> 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.
>
> Well, we set up stack few instructions before that. But we do it in
> quite a complicated way; could you just put stack at 0x00:0x200 or
> something like that? Also test if push alone is enough to kill it.

Could you send me the code you want me to test, I'd don't know enough
asm to move the stack.  I tried replacing the line with the comment
about the ASUS board private stack with a line like, "mov $0x200,
%sp", but I don't understand it.

As for check about the push alone causing the reboot, I removed the
pop, and it still reboots, but to me that doesn't say that it's the
push that does it.  It could be the next line.  I'll try to put in an
infinite loop.

Thanks,
Jason

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