RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

["Yu, Luming" <luming.yu@intel.com>]

>> 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