RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming
Date: Tue Mar 21 2006 - 23:56:28 EST
>> We can do bisection in EC0.UPDT to find out which statement cause
>Yes, though see below for why I don't think it'll help no
>matter what we
Please don't give up . :-)
I need to know which statement in EC0.UPDT that could trigger the
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
>> Eventually, we need to disable unnecessary BIOS call for
>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
>The hang may work like this: Between boot and sleep, calling
>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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/