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

[Sanjoy Mahajan]

  How about this. The side effect of this change is that _BIF, _BST could
  NOT work. But I think it's just ok.


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

It hangs in the usual way (2nd sleep).  The boot messages had two Fatal
opcodes, but that must be the _BIF and _BST that you mentioned:

  Execute Method: [\_TZ_.THM0._TMP] (Node e3f8bf88)
  ACPI: Fatal opcode executed
  Execute Method: [\_TZ_.THM0._PSV] (Node e3f8be48)
  Execute Method: [\_TZ_.THM0._TC1] (Node e3f8bdc8)
  Execute Method: [\_TZ_.THM0._TC2] (Node e3f8bd88)
  Execute Method: [\_TZ_.THM0._TSP] (Node e3f8bd48)
  Execute Method: [\_TZ_.THM0._AC0] (Node e3f8bf48)
  Execute Method: [\_TZ_.THM0._SCP] (Node e3f8bec8)
  Execute Method: [\_TZ_.THM0._TMP] (Node e3f8bf88)
  ACPI: Fatal opcode executed
  ACPI: Thermal Zone [THM0] (47 C)

With later modifications (e.g. commenting out one of the Store lines), I
could Return(0x00) instead of commenting out the line.  Let me know
which ones to try.  

One more thought.  We know that commenting out the UPDT call in _TMP
fixes the hang.  By bisecting the UPDT method, however, we change every
call to UPDT, including the one in THM0._TMP.  So we're making extra
changes beyond what is needed to fix the hang (and maybe producing
another hang?).

But let's continue this bisection since it's almost done.  If we
eventually find the offending statement, we can use the information in
order to find the smallest change that fixes the hang.  We make a copy
of the original UPDT method, call it UPDTCOPY, say; same for I2RB.  Then
THM0._TMP can call EC0.UPDTCOPY(), which calls I2RBCOPY.  And we modify
I2RBCOPY, but we leave I2RB and UPDT alone.

-Sanjoy

`A society of sheep must in time beget a government of wolves.'
   - Bertrand de Jouvenal
-
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/