Messages in this thread | | | Subject | RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT] | Date | Wed, 22 Mar 2006 12:58:36 +0800 | From | "Yu, Luming" <> |
| |
>> We can do bisection in EC0.UPDT to find out which statement cause >> hang? > >Yes, though see below for why I don't think it'll help no >matter what we >find there.
Please don't give up . :-)
I need to know which statement in EC0.UPDT that could trigger the problem. That is very important to understand the problem correctly. If we cannot find out that statement , then, I will dout the testing results that guiding us to here.
> >> My assumption is that since Windows works well, then these BIOS code >> should have been tested ok. The only possible excuse for BIOS is that >> Linux is using unnecessary/untested code path for >Suspend/resume. So, >> Eventually, we need to disable unnecessary BIOS call for >> suspend/resume > >Maybe we're not collecting the right data in that case. We know that >commenting out the call to UPDT in THM0.TMP fixes the hang. >But it does >not follow that the osl suspend code should avoid running UPDT.
This is still my assumption that some AML code needed to be avoided in suspend/resume, I need data support. So, we need to dig more in EC0.UPDT.
> >The hang may work like this: Between boot and sleep, calling >UPDT messes >up something in the ec [which is why it takes >1 sleep to >cause a hang]. >When the system tries to sleep, that something triggers and the ec >hangs. But it may hang somewhere else than UPDT, and avoiding UPDT >during sleep will not fix it.
If BIOS behaviors NOT correctly , then everything can happen.
> >However, we do have one more piece of data. When it hangs, it hangs in >\_SI._SST, because I see that line on successful sleeps (as the last
I don't know this. I always assume the hang is at _PTS.SMPI
>method before the beep) but not when it hangs (and then I also don't >hear a beep). There are lots of calls to EC0.XXX, including to >EC0.BEEP, within _SST, which isn't surprising if the EC is the problem.
It could be. But there should have something that trigger it.
>So perhaps I should bisect in _SST and put in the debug lines there? > >Here's another idea, which is a terrible hack. But there are lots of >lines in the DSDT like > If (LOr (SPS, WNTF)) >which I imagine is saying "If something or if WinNT". So, >what if Linux >pretends to be WinNT (or W98F -- which is another common >test), at least >for the 600x? Maybe those code paths are known to work. > Yes, you can try that.
Thanks, Luming - 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/
| |