[i2c] PIIX4 on Dell PowerEdge 1600SC

Jean Delvare khali at linux-fr.org
Mon Oct 8 21:00:46 CEST 2007


Hi Catalin,

On Thu, 4 Oct 2007 23:19:52 -0400, Catalin Patulea wrote:
> (...)
> eeprom also probes past that address, and 0x54, 0x55 and 0x57 also
> appear to be eeproms:
> # od -t x1 /sys/bus/i2c/drivers/eeprom/0-0054/eeprom
> 0000000 02 00 80 0e 16 25 32 38 70 74 7e 00 00 69 20 53
> 0000020 4c 36 45 4d 01 78 3c 9c 00 00 01 90 40 07 d0 05
> 0000040 dc 05 4d 46 07 00 00 02 00 00 00 00 00 00 00 00
> 0000060 00 fe 20 31 2e 30 00 51 38 30 35 33 32 4b 43 20
> 0000100 20 20 20 52 4e 38 47 46 55 41 56 41 45 00 40 f0
> 0000120 c2 c3 4f f5 43 00 00 00 00 00 00 00 00 00 00 00
> 0000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dd
> 0000160 42 00 00 be 3f eb fb ff 3e 00 00 00 00 9e 00 00
> 0000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *
> 0000400
> 
> # od -t x1 /sys/bus/i2c/drivers/eeprom/0-0055/eeprom
> 0000000 02 00 80 0e 16 25 32 38 70 74 7e 00 00 69 20 53
> 0000020 4c 35 5a 39 01 78 3c 90 00 00 01 90 40 07 d0 05
> 0000040 dc 05 4d 46 13 00 00 02 00 00 00 00 00 00 00 00
> 0000060 00 fe 20 31 2e 30 00 51 38 30 35 33 32 4b 43 20
> 0000100 20 20 20 52 4e 38 42 46 55 41 56 44 42 00 80 30
> 0000120 70 aa 00 8b 5a 00 00 00 00 00 00 00 00 00 00 00
> 0000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6f
> 0000160 42 00 00 be 3f eb fb ff 3e 00 00 00 00 9e 00 00
> 0000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *
> 0000400
> 
> [even though the above may look identical, they differ by a few bytes]
> 
> # od -t x1 /sys/bus/i2c/drivers/eeprom/0-0057/eeprom
> 0000000 01 0a 00 01 00 00 00 f4 01 09 00 00 00 00 83 64
> 0000020 c9 b2 de 50 57 41 2c 50 4c 4e 2c 32 50 5f 5a 45
> 0000040 c9 30 30 50 32 39 38 00 00 00 c0 c1 00 00 00 26
> 0000060 01 44 45 4c 4c ad 00 00 01 03 00 00 40 19 58 03
> 0000100 00 00 00 00 00 0a 04 01 fc 01 09 00 02 01 00 03
> 0000120 00 02 00 09 00 03 00 05 00 04 00 02 00 05 00 02
> 0000140 00 0f 00 04 00 10 00 05 00 14 00 04 00 15 00 05
> 0000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *
> 0000400
> 
> However, if I let the eeprom driver probe 0x56, my system locks up:
> # modprobe eeprom
> i2c-core: driver [eeprom] registered
> i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x50
> [similar output as above up to 0x55]
> i2c-adapter i2c-0: client [eeprom] registered with bus id 0-0055
> i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x56
> i2c-adapter i2c-0: Transaction (pre): CNT=00, CMD=80, ADD=ac, DAT0=00, DAT1=fc
> <system locks up>
> 
> I've also found that there's something at 0x30 through 0x33. i2cdetect
> shows these addresses as active, but i2cdump lists only 0xff's.
> 
> Just about every other address that I've tried probing locks up the system hard.

In other words, the SMBus locks up when it doesn't receive the expected
ack on the address byte. But not on Quick (write) command, otherwise
i2cdetect itself would have locked up the bus. Strange, I can't
remember anything similar.

> So, there's a few questions:
> 1) Why would probing a non-existent address lock up the system? Is
> there any way to prevent this?

No clue, sorry. If you find out, please let us know.

> 2) What EEPROMs could be at 0x54, 0x55 and 0x57? Does anyone recognize
> the contents?

I don't but there appears to be a number of bytes in the ASCII range.
Try "od -t c", maybe the revealed text will give you a hint. This could
be Dell proprietary data though, so odds are that you won't make much
sense out of it.

> 3) What could be at 0x30 through 0x33?

The "write protect" address of your EEPROMs at 0x50 through 0x53,
respectively. See:
http://www.lm-sensors.org/wiki/FAQ/Chapter3#WhatisatI2Caddresses0x30-0x37

-- 
Jean Delvare



More information about the i2c mailing list