Thanks for the responses everyone, inline, On 29 Jan 2014, at 10:25, Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > On Wed, Jan 29, 2014 at 05:42:24PM +0100, Jean Delvare wrote: >> Hi Alun, >> >> On Tue, 28 Jan 2014 20:57:00 -0800, Alun Evans wrote: >>> I’m trying to get some sense out of this: >>> >>> 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 05) >>> Subsystem: Super Micro Computer Inc Device 0661 >>> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- >>> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >>> Interrupt: pin C routed to IRQ 18 >>> Region 0: Memory at fba20000 (64-bit, non-prefetchable) [size=256] >>> Region 4: I/O ports at 1180 [size=32] >>> Kernel driver in use: i801_smbus >>> Kernel modules: i2c-i801 >>> >>> $ sudo i2cdetect -l >>> i2c-0 smbus SMBus I801 adapter at 1180 SMBus adapter >>> i2c-1 i2c igb BB I2C adapter >>> i2c-2 i2c igb BB I2C adapter >>> >>> The following doesn’t make sense to me: >>> >>> $ sudo i2cdetect 0 >>> WARNING! This program can confuse your I2C bus, cause data loss and worse! >>> I will probe file /dev/i2c-0. >>> I will probe address range 0x03-0x77. >>> Continue? [Y/n] Y >>> 0 1 2 3 4 5 6 7 8 9 a b c d e f >>> 00: -- -- -- -- -- 08 -- -- -- -- -- -- -- >>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- 2d -- -- >>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >>> 40: -- -- -- -- 44 -- -- -- 48 -- -- -- -- -- -- -- >>> 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >>> 60: -- -- -- -- -- -- -- -- 68 69 -- -- 6c -- -- -- >>> 70: -- -- -- -- -- -- -- -- >>> >>> Since I have two RDIMMs on this board: >>> >>> $ sudo ./ipmicfg-linux.x86_64 -nm cpumemtemp >>> CPU#0 = 35(c) >>> [CPU#0]CHANNEL#2, DIMM#0(P1_DIMMC1) = 24(c) >>> [CPU#0]CHANNEL#2, DIMM#1(P1_DIMMC2) = 24(c) >>> >>> And snooping the bus on boot up with a total phase Aardvark, I see that the DIMMs are on addr 0x50, and 0x51, and if I dump 0x50, I just see 256 bytes of 0xff, rather than the SPD eeprom data that I was expecting. >> >> This is a big board with many DDR3 slots. Heh, this is a 8-DIMM board. We’ve just ordered a 24-DIMM board, with an eye to a 48-DIMM board. >> It is possible that >> Supermicro put them being an I2C multiplexer. That would explain why >> you don't "see" them, the multiplexer must enable the right branch >> before you can see the SPD EEPROMs. >> > Agreed, especially since the SPD on 0x51 does not show up at all. > >> Please ask Supermicro about it. I have put a request in… We’ll see if I get a response. >> If the memory slots are behind an I2C >> multiplexer, ask them if the multiplexer is I2C-based or GPIO-based. If >> I2C-based, ask for the multiplexer type and address. If GPIO-based, ask >> for the chip name and pin numbers for the GPIOs. In both case, please >> ask which GPIO combinations map to which memory slots. >> > I would suspect it is GPIO; the i2c muxes are typically at address 0x7x > which is empty in above i2cdetect log. The DSDT might give a hint if we > are really lucky. Not that I am any good in decoding DSDTs, though ;-). I followed : https://01.org/linux-acpi/utilities And there is this hunk: OperationRegion (GPIO, SystemIO, GPBS, 0x20) Field (GPIO, DWordAcc, NoLock, Preserve) { Offset (0x0C), GLVL, 32, Offset (0x18), GBLK, 32 } A. -- Alun Evans
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
