>> 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-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
