Problem with eeprom module in 2.9.0

Problem with eeprom module in 2.9.0

[David Knierim]

As you can see, I've been doing a lot of testing of sensors lately...

I have a number of servers that have been running the CVS version of i2c 
and lm_sensors downloaded on October 25, 2004, plus the patch to add 
DDR2 support.   This release of sensors has performed well.

I'm now trying to upgrade the version of sensors on these servers to 
2.9.1 for i2c and 2.9.0 plus the bmcsensors.c patch.   The servers are 
running Red Hat 9 (2.4.20-31.9.0bigmem with a few patches to add 
additional hardware support).  This same version of kernel is used for 
both versions of lm_sensors and for both versions of server that I will 
be discussing.

The lm87 and lm93 drivers are working OK, but the eeprom driver in 2.9.0 
really does not like our newest servers. On the failing servers (Dual 
XEON 3.2 Ghz, E7520 chipset, DDR2 memory), sensors stops providing 
useful information as soon as the eeprom driver is loaded.

I loaded the appropriate drivers:
i2c-core i2c-dev i2c-proc i2c-i801 eeprom

Running sensors gives bogus output:
# sensors
eeprom-i2c-0-53
Adapter: SMBus I801 adapter at 0540
Unknown EEPROM type (255).

eeprom-i2c-0-57
Adapter: SMBus I801 adapter at 0540
Unknown EEPROM type (255).

Running this command logs the following message to dmesg:
PCI device 8086:25a4 (Intel Corp.): Reset failed! (21)
eeprom.o: block read fail at 0x00!

Removing modules using rmmod runs without error, but
when the eeprom module is reloaded, it does not find any i2c devices.

I then rebooted the server to get the i2c bus working again (which worked).

I have 2.9.0 on a different server family (Dual XEON 2.4 Ghz, E7501 
chipset, DDR memory) and the eeprom driver works fine.

I then decided to see what would happen if I loaded the lm87, the lm93 
and the eeprom driver on the failing server.

The first time I ran sensors after loading the drivers (fan errors are 
expected):
# sensors

Adapter: SMBus I801 adapter at 0540
mon0,+V1_8:
            +1.80 V  (min =  +1.72 V, max =  +1.88 V)
mon0,+V3_3:
            +3.27 V  (min =  +3.16 V, max =  +3.44 V)
mon0,+V5_pci:
            +5.00 V  (min =  +4.74 V, max =  +5.26 V)
mon0,+V12:+12.06 V  (min = +11.38 V, max = +12.63 V)
mon0,Fan_C1:
              0 RPM  (min = 1394 RPM, div = 8)          ALARM
mon0,Fan_C2:
              0 RPM  (min = 1394 RPM, div = 8)          ALARM
mon0,AmbT:   +26C  (low  =    +0C, high =   +60C)
mon0,amb_cpu0_temp:
              +30C  (low  =    +0C, high =   +60C)
mon0,amb_ddr_temp:
              +36C  (low  =    +0C, high =   +65C)

lm93-i2c-0-2e
Adapter: SMBus I801 adapter at 0540
mon1,+V1.5:
            +1.49 V  (min =  +1.42 V, max =  +1.57 V)
mon1,VCC_CPU0:
            +1.36 V  (min =  +0.00 V, max =  +1.60 V)
mon1,VCC_CPU1:
            +1.36 V  (min =  +0.00 V, max =  +1.60 V)
mon1,battv_mon:
            +3.12 V  (min =  +2.00 V, max =  +3.30 V)
mon1,+V5_0:
            +5.09 V  (min =  +4.75 V, max =  +5.25 V)
mon1,VTT:  +1.20 V  (min =  +1.13 V, max =  +1.26 V)
mon1,+V3_3:
            +3.29 V  (min =  +3.14 V, max =  +3.46 V)
mon1,Fan_A1:
              0 RPM  (min = 1398 RPM)                       ALARM
mon1,Fan_A2:
              0 RPM  (min = 1398 RPM)                       ALARM
mon1,Fan_B1:
              0 RPM  (min = 1398 RPM)                       ALARM
mon1,Fan_B2:
              0 RPM  (min = 1398 RPM)                       ALARM
mon1,cpu0:   +29C  (low  =    +0C, high =   +80C)
mon1,cpu1:   +34C  (low  =    +0C, high =   +80C)
mon1,AmbT:   +32C  (low  =    +0C, high =   +65C)
mon1,CPU0_VID:
           +1.387 V
mon1,CPU1_VID:
           +1.387 V

eeprom-i2c-0-53
Adapter: SMBus I801 adapter at 0540
Unknown EEPROM type (255).

eeprom-i2c-0-57
Adapter: SMBus I801 adapter at 0540
Unknown EEPROM type (255).

I then reran sensors:
# sensors
lm87-i2c-0-2d
Adapter: SMBus I801 adapter at 0540
mon0,+V1_8:
            +0.00 V  (min =  +0.00 V, max =  +0.00 V)
mon0,+V3_3:
            +0.00 V  (min =  +0.00 V, max =  +0.00 V)
mon0,+V5_pci:
            +0.00 V  (min =  +0.00 V, max =  +0.00 V)
mon0,+V12: +0.00 V  (min =  +0.00 V, max =  +0.00 V)
mon0,Fan_C1:
             -1 RPM  (min =   -1 RPM, div = 1)
mon0,Fan_C2:
             -1 RPM  (min =   -1 RPM, div = 1)
mon0,AmbT:    +0C  (low  =    +0C, high =    +0C)
mon0,amb_cpu0_temp:
               +0C  (low  =    +0C, high =    +0C)
mon0,amb_ddr_temp:
               +0C  (low  =    +0C, high =    +0C)

lm93-i2c-0-2e
Adapter: SMBus I801 adapter at 0540
mon1,+V1.5:
            +1.49 V  (min =  +1.42 V, max =  +1.57 V)
mon1,VCC_CPU0:
            +1.36 V  (min =  +0.00 V, max =  +1.60 V)
mon1,VCC_CPU1:
            +1.36 V  (min =  +0.00 V, max =  +1.60 V)
mon1,battv_mon:
            +3.12 V  (min =  +2.00 V, max =  +3.30 V)
mon1,+V5_0:
            +5.09 V  (min =  +4.75 V, max =  +5.25 V)
mon1,VTT:  +1.20 V  (min =  +1.13 V, max =  +1.26 V)
mon1,+V3_3:
            +3.29 V  (min =  +3.14 V, max =  +3.46 V)
mon1,Fan_A1:
              0 RPM  (min = 1398 RPM)                       ALARM
mon1,Fan_A2:
              0 RPM  (min = 1398 RPM)                       ALARM
mon1,Fan_B1:
              0 RPM  (min = 1398 RPM)                       ALARM
mon1,Fan_B2:
              0 RPM  (min = 1398 RPM)                       ALARM
mon1,cpu0:   +29C  (low  =    +0C, high =    +0C)
mon1,cpu1:   +34C  (low  =    +0C, high =    +0C)
mon1,AmbT:   +32C  (low  =    +0C, high =    +0C)
mon1,CPU0_VID:
           +1.087 V
mon1,CPU1_VID:
           +1.087 V

eeprom-i2c-0-53
Adapter: SMBus I801 adapter at 0540
Unknown EEPROM type (255).

eeprom-i2c-0-57
Adapter: SMBus I801 adapter at 0540
Unknown EEPROM type (255).

At this point /var/log/messages is filled with errors such as this:
Jan  6 11:49:04 gateway653 kernel: lm87.o: All read byte retries failed!!
Jan  6 11:49:04 gateway653 kernel: lm87.o: Read byte data failed, 
address 0x42
Jan  6 11:49:04 gateway653 last message repeated 4 times
Jan  6 11:49:04 gateway653 kernel: lm87.o: All read byte retries failed!!
Jan  6 11:49:04 gateway653 kernel: lm87.o: Read byte data failed, 
address 0x19
Jan  6 11:49:04 gateway653 last message repeated 4 times
Jan  6 11:49:04 gateway653 kernel: lm87.o: All read byte retries failed!!
Jan  6 11:49:04 gateway653 kernel: PCI device 8086:25a4 (Intel Corp.): 
Reset failed! (21)
Jan  6 11:49:04 gateway653 kernel: lm93.o: block read data failed, 
command 0xf5.
Jan  6 11:49:04 gateway653 kernel: PCI device 8086:25a4 (Intel Corp.): 
Reset failed! (21)
Jan  6 11:49:04 gateway653 kernel: lm93.o: block read data failed, 
command 0xf5.
Jan  6 11:49:04 gateway653 kernel: PCI device 8086:25a4 (Intel Corp.): 
Reset failed! (21)
Jan  6 11:49:04 gateway653 kernel: lm93.o: block read data failed, 
command 0xf5

Thanks for any help or guidance you can provide.

David

Problem with eeprom module in 2.9.0

[Jean Delvare]

Hi David,

> As you can see, I've been doing a lot of testing of sensors lately...

I wouldn't complain, since you find real bugs and send real patches :)
You're our best tester.

> I have a number of servers that have been running the CVS version of
> i2c  and lm_sensors downloaded on October 25, 2004, plus the patch to
> add  DDR2 support.   This release of sensors has performed well.
> 
> I'm now trying to upgrade the version of sensors on these servers to 
> 2.9.1 for i2c and 2.9.0 plus the bmcsensors.c patch.   The servers are
> running Red Hat 9 (2.4.20-31.9.0bigmem with a few patches to add 
> additional hardware support).  This same version of kernel is used for
> both versions of lm_sensors and for both versions of server that I
> will  be discussing.

Note that this is really i2c 2.9.0, not 2.9.1.

> The lm87 and lm93 drivers are working OK, but the eeprom driver in
> 2.9.0  really does not like our newest servers. On the failing servers
> (Dual  XEON 3.2 Ghz, E7520 chipset, DDR2 memory), sensors stops
> providing  useful information as soon as the eeprom driver is loaded.
> 
> I loaded the appropriate drivers:
> i2c-core i2c-dev i2c-proc i2c-i801 eeprom
> 
> Running sensors gives bogus output:
> # sensors
> eeprom-i2c-0-53
> Adapter: SMBus I801 adapter at 0540
> Unknown EEPROM type (255).
> 
> eeprom-i2c-0-57
> Adapter: SMBus I801 adapter at 0540
> Unknown EEPROM type (255).
> 
> Running this command logs the following message to dmesg:
> PCI device 8086:25a4 (Intel Corp.): Reset failed! (21)
> eeprom.o: block read fail at 0x00!

255 is really -1, aka read error. At the moment you see this, your SMBus
is already locked.

> Removing modules using rmmod runs without error, but
> when the eeprom module is reloaded, it does not find any i2c devices.

Because the bus is locked.

OK, the big change here is most probably the support (or attempt
thereof) of I2C block read in i2c-i801. As far as I know you are the
first tester of this feature. The eeprom driver does make use of this
feature when possible, and it doesn't seem to work as intended for you.

What I find strange is that the lm93 driver does make use of the block
transfers too, and they seem to work for you (until the eeprom driver
trashes the whole bus). This suggests that the bug isn't in the i2c-i801
driver but it the eeprom driver, or maybe the eeprom and lm93 driver do
not use i2c block reads in the same way.

> I have 2.9.0 on a different server family (Dual XEON 2.4 Ghz, E7501 
> chipset, DDR memory) and the eeprom driver works fine.

What's the PCI ID of this one? Maybe block transfers work OK for the
E7501 but not for the E7520.

Can you please try the attached patch? It disables block reads in the
eeprom driver. If it solves the problem for you then we at least know
what is triggering the bug (although I still can't get why lm93 doesn't
trigger it).

Thanks,
-- 
Jean Delvare
http://khali.linux-fr.org/
-------------- next part --------------
Index: kernel/chips/eeprom.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/chips/eeprom.c,v
retrieving revision 1.57
diff -u -r1.57 eeprom.c
--- kernel/chips/eeprom.c	29 Dec 2004 10:43:57 -0000	1.57
+++ kernel/chips/eeprom.c	6 Jan 2005 22:16:55 -0000
@@ -303,8 +303,7 @@
 		printk(KERN_DEBUG "eeprom.o: Starting update, slice %u\n", slice);
 #endif
 
-		if (i2c_check_functionality(client->adapter,
-		                            I2C_FUNC_SMBUS_READ_I2C_BLOCK))
+		if (0)
 		{
 			for (i = slice << 5; i < (slice + 1) << 5;
 			                            i += I2C_SMBUS_I2C_BLOCK_MAX)

Problem with eeprom module in 2.9.0

[Mark M. Hoffman]

Hi:

* Jean Delvare <khali@linux-fr.org> [2005-01-06 23:12:16 +0100]:
> OK, the big change here is most probably the support (or attempt
> thereof) of I2C block read in i2c-i801. As far as I know you are the
> first tester of this feature. The eeprom driver does make use of this
> feature when possible, and it doesn't seem to work as intended for you.
> 
> What I find strange is that the lm93 driver does make use of the block
> transfers too, and they seem to work for you (until the eeprom driver
> trashes the whole bus). This suggests that the bug isn't in the i2c-i801
> driver but it the eeprom driver, or maybe the eeprom and lm93 driver do
> not use i2c block reads in the same way.

MDS just added the I2C variant of the block transfer.  But lm93 uses the
SMBus variant... so it is possible that it's a problem in i2c-i801.

Of course last time I said something like that, there was egg all over
my face... :)

> What's the PCI ID of this one? Maybe block transfers work OK for the
> E7501 but not for the E7520.
> 
> Can you please try the attached patch? It disables block reads in the
> eeprom driver. If it solves the problem for you then we at least know
> what is triggering the bug (although I still can't get why lm93 doesn't
> trigger it).

See above.  But the eeprom patch you gave is still a useful test.

I really should get a 2.4 kernel / distro back on my ICH5 machine so I
can see what's going on there.  I'm short on time this week and will
be traveling next week... so it may have to wait a while.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

Problem with eeprom module in 2.9.0

[Mark Studebaker]

good diagnosis khali.
the 6300ESB definitely supports i2c block so there must be a bug in there somewhere.
I just reviewed the code and didn't see anything obvious.
David can you recompile i2c-i801 with the DEBUG=1 uncommented and
send us the dmesg output?

Jean Delvare wrote:
> Hi David,
> 
> 
>>>What's the PCI ID of this one? Maybe block transfers work OK for the
>>>E7501 but not for the E7520.
>>
>>The SMBus controller on the E7501 is 8086:2483 (rev 02).
>>The SMBus controller on the E7520 is 8086:25a4 (rev 02).
> 
> 
> OK, mystery explained then. 2483 is an ICH3, for which the I2C block
> transfers are not available at all - so MDS' changes did not affect
> this one. 25a4 is an 6300ESB, which is more recent and supposedly
> supports I2C block transfers, thus is affected by the change.
> 
> 
>>>(although I still can't get why lm93 doesn't trigger it).
> 
> 
> As noted by Mark Hoffman, the lm93 driver uses SMBus block transfers, not
> I2C block transfers. Second mystery explained. SMBus block transfers
> were implemented longer ago and seem to work.
> 
> So the conclusion is that the (untested as of now) I2C block transfer
> recently added to the i2c-i801 driver by Mark Studebaker doesn't work
> for you, and most presumably doesn't work at all. I will leave it to
> Mark to propose a fix or debug tests to further analyze the problem.
> 
> Thanks,
> --
> Jean Delvare
> 
> 

Problem with eeprom module in 2.9.0

[Mark M. Hoffman]

Hi everyone:

* Mark D. Studebaker <mds4@verizon.net> [2005-01-22 11:54:37 -0500]:
> good diagnosis khali.
> the 6300ESB definitely supports i2c block so there must be a bug in there 
> somewhere.
> I just reviewed the code and didn't see anything obvious.
> David can you recompile i2c-i801 with the DEBUG=1 uncommented and
> send us the dmesg output?

I may have found it.  There is a note on page 240 of the ICH5 datasheet
that says:

	For I2C Read command, the value written into bit 0 of the
	Transmit Slave Address Register (SMB I/O register, offset
	04h) needs to be 0.

We're writing a 1 (as would be expected: it's a read after all).  I'll
test this hypothesis tomorrow evening... right now I need sleep.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

Problem with eeprom module in 2.9.0

[Mark M. Hoffman]

Hi again:

> * Mark D. Studebaker <mds4@verizon.net> [2005-01-22 11:54:37 -0500]:
> > good diagnosis khali.
> > the 6300ESB definitely supports i2c block so there must be a bug in there 
> > somewhere.
> > I just reviewed the code and didn't see anything obvious.
> > David can you recompile i2c-i801 with the DEBUG=1 uncommented and
> > send us the dmesg output?

* Mark M. Hoffman <mhoffman@lightlink.com> [2005-01-25 00:01:45 -0500]:
> I may have found it.  There is a note on page 240 of the ICH5 datasheet
> that says:
> 
> 	For I2C Read command, the value written into bit 0 of the
> 	Transmit Slave Address Register (SMB I/O register, offset
> 	04h) needs to be 0.
> 
> We're writing a 1 (as would be expected: it's a read after all).  I'll
> test this hypothesis tomorrow evening... right now I need sleep.

Before I made the change above, my 'scope wasn't even triggering when
I tried to do an I2C block read.  After making that change, at least I
had something to look at...

Next, I found that the "command" field for I2C block read must be
written into SMBHSTDAT1 instead of SMBHSTCMD.  After making that change,
the picture on the 'scope is correct, but...

The driver still complains "bus timeout".  Now, I guess that the host
block data byte register is in "block buffer" mode for the I2C block read
command, regardless of the value of E32B.  That's the only thing I can
think of that explains why it never gets a "byte done status" in the
host status reg.  As it stands, the block transfer loop looks for "byte
done" but ignores "intr", and again that would explain what I'm seeing
on the 'scope and in the kernel logs.

Here's my patch so far.  There's some noise because I tried to make a
better xfer-killer (though it didn't seem to help any).  The important
changes are in the last chunk.  I probably won't get to play with this
again before the weekend.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

Index: kernel/busses/i2c-i801.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/busses/i2c-i801.c,v
retrieving revision 1.44
diff -u -r1.44 i2c-i801.c
--- kernel/busses/i2c-i801.c	22 Jan 2005 11:02:40 -0000	1.44
+++ kernel/busses/i2c-i801.c	26 Jan 2005 06:26:15 -0000
@@ -41,7 +41,7 @@
 
 /* Note: we assume there can only be one I801, with one SMBus interface */
 
-/* #define DEBUG 1 */
+#define DEBUG 1
 
 #include <linux/module.h>
 #include <linux/pci.h>
@@ -217,6 +217,37 @@
 	return error_return;
 }
 
+/* This function kills any transaction in progress
+ * status is the most recently read SMBHSTSTS - useful for debug
+ * messages but doesn't affect the outcome of this function
+ * returns 0 if the abort was successful, -1 otherwise */
+static int i801_abort(int status)
+{
+	int timeout = 0;
+
+	dev_dbg(I801_dev, "SMBus busy (%02x). Resetting... \n", status);
+
+	/* set kill bit */
+	outb_p(0x02, SMBHSTCNT);
+
+	/* wait for fail status */
+	do {
+		i2c_delay(1);
+		status = inb_p(SMBHSTSTS);
+	} while (((status & 0x10) = 0) && (timeout++ < MAX_TIMEOUT));
+
+	if (timeout >= MAX_TIMEOUT) {
+		dev_dbg(I801_dev, "Host bus timeout while attempting to "
+			"abort!  You might need to power-cycle the whole "
+			"machine to fix this.\n");
+		return -1;
+	}
+
+	/* clear control and status regs */
+	outb_p(0x00, SMBHSTCNT);
+	outb_p(0xbe, SMBHSTSTS);
+	return 0;
+}
 
 static int i801_transaction(void)
 {
@@ -224,24 +255,16 @@
 	int result = 0;
 	int timeout = 0;
 
-	dev_dbg(I801_dev, "Transaction (pre): CNT=%02x, CMD=%02x,"
+	dev_dbg(I801_dev, "Transaction (pre): CNT=%02x, CMD=%02x, "
 		"ADD=%02x, DAT0=%02x, DAT1=%02x\n", inb_p(SMBHSTCNT),
 		inb_p(SMBHSTCMD), inb_p(SMBHSTADD), inb_p(SMBHSTDAT0),
 		inb_p(SMBHSTDAT1));
 
 	/* Make sure the SMBus host is ready to start transmitting */
 	/* 0x1f = Failed, Bus_Err, Dev_Err, Intr, Host_Busy */
-	if ((temp = (0x1f & inb_p(SMBHSTSTS))) != 0x00) {
-		dev_dbg(I801_dev, "SMBus busy (%02x). Resetting... \n",
-			temp);
-		outb_p(temp, SMBHSTSTS);
-		if ((temp = (0x1f & inb_p(SMBHSTSTS))) != 0x00) {
-			dev_dbg(I801_dev, "Failed! (%02x)\n", temp);
+	if ((temp = (0x1f & inb_p(SMBHSTSTS))) != 0x00)
+		if (i801_abort(temp) = -1)
 			return -1;
-		} else {
-			dev_dbg(I801_dev, "Successfull!\n");
-		}
-	}
 
 	outb_p(inb(SMBHSTCNT) | I801_START, SMBHSTCNT);
 
@@ -355,15 +378,11 @@
 			errmask=0x1e; 
 		}
 		if (temp & errmask) {
-			dev_dbg(I801_dev, "SMBus busy (%02x). "
-				"Resetting... \n", temp);
-			outb_p(temp, SMBHSTSTS);
-			if (((temp = inb_p(SMBHSTSTS)) & errmask) != 0x00) {
-				dev_err(I801_dev,
-					"Reset failed! (%02x)\n", temp);
+			if (i801_abort(temp) = -1) {
 				result = -1;
-                                goto END;
+				goto END;
 			}
+
 			if (i != 1) {
 				/* if die in middle of block transaction, fail */
 				result = -1;
@@ -515,9 +534,25 @@
 		if(hwpec && size = I2C_SMBUS_BLOCK_DATA)
 			size = I2C_SMBUS_BLOCK_DATA_PEC;
 #endif
-		outb_p(((addr & 0x7f) << 1) | (read_write & 0x01),
-		       SMBHSTADD);
-		outb_p(command, SMBHSTCMD);
+		if (size = I2C_SMBUS_I2C_BLOCK_DATA) {
+			/* NB: page 240 of ICH5 datasheet shows that the R/#W
+			 * bit should be cleared here, even when reading */
+			outb_p( ((addr & 0x7f) << 1), SMBHSTADD);
+
+			if (read_write)
+				/* NB: page 240 of ICH5 datasheet also shows
+				 * that DATA1 is the cmd field when reading */
+				outb_p(command, SMBHSTDAT1);
+			else
+				outb_p(command, SMBHSTCMD);
+				
+		} else {
+			outb_p(((addr & 0x7f) << 1) | (read_write & 0x01),
+				SMBHSTADD);
+
+			outb_p(command, SMBHSTCMD);
+		}
+
 		block = 1;
 		break;
 	case I2C_SMBUS_PROC_CALL:

Problem with eeprom module in 2.9.0

[Mark Studebaker]

thanks for working on this
(amazing what you can accomplish with two scope probes, huh?)
you're right about the bit0 and the DAT1 changes.

Is the done bit set for all but the last byte,
or does it never set it?
If it's all but the last one, I don't think it's in E32B mode...
maybe just a quirk of i2c read.
Also may depend on whether slave stops the transfer or the
host reads a full 32 bytes...


Mark M. Hoffman wrote:
> Hi again:
> 
> 
>>* Mark D. Studebaker <mds4@verizon.net> [2005-01-22 11:54:37 -0500]:
>>
>>>good diagnosis khali.
>>>the 6300ESB definitely supports i2c block so there must be a bug in there 
>>>somewhere.
>>>I just reviewed the code and didn't see anything obvious.
>>>David can you recompile i2c-i801 with the DEBUG=1 uncommented and
>>>send us the dmesg output?
> 
> 
> * Mark M. Hoffman <mhoffman@lightlink.com> [2005-01-25 00:01:45 -0500]:
> 
>>I may have found it.  There is a note on page 240 of the ICH5 datasheet
>>that says:
>>
>>	For I2C Read command, the value written into bit 0 of the
>>	Transmit Slave Address Register (SMB I/O register, offset
>>	04h) needs to be 0.
>>
>>We're writing a 1 (as would be expected: it's a read after all).  I'll
>>test this hypothesis tomorrow evening... right now I need sleep.
> 
> 
> Before I made the change above, my 'scope wasn't even triggering when
> I tried to do an I2C block read.  After making that change, at least I
> had something to look at...
> 
> Next, I found that the "command" field for I2C block read must be
> written into SMBHSTDAT1 instead of SMBHSTCMD.  After making that change,
> the picture on the 'scope is correct, but...
> 
> The driver still complains "bus timeout".  Now, I guess that the host
> block data byte register is in "block buffer" mode for the I2C block read
> command, regardless of the value of E32B.  That's the only thing I can
> think of that explains why it never gets a "byte done status" in the
> host status reg.  As it stands, the block transfer loop looks for "byte
> done" but ignores "intr", and again that would explain what I'm seeing
> on the 'scope and in the kernel logs.
> 
> Here's my patch so far.  There's some noise because I tried to make a
> better xfer-killer (though it didn't seem to help any).  The important
> changes are in the last chunk.  I probably won't get to play with this
> again before the weekend.
> 
> Regards,
> 

Problem with eeprom module in 2.9.0

[Mark M. Hoffman]

Hi Mark:

* Mark D. Studebaker <mds4@verizon.net> [2005-01-29 14:13:18 -0500]:
> thanks for working on this
> (amazing what you can accomplish with two scope probes, huh?)

Yes, thanks again btw.

> you're right about the bit0 and the DAT1 changes.
> 
> Is the done bit set for all but the last byte,
> or does it never set it?

It is never set, so the driver never bothers to complete the xfer.
(I guess I wasn't clear about that in what I wrote below).

> If it's all but the last one, I don't think it's in E32B mode...
> maybe just a quirk of i2c read.
> Also may depend on whether slave stops the transfer or the
> host reads a full 32 bytes...

Unfortunately, the slave chip spams on forever: remember that i2c block
read is not limited to 32 bytes like smbus block read is.  So the bus
is locked up until reset *sigh*.  And btw: I have no idea why the abort
routine I wrote in that patch can't kill it.

> Mark M. Hoffman wrote:
> >Hi again:
> >
> >
> >>* Mark D. Studebaker <mds4@verizon.net> [2005-01-22 11:54:37 -0500]:
> >>
> >>>good diagnosis khali.
> >>>the 6300ESB definitely supports i2c block so there must be a bug in 
> >>>there somewhere.
> >>>I just reviewed the code and didn't see anything obvious.
> >>>David can you recompile i2c-i801 with the DEBUG=1 uncommented and
> >>>send us the dmesg output?
> >
> >
> >* Mark M. Hoffman <mhoffman@lightlink.com> [2005-01-25 00:01:45 -0500]:
> >
> >>I may have found it.  There is a note on page 240 of the ICH5 datasheet
> >>that says:
> >>
> >>	For I2C Read command, the value written into bit 0 of the
> >>	Transmit Slave Address Register (SMB I/O register, offset
> >>	04h) needs to be 0.
> >>
> >>We're writing a 1 (as would be expected: it's a read after all).  I'll
> >>test this hypothesis tomorrow evening... right now I need sleep.
> >
> >
> >Before I made the change above, my 'scope wasn't even triggering when
> >I tried to do an I2C block read.  After making that change, at least I
> >had something to look at...
> >
> >Next, I found that the "command" field for I2C block read must be
> >written into SMBHSTDAT1 instead of SMBHSTCMD.  After making that change,
> >the picture on the 'scope is correct, but...
> >
> >The driver still complains "bus timeout".  Now, I guess that the host
> >block data byte register is in "block buffer" mode for the I2C block read
> >command, regardless of the value of E32B.  That's the only thing I can
> >think of that explains why it never gets a "byte done status" in the
> >host status reg.  As it stands, the block transfer loop looks for "byte
> >done" but ignores "intr", and again that would explain what I'm seeing
> >on the 'scope and in the kernel logs.
> >
> >Here's my patch so far.  There's some noise because I tried to make a
> >better xfer-killer (though it didn't seem to help any).  The important
> >changes are in the last chunk.  I probably won't get to play with this
> >again before the weekend.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com