[ltp] Re: tp_smapi 0.29: found the cause for the crashes on a T42

[TNKS]

The latest for the T43:
    BIOS: 1YET64WW v1.28 (19 Jul 2006)
      EC: 1YHT29WW v1.06 (06 Jun 2006)

The latest for the T42:
    BIOS: 1RETDPWW v3.21 (12 Jun 2006)
      EC: 1RHT71WW v3.04 (15 Nov 2004)

So it seems that Lenovo released a EC upgrade for T43's but nothing for
T42's?  That really sucks.  I guess that's the beginning of the end of
Lenovo's support for my model.  

Unless you guy's feel this kind of issue can be brought to the forefront of
Lenovo's "give-a-hoot" list.  But I've never had luck getting corporations
to do much more than sell me something.

At least we can tailor TP-SMAPI to dance around the buggy EC if necessary.

- Sukant



Henrique de Moraes Holschuh wrote:

> Well, it is finally over.
> 
> Thanks to TNKS's help and a lot of debugging, we found out that function
> 0x0b was highly suspect.  Thanks to blind luck, I found out that was dead
> right:
> 
> While doing some cleanup on my thinkpad documentation folder a few hours
> ago, I happened to read the firmware changelog for the last firmware
> upgrade I had performed, and I found this entry in the file:
> 
>   Symptom corrected by version 1YHT28WW (1.05) - Removed from the stie
>   Note: This version of Embedded Controller Program will only work with
>   BIOS Version 1.25 or later.
> 
>     * (Fix) Fix for battery information query processing.
>     * (New) Support "ThinkPad NumLock" control.
> Note: "ThinkPad NumLock" menu item is available in the BIOS
> Setup Utility only when the BIOS is also updated to version
> 1YET60WW (1.25) or later.
> 
> Well, that was way too suspicious to just ignore.  I downgraded the T43 to
> EC 1.04, and now I could reproduce the problem just fine: the EC hung on
> me readly enough, while using a modified tp_smapi that just called
> function
> 0x0b and nothing else.  After going back to EC 1.06, it wouldn't hang
> anymore.
> 
> So, the fix is to blacklist function 0x0b for certain firmwares.  Since we
> don't even know what the data 0x0b returns is for, we can just blacklist
> it
> for every firmware, at least for now.  If anyone ever finds some use for
> 0x0b, we can revisit the issue.
>