Messages in this thread | | | From | dagit@codersba ... | Subject | Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)) | Date | Tue, 14 Jun 2005 15:18:06 -0700 |
| |
Pavel Machek <pavel@suse.cz> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |