[ltp] Re: Re: EC Hanging with latest tp-smapi (0.29)

[Henrique de Moraes Holschuh]

On Tue, 29 Aug 2006, TNKS wrote:
> big difference between 0ms and 10ms.  I'm feeling like there /is/ something
> special about 0x0b. Well, I /know/ something is special about it, because I
> do get warnings when I do the dump:

Well, if you change the loop to ONLY call 0x0b and nothing else, does it
hang?  Or if you invert the loop, so that it starts with 0x0b and walks its
way to 0x00 ?

0x0a is also suspect.  Inverting the loop will test 0x0a.

> thinkpad_ec: thinkpad_ec_read_data: 0x161F reports error: (0x0b:0x00)->0x80.  
> 
> They fill up my dmesg.  One for every EC access.

Please send me a full dmesg output of the thinkpad_ec errors on private
mail, I will try to track down exactly where they happen in the thinkpad_ec
state machine, and that might give me a new clue, if we're lucky.

> Unfortunately, although the problem seems /slightly/ diminished, it still
> hangs every time with a delay of 10ms before every EC read.  It takes a few
> seconds longer with this delay.  It's not a instantaneous as it was before.

I bet if we profiled the EC calls we would know, but _that_ ain't a trivial
thing to ask you to do.

> I didn't play around with widening the delay farther beyond 10ms.  I'm

It wouldn't help.  If 10ms is not enough for the EC, nothing will be.  10ms is
enough for the EC to run more than 15000 instructions.

> reading EC data.  I'd feel more comfortable if we could just avoid the read
> on systems that don't seem to support it.

My worries are HDAPS.  HDAPS requires one EC call per sample, plus other
calls here and there for book-keeping, and it uses exactly the same EC call
system that tp_smapi uses.  If anything in hdaps hangs the EC, we cannot
simply "not call it, then" like we can for tp_smapi.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh