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

From: Sanjoy Mahajan
Date: Wed Mar 22 2006 - 01:57:48 EST


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