2006-03-22 01:35:05

by Luming Yu

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

>
>Hmm, you seems to prefer depth-first search algorithm?
>I like it too. :-)
>
>
>>
>>One bug is quite repeatable and we know a lot about it. With all zones
>>except THM0 commented out, the system hung. With the EC0.UPDT line in
>>THM0._TMP also commented out, the system didn't hang. So there's a
>>problem related to the EC, even with only THM0. And finding that
>>problem may giveideas for what else may be wrong.
>
>We can do bisection in EC0.UPDT to find out which statement cause hang?
>Hmm, we are going to fix BIOS. :-)

You can insert debug statements in EC0.UPDT to help debug:

Store (IGNR, Debug)
Store (" before relase I2CM", Debug)
Store (HBS7, TMP7)
....

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


2006-03-22 07:00:34

by Sanjoy Mahajan

[permalink] [raw]
Subject: Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

I tried the following kernels (all with only THM0):

1. No other changes: It hangs, as before and as expected.

2. Commented out a large chunk of the UPDT() method:

diff -r ac2b38909dfa -r c431c477d3b6 dsdt/600x.dsl
--- a/dsdt/600x.dsl Tue Mar 21 17:12:47 2006 -0500
+++ b/dsdt/600x.dsl Wed Mar 22 00:22:21 2006 -0500
@@ -4132,19 +4132,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 1,
If (Acquire (I2CM, 0x0064)) {}
Else
{
- Store (I2RB (Zero, 0x01, 0x04), Local7)
- If (Local7)
- {
- Fatal (0x01, 0x80000003, Local7)
- }
- Else
- {
- Store (HBS0, TMP0)
- Store (HBS2, TMP2)
- Store (HBS6, TMP6)
- Store (HBS7, TMP7)
- }
-
Release (I2CM)
}
}

So now it just grabs and releases the I2CM lock.

This kernel hung on the first sleep, but I couldn't reproduce that
behavior. I tried two more boots, and each time it never hung. I even
thought it might depend on the result of previous boots, so I tried
kernel #1 again and got the same hang, and then tried #2. But it still
wouldn't hang. So I went back through the serial console logs to check
whether I was hallucinating, and I was not. This kernel had indeed hung
on the first sleep, but only the first time I booted it.

So I'm going to assume that it's okay, and that if it isn't okay, it's
because of another, more intermitten bug.

3. Commented out EC0.UPDT() call in THM0._THM, and this kernel was fine,
which is how it behaved a couple days ago, and is what I expected.

I'm about to try a smaller change (continuing the bisect):

diff -r ac2b38909dfa -r f10a309b8385 dsdt/600x.dsl
--- a/dsdt/600x.dsl Tue Mar 21 17:12:47 2006 -0500
+++ b/dsdt/600x.dsl Wed Mar 22 01:44:12 2006 -0500
@@ -4137,13 +4137,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 1,
{
Fatal (0x01, 0x80000003, Local7)
}
- Else
- {
- Store (HBS0, TMP0)
- Store (HBS2, TMP2)
- Store (HBS6, TMP6)
- Store (HBS7, TMP7)
- }

Release (I2CM)
}


After that bisection there's not much more to change in UPDT().
However, I can drill down into I2RB() because of this line in UPDT():

Store (I2RB (Zero, 0x01, 0x04), Local7)

But I have no idea what's safe to experiment with in I2RB():

Method (I2RB, 3, NotSerialized)
{
Store (Arg0, HCSL)
Store (ShiftLeft (Arg1, 0x01), HMAD)
Store (Arg2, HMCM)
Store (0x0B, HMPR)
Return (CHKS ())
}


All those lines look like tricky hardware manipulations.

By the way, which debug_{level,layer} settings will show the lines of
the human-readable DSDT as they are executed?

-Sanjoy