Data block transactions fail on i2c-i801 controller?

Data block transactions fail on i2c-i801 controller?

[David Knierim]

Hi,
   I'm working with server based on Intel 7520 (Lindenhurst) chipset.   This uses the i2c-i801 bus driver.   An lm93 is attached to this bus.    If I load the lm93 in it's default mode, which "allows SMBus block data transactions if the host supports them", it takes a long time for sensors to run.   This is the output of "time":
real    0m10.901s
user    0m0.010s
sys     0m0.010s

If the lm93 is loaded with it's disable_block mode, which disables data block transactions, the operation is much faster:
real    0m1.261s
user    0m0.010s
sys     0m0.010s


In both cases, there are no errors logged to dmesg or /var/log/messages.   The output is correct in both cases.   The data block transaction mode just takes a lot longer to complete.


Any ideas??

David

Data block transactions fail on i2c-i801 controller?

[Mark M. Hoffman]

Oops, forgot to CC the list...

----- Forwarded message from "Mark M. Hoffman" <mhoffman@lightlink.com> -----

From: "Mark M. Hoffman" <mhoffman@lightlink.com>
To: David Knierim <david_knierim@earthlink.net>
Date: Mon, 20 Sep 2004 20:22:55 -0400
Subject: Re: Data block transactions fail on i2c-i801 controller?

Hi David:

* David Knierim <david_knierim@earthlink.net> [2004-09-20 16:40:33 -0400]:
> 
> Hi,
>    I'm working with server based on Intel 7520 (Lindenhurst) chipset.   This uses the i2c-i801 bus driver.   An lm93 is attached to this bus.    If I load the lm93 in it's default mode, which "allows SMBus block data transactions if the host supports them", it takes a long time for sensors to run.   This is the output of "time":
> real    0m10.901s
> user    0m0.010s
> sys     0m0.010s
> 
> If the lm93 is loaded with it's disable_block mode, which disables data block transactions, the operation is much faster:
> real    0m1.261s
> user    0m0.010s
> sys     0m0.010s
> 
> 
> In both cases, there are no errors logged to dmesg or /var/log/messages.   The output is correct in both cases.   The data block transaction mode just takes a lot longer to complete.
> 
> 
> Any ideas??

Please uncomment line 42 "#define DEBUG" and rebuild, reinstall,
and try again.  Now you should get some log messages... please
send those here; hopefully the original authors (Phil & MDS) can
have a look as well.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

Data block transactions fail on i2c-i801 controller?

[David Knierim]

The logs were pretty large, so we placed them on the web:

http://lee.k12.nc.us/~joden/misc/sensors/

dmesg_noblock - block data disabled
dmesg_withblock - block data enabled

David

-----Original Message-----
From: "Mark M. Hoffman" <mhoffman@lightlink.com>
Sent: Sep 20, 2004 5:22 PM
To: David Knierim <david_knierim@earthlink.net>
Subject: Re: Data block transactions fail on i2c-i801 controller?

Hi David:

* David Knierim <david_knierim@earthlink.net> [2004-09-20 16:40:33 -0400]:
> 
> Hi,
>    I'm working with server based on Intel 7520 (Lindenhurst) chipset.   This uses the i2c-i801 bus driver.   An lm93 is attached to this bus.    If I load the lm93 in it's default mode, which "allows SMBus block data transactions if the host supports them", it takes a long time for sensors to run.   This is the output of "time":
> real    0m10.901s
> user    0m0.010s
> sys     0m0.010s
> 
> If the lm93 is loaded with it's disable_block mode, which disables data block transactions, the operation is much faster:
> real    0m1.261s
> user    0m0.010s
> sys     0m0.010s
> 
> 
> In both cases, there are no errors logged to dmesg or /var/log/messages.   The output is correct in both cases.   The data block transaction mode just takes a lot longer to complete.
> 
> 
> Any ideas??

Please uncomment line 42 "#define DEBUG" and rebuild, reinstall,
and try again.  Now you should get some log messages... please
send those here; hopefully the original authors (Phil & MDS) can
have a look as well.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

Data block transactions fail on i2c-i801 controller?

[Mark Studebaker]

I did the i801 block code.
I'll take a look at it.
Give me about a week.
mds

Jean Delvare wrote:
> On Wed, 22 Sep 2004 18:16:11 -0400, Mark M. Hoffman wrote
> 
>>The i2c-i801 driver has *major* brain damage w.r.t. block xfers. 
>> What I *expected* to see in your logs was a timeout of some sort,
>>indicating that the bus was not resetting properly after a xfer.
>>
>>Not even close: the bus driver is actually performing a whole block xfer
>>once for each byte!!!  Seeing this, I wouldn't be suprised to find 
>>out that you are the very first user of that function, ever.  I am honestly
>>amazed that it works at all.
>>
>>So I understand what needs to be done, but actually fixing it is not
>>high on my list just now - especially since you have a workaround
>>(disable_block=1).
>>
>>One reason this will take some time is that this driver supports several
>>different chipsets.  Apparently some of them have a block xfer buffer
>>and some don't; I would have to read through ~5 chipset datasheets to
>>sort it out.  This is one reason I was hoping the original authors would
>>get involved.
> 
> 
> I am not the original author but a user of the i2c-i801 driver. My laptop has
> an ICH3-M chip on-board. It has a couple EEPROMs attached, with which I have
> been playing a lot at some time. It seemed to work well, and I think that the
> eeprom driver uses block transfer when available. I may do any kind of test on
> my chip, either with the current 2.4 and 2.6 drivers or with patches from you
> applied, you just have to ask.
> 
> Thanks.
> 

Data block transactions fail on i2c-i801 controller?

[Jean Delvare]

On Wed, 22 Sep 2004 18:16:11 -0400, Mark M. Hoffman wrote
> The i2c-i801 driver has *major* brain damage w.r.t. block xfers. 
>  What I *expected* to see in your logs was a timeout of some sort,
> indicating that the bus was not resetting properly after a xfer.
> 
> Not even close: the bus driver is actually performing a whole block xfer
> once for each byte!!!  Seeing this, I wouldn't be suprised to find 
> out that you are the very first user of that function, ever.  I am honestly
> amazed that it works at all.
> 
> So I understand what needs to be done, but actually fixing it is not
> high on my list just now - especially since you have a workaround
> (disable_block=1).
> 
> One reason this will take some time is that this driver supports several
> different chipsets.  Apparently some of them have a block xfer buffer
> and some don't; I would have to read through ~5 chipset datasheets to
> sort it out.  This is one reason I was hoping the original authors would
> get involved.

I am not the original author but a user of the i2c-i801 driver. My laptop has
an ICH3-M chip on-board. It has a couple EEPROMs attached, with which I have
been playing a lot at some time. It seemed to work well, and I think that the
eeprom driver uses block transfer when available. I may do any kind of test on
my chip, either with the current 2.4 and 2.6 drivers or with patches from you
applied, you just have to ask.

Thanks.

-- 
Jean Delvare
http://khali.linux-fr.org/

Data block transactions fail on i2c-i801 controller?

[Mark M. Hoffman]

Hello David:

* David Knierim <david_knierim@earthlink.net> [2004-09-21 07:58:37 -0700]:
> The logs were pretty large, so we placed them on the web:
> 
> http://lee.k12.nc.us/~joden/misc/sensors/

Thanks for doing that, and for saving some list B/W too.

> dmesg_noblock - block data disabled
> dmesg_withblock - block data enabled

The i2c-i801 driver has *major* brain damage w.r.t. block xfers.  What
I *expected* to see in your logs was a timeout of some sort, indicating
that the bus was not resetting properly after a xfer.

Not even close: the bus driver is actually performing a whole block xfer
once for each byte!!!  Seeing this, I wouldn't be suprised to find out
that you are the very first user of that function, ever.  I am honestly
amazed that it works at all.

So I understand what needs to be done, but actually fixing it is not
high on my list just now - especially since you have a workaround
(disable_block=1).

One reason this will take some time is that this driver supports several
different chipsets.  Apparently some of them have a block xfer buffer
and some don't; I would have to read through ~5 chipset datasheets to
sort it out.  This is one reason I was hoping the original authors would
get involved.

Hopefully, I'll have some time to work on this after I finish some other
stuff.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

Data block transactions fail on i2c-i801 controller?

[Jean Delvare]

> I did the i801 block code.
> I'll take a look at it.
> Give me about a week.

Mark, any news?

Thanks,
-- 
Jean Delvare
http://khali.linux-fr.org/

Data block transactions fail on i2c-i801 controller?

[Mark M. Hoffman]

Hi MDS, David:

* Mark D. Studebaker <mds4@verizon.net> [2004-12-07 10:14:54 -0500]:
> wow, a week turned into 2 1/2 months :)
> sorry for the delay.
> 
> There is no problem in the i801 block code.
> The bug is in the lm93 driver. 
> There is no check for success in lm93_read_block().
> Therefore every block transaction is called 5 times (MAX_RETRIES).
> What should have been 9 transactions turned into 45.
> Rather obvious from the logs (which are still at the link David posted - 
> thanks David).
> I'll fix lm93.

Yikes.

Yes it is obvious.  I'm eating my foot as I type this... or as my boss would
say, working on a case of athlete's tongue. :)  I'm sorry about that Mark -
thanks for fixing it.

David: please let us know how that works out when you get the chance.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

Data block transactions fail on i2c-i801 controller?

[Mark Studebaker]

wow, a week turned into 2 1/2 months :)
sorry for the delay.

There is no problem in the i801 block code.
The bug is in the lm93 driver. 
There is no check for success in lm93_read_block().
Therefore every block transaction is called 5 times (MAX_RETRIES).
What should have been 9 transactions turned into 45.
Rather obvious from the logs (which are still at the link David posted - thanks David).
I'll fix lm93.

mds

Jean Delvare wrote:
>>I did the i801 block code.
>>I'll take a look at it.
>>Give me about a week.
> 
> 
> Mark, any news?
> 
> Thanks,

Data block transactions fail on i2c-i801 controller?

[David Knierim]

Mark M. Hoffman wrote:
> Hi MDS, David:
> 
> * Mark D. Studebaker <mds4@verizon.net> [2004-12-07 10:14:54 -0500]:
> 
>>wow, a week turned into 2 1/2 months :)
>>sorry for the delay.
>>
>>There is no problem in the i801 block code.
>>The bug is in the lm93 driver. 
>>There is no check for success in lm93_read_block().
>>Therefore every block transaction is called 5 times (MAX_RETRIES).
>>What should have been 9 transactions turned into 45.
>>Rather obvious from the logs (which are still at the link David posted - 
>>thanks David).
>>I'll fix lm93.
> 
> 
> Yikes.
> 
> Yes it is obvious.  I'm eating my foot as I type this... or as my boss would
> say, working on a case of athlete's tongue. :)  I'm sorry about that Mark -
> thanks for fixing it.
> 
> David: please let us know how that works out when you get the chance.
> 
> Regards,
> 


I finally got a chance to look at this.   The transactions are now much 
faster.  Previously, when running the lm93 without block transfers:
# time sensors lm93-i2c-0-2e
real 0m1.343s
user 0m0.000s
sys  0m0.000s

Previously, running the same command with block transfers took almost 11 
seconds.

Now when run with block transfers:
# time sensors lm93-i2c-0-2e
real 0m0.508s
user 0m0.000s
sys  0m0.510s

I haven't had a chance to run it for an extended time to see if there 
are any reliability issues.

Thanks for fixing this!

David