[lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Alun Evans]

[-- Attachment #1.1: Type: text/plain, Size: 2213 bytes --]

Hello,

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.

I’ve been hacking away at the kernel module, but I’ve not been able to really make any progress. Looking for any pointers.


thanks,

A.

-- 
Alun Evans

[-- Attachment #1.2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Jean Delvare]

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. 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.

Please ask Supermicro about it. 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've done that before for the Asus Z8 series, so if you can get all the
technical details from Supermicro, I should be able to add support for
your board to the i2c-i801 drivers.

-- 
Jean Delvare
http://jdelvare.nerim.net/wishlist.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Guenter Roeck]

T24gV2VkLCBKYW4gMjksIDIwMTQgYXQgMDU6NDI6MjRQTSArMDEwMCwgSmVhbiBEZWx2YXJlIHdy
b3RlOgo+IEhpIEFsdW4sCj4gCj4gT24gVHVlLCAyOCBKYW4gMjAxNCAyMDo1NzowMCAtMDgwMCwg
QWx1biBFdmFucyB3cm90ZToKPiA+IEnigJltIHRyeWluZyB0byBnZXQgc29tZSBzZW5zZSBvdXQg
b2YgdGhpczoKPiA+IAo+ID4gMDA6MWYuMyBTTUJ1czogSW50ZWwgQ29ycG9yYXRpb24gQzYwMC9Y
Nzkgc2VyaWVzIGNoaXBzZXQgU01CdXMgSG9zdCBDb250cm9sbGVyIChyZXYgMDUpCj4gPiAgICAg
ICAgIFN1YnN5c3RlbTogU3VwZXIgTWljcm8gQ29tcHV0ZXIgSW5jIERldmljZSAwNjYxCj4gPiAg
ICAgICAgIENvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0g
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCj4gPiAg
ICAgICAgIFN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1t
ZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQo+ID4g
ICAgICAgICBJbnRlcnJ1cHQ6IHBpbiBDIHJvdXRlZCB0byBJUlEgMTgKPiA+ICAgICAgICAgUmVn
aW9uIDA6IE1lbW9yeSBhdCBmYmEyMDAwMCAoNjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6
ZT0yNTZdCj4gPiAgICAgICAgIFJlZ2lvbiA0OiBJL08gcG9ydHMgYXQgMTE4MCBbc2l6ZT0zMl0K
PiA+ICAgICAgICAgS2VybmVsIGRyaXZlciBpbiB1c2U6IGk4MDFfc21idXMKPiA+ICAgICAgICAg
S2VybmVsIG1vZHVsZXM6IGkyYy1pODAxCj4gPiAKPiA+ICQgc3VkbyBpMmNkZXRlY3QgLWwKPiA+
IGkyYy0wICAgc21idXMgICAgICAgICAgIFNNQnVzIEk4MDEgYWRhcHRlciBhdCAxMTgwICAgICAg
ICAgICAgICBTTUJ1cyBhZGFwdGVyCj4gPiBpMmMtMSAgIGkyYyAgICAgICAgICAgICBpZ2IgQkIg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSTJDIGFkYXB0ZXIKPiA+IGkyYy0yICAg
aTJjICAgICAgICAgICAgIGlnYiBCQiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJ
MkMgYWRhcHRlcgo+ID4gCj4gPiBUaGUgZm9sbG93aW5nIGRvZXNu4oCZdCBtYWtlIHNlbnNlIHRv
IG1lOgo+ID4gCj4gPiAkIHN1ZG8gaTJjZGV0ZWN0IDAKPiA+IFdBUk5JTkchIFRoaXMgcHJvZ3Jh
bSBjYW4gY29uZnVzZSB5b3VyIEkyQyBidXMsIGNhdXNlIGRhdGEgbG9zcyBhbmQgd29yc2UhCj4g
PiBJIHdpbGwgcHJvYmUgZmlsZSAvZGV2L2kyYy0wLgo+ID4gSSB3aWxsIHByb2JlIGFkZHJlc3Mg
cmFuZ2UgMHgwMy0weDc3Lgo+ID4gQ29udGludWU/IFtZL25dIFkKPiA+ICAgICAgMCAgMSAgMiAg
MyAgNCAgNSAgNiAgNyAgOCAgOSAgYSAgYiAgYyAgZCAgZSAgZgo+ID4gMDA6ICAgICAgICAgIC0t
IC0tIC0tIC0tIC0tIDA4IC0tIC0tIC0tIC0tIC0tIC0tIC0tIAo+ID4gMTA6IC0tIC0tIC0tIC0t
IC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIAo+ID4gMjA6IC0tIC0tIC0tIC0t
IC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIDJkIC0tIC0tIAo+ID4gMzA6IC0tIC0tIC0tIC0t
IC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIAo+ID4gNDA6IC0tIC0tIC0tIC0t
IDQ0IC0tIC0tIC0tIDQ4IC0tIC0tIC0tIC0tIC0tIC0tIC0tIAo+ID4gNTA6IDUwIC0tIC0tIC0t
IC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tIAo+ID4gNjA6IC0tIC0tIC0tIC0t
IC0tIC0tIC0tIC0tIDY4IDY5IC0tIC0tIDZjIC0tIC0tIC0tIAo+ID4gNzA6IC0tIC0tIC0tIC0t
IC0tIC0tIC0tIC0tICAgICAgICAgICAgICAgICAgICAgICAgIAo+ID4gCj4gPiBTaW5jZSBJIGhh
dmUgdHdvIFJESU1NcyBvbiB0aGlzIGJvYXJkOgo+ID4gCj4gPiAkIHN1ZG8gLi9pcG1pY2ZnLWxp
bnV4Lng4Nl82NCAtbm0gY3B1bWVtdGVtcAo+ID4gQ1BVIzAgPSAzNShjKQo+ID4gW0NQVSMwXUNI
QU5ORUwjMiwgRElNTSMwKFAxX0RJTU1DMSkgPSAyNChjKQo+ID4gW0NQVSMwXUNIQU5ORUwjMiwg
RElNTSMxKFAxX0RJTU1DMikgPSAyNChjKQo+ID4gCj4gPiBBbmQgc25vb3BpbmcgdGhlIGJ1cyBv
biBib290IHVwIHdpdGggYSB0b3RhbCBwaGFzZSBBYXJkdmFyaywgSSBzZWUgdGhhdCB0aGUgRElN
TXMgYXJlIG9uIGFkZHIgMHg1MCwgYW5kIDB4NTEsIGFuZCBpZiBJIGR1bXAgMHg1MCwgSSBqdXN0
IHNlZSAyNTYgYnl0ZXMgb2YgMHhmZiwgcmF0aGVyIHRoYW4gdGhlIFNQRCBlZXByb20gZGF0YSB0
aGF0IEkgd2FzIGV4cGVjdGluZy4KPiAKPiBUaGlzIGlzIGEgYmlnIGJvYXJkIHdpdGggbWFueSBE
RFIzIHNsb3RzLiBJdCBpcyBwb3NzaWJsZSB0aGF0Cj4gU3VwZXJtaWNybyBwdXQgdGhlbSBiZWlu
ZyBhbiBJMkMgbXVsdGlwbGV4ZXIuIFRoYXQgd291bGQgZXhwbGFpbiB3aHkKPiB5b3UgZG9uJ3Qg
InNlZSIgdGhlbSwgdGhlIG11bHRpcGxleGVyIG11c3QgZW5hYmxlIHRoZSByaWdodCBicmFuY2gK
PiBiZWZvcmUgeW91IGNhbiBzZWUgdGhlIFNQRCBFRVBST01zLgo+IApBZ3JlZWQsIGVzcGVjaWFs
bHkgc2luY2UgdGhlIFNQRCBvbiAweDUxIGRvZXMgbm90IHNob3cgdXAgYXQgYWxsLgoKPiBQbGVh
c2UgYXNrIFN1cGVybWljcm8gYWJvdXQgaXQuIElmIHRoZSBtZW1vcnkgc2xvdHMgYXJlIGJlaGlu
ZCBhbiBJMkMKPiBtdWx0aXBsZXhlciwgYXNrIHRoZW0gaWYgdGhlIG11bHRpcGxleGVyIGlzIEky
Qy1iYXNlZCBvciBHUElPLWJhc2VkLiBJZgo+IEkyQy1iYXNlZCwgYXNrIGZvciB0aGUgbXVsdGlw
bGV4ZXIgdHlwZSBhbmQgYWRkcmVzcy4gSWYgR1BJTy1iYXNlZCwgYXNrCj4gZm9yIHRoZSBjaGlw
IG5hbWUgYW5kIHBpbiBudW1iZXJzIGZvciB0aGUgR1BJT3MuIEluIGJvdGggY2FzZSwgcGxlYXNl
Cj4gYXNrIHdoaWNoIEdQSU8gY29tYmluYXRpb25zIG1hcCB0byB3aGljaCBtZW1vcnkgc2xvdHMu
Cj4gCkkgd291bGQgc3VzcGVjdCBpdCBpcyBHUElPOyB0aGUgaTJjIG11eGVzIGFyZSB0eXBpY2Fs
bHkgYXQgYWRkcmVzcyAweDd4CndoaWNoIGlzIGVtcHR5IGluIGFib3ZlIGkyY2RldGVjdCBsb2cu
IFRoZSBEU0RUIG1pZ2h0IGdpdmUgYSBoaW50IGlmIHdlCmFyZSByZWFsbHkgbHVja3kuIE5vdCB0
aGF0IEkgYW0gYW55IGdvb2QgaW4gZGVjb2RpbmcgRFNEVHMsIHRob3VnaCA7LSkuCgpHdWVudGVy
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5z
b3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5s
bS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Alun Evans]

[-- Attachment #1.1: Type: text/plain, Size: 3863 bytes --]

Thanks for the responses everyone, inline,

On 29 Jan 2014, at 10:25, Guenter Roeck <linux@roeck-us.net> 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 #1.2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Jean Delvare]

On Wed, 29 Jan 2014 11:48:47 -0800, Alun Evans wrote:
> >> 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.

Right, 8 DIMMs would normally not require multiplexing. But vendors
like to reuse designs and your 8-DIMM board is probably a "small"
version of something bigger. My Asus Z8NA-D6 has only 6 DIMMs but it
has an I2C multiplexer anyway.

> > (...)
> > 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
>     }

And can you tell us what GPBS is?

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Alun Evans]

[-- Attachment #1.1: Type: text/plain, Size: 1404 bytes --]


On 29 Jan 2014, at 11:55, Jean Delvare <khali@linux-fr.org> wrote:

> On Wed, 29 Jan 2014 11:48:47 -0800, Alun Evans wrote:
>>>> 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.
> 
> Right, 8 DIMMs would normally not require multiplexing. But vendors
> like to reuse designs and your 8-DIMM board is probably a "small"
> version of something bigger. My Asus Z8NA-D6 has only 6 DIMMs but it
> has an I2C multiplexer anyway.

Ah, that is likely with an SM board certainly.

> 
>>> (...)
>>> 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
>>    }
> 
> And can you tell us what GPBS is?
> 

Looks like it’s GPIOBASE.

I’ve never looked at ACPI/DSDT, so I’ve not clue what I’m doing here.

I could send the entire del file, but I don’t want to trouble anyone unnecessarily.

A.

-- 
Alun Evans

[-- Attachment #1.2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Alun Evans]

[-- Attachment #1.1: Type: text/plain, Size: 1161 bytes --]


On 29 Jan 2014, at 11:48, Alun Evans <alun@badgerous.net> wrote:

> Thanks for the responses everyone, inline,
> 
> On 29 Jan 2014, at 10:25, Guenter Roeck <linux@roeck-us.net> wrote:
> 
>> On Wed, Jan 29, 2014 at 05:42:24PM +0100, Jean Delvare wrote:
>>> Hi Alun,
>>> <snip>
>> 
>>> 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 inlined the above hunk with my question, and the first response was:

> Received feedback; The memory address does not use mux.  It is hardware defined by Intel.

So I went and clarified I was not talking about the DDR physical address setup by the memory reference code, and I got:

> Per our engineer; There is no hardware connecting to DIMM.

I’m not sure I’ve found the right help here...


A.

-- 
Alun Evans

[-- Attachment #1.2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Guenter Roeck]

T24gV2VkLCBKYW4gMjksIDIwMTQgYXQgMDU6MTI6NDhQTSAtMDgwMCwgQWx1biBFdmFucyB3cm90
ZToKPiAKPiBPbiAyOSBKYW4gMjAxNCwgYXQgMTE6NDgsIEFsdW4gRXZhbnMgPGFsdW5AYmFkZ2Vy
b3VzLm5ldD4gd3JvdGU6Cj4gCj4gPiBUaGFua3MgZm9yIHRoZSByZXNwb25zZXMgZXZlcnlvbmUs
IGlubGluZSwKPiA+IAo+ID4gT24gMjkgSmFuIDIwMTQsIGF0IDEwOjI1LCBHdWVudGVyIFJvZWNr
IDxsaW51eEByb2Vjay11cy5uZXQ+IHdyb3RlOgo+ID4gCj4gPj4gT24gV2VkLCBKYW4gMjksIDIw
MTQgYXQgMDU6NDI6MjRQTSArMDEwMCwgSmVhbiBEZWx2YXJlIHdyb3RlOgo+ID4+PiBIaSBBbHVu
LAo+ID4+PiA8c25pcD4KPiA+PiAKPiA+Pj4gUGxlYXNlIGFzayBTdXBlcm1pY3JvIGFib3V0IGl0
Lgo+ID4gCj4gPiBJIGhhdmUgcHV0IGEgcmVxdWVzdCBpbuKApiBXZeKAmWxsIHNlZSBpZiBJIGdl
dCBhIHJlc3BvbnNlLgo+ID4gCj4gPj4+IElmIHRoZSBtZW1vcnkgc2xvdHMgYXJlIGJlaGluZCBh
biBJMkMKPiA+Pj4gbXVsdGlwbGV4ZXIsIGFzayB0aGVtIGlmIHRoZSBtdWx0aXBsZXhlciBpcyBJ
MkMtYmFzZWQgb3IgR1BJTy1iYXNlZC4gSWYKPiA+Pj4gSTJDLWJhc2VkLCBhc2sgZm9yIHRoZSBt
dWx0aXBsZXhlciB0eXBlIGFuZCBhZGRyZXNzLiBJZiBHUElPLWJhc2VkLCBhc2sKPiA+Pj4gZm9y
IHRoZSBjaGlwIG5hbWUgYW5kIHBpbiBudW1iZXJzIGZvciB0aGUgR1BJT3MuIEluIGJvdGggY2Fz
ZSwgcGxlYXNlCj4gPj4+IGFzayB3aGljaCBHUElPIGNvbWJpbmF0aW9ucyBtYXAgdG8gd2hpY2gg
bWVtb3J5IHNsb3RzLgo+IAo+IEkgaW5saW5lZCB0aGUgYWJvdmUgaHVuayB3aXRoIG15IHF1ZXN0
aW9uLCBhbmQgdGhlIGZpcnN0IHJlc3BvbnNlIHdhczoKPiAKPiA+IFJlY2VpdmVkIGZlZWRiYWNr
OyBUaGUgbWVtb3J5IGFkZHJlc3MgZG9lcyBub3QgdXNlIG11eC4gIEl0IGlzIGhhcmR3YXJlIGRl
ZmluZWQgYnkgSW50ZWwuCj4gCj4gU28gSSB3ZW50IGFuZCBjbGFyaWZpZWQgSSB3YXMgbm90IHRh
bGtpbmcgYWJvdXQgdGhlIEREUiBwaHlzaWNhbCBhZGRyZXNzIHNldHVwIGJ5IHRoZSBtZW1vcnkg
cmVmZXJlbmNlIGNvZGUsIGFuZCBJIGdvdDoKPiAKPiA+IFBlciBvdXIgZW5naW5lZXI7IFRoZXJl
IGlzIG5vIGhhcmR3YXJlIGNvbm5lY3RpbmcgdG8gRElNTS4KPiAKPiBJ4oCZbSBub3Qgc3VyZSBJ
4oCZdmUgZm91bmQgdGhlIHJpZ2h0IGhlbHAgaGVyZS4uLgo+IApBY3R1YWxseSB5b3UgbWlnaHQg
aGF2ZS4gT24gc29tZSBIVyB0aGUgRElNTXMgYXJlIGNvbm5jZXRlZCB0byBhIHNlcGFyYXRlClNN
QnVzIGNoYW5uZWwgd2hpY2ggaXMgbm90IHZpc2libGUgdG8gU1cuCgpHdWVudGVyCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxp
bmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3Jz
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Guenter Roeck]

T24gV2VkLCBKYW4gMjksIDIwMTQgYXQgMDU6MzA6MTRQTSAtMDgwMCwgR3VlbnRlciBSb2VjayB3
cm90ZToKPiBPbiBXZWQsIEphbiAyOSwgMjAxNCBhdCAwNToxMjo0OFBNIC0wODAwLCBBbHVuIEV2
YW5zIHdyb3RlOgo+ID4gCj4gPiBPbiAyOSBKYW4gMjAxNCwgYXQgMTE6NDgsIEFsdW4gRXZhbnMg
PGFsdW5AYmFkZ2Vyb3VzLm5ldD4gd3JvdGU6Cj4gPiAKPiA+ID4gVGhhbmtzIGZvciB0aGUgcmVz
cG9uc2VzIGV2ZXJ5b25lLCBpbmxpbmUsCj4gPiA+IAo+ID4gPiBPbiAyOSBKYW4gMjAxNCwgYXQg
MTA6MjUsIEd1ZW50ZXIgUm9lY2sgPGxpbnV4QHJvZWNrLXVzLm5ldD4gd3JvdGU6Cj4gPiA+IAo+
ID4gPj4gT24gV2VkLCBKYW4gMjksIDIwMTQgYXQgMDU6NDI6MjRQTSArMDEwMCwgSmVhbiBEZWx2
YXJlIHdyb3RlOgo+ID4gPj4+IEhpIEFsdW4sCj4gPiA+Pj4gPHNuaXA+Cj4gPiA+PiAKPiA+ID4+
PiBQbGVhc2UgYXNrIFN1cGVybWljcm8gYWJvdXQgaXQuCj4gPiA+IAo+ID4gPiBJIGhhdmUgcHV0
IGEgcmVxdWVzdCBpbuKApiBXZeKAmWxsIHNlZSBpZiBJIGdldCBhIHJlc3BvbnNlLgo+ID4gPiAK
PiA+ID4+PiBJZiB0aGUgbWVtb3J5IHNsb3RzIGFyZSBiZWhpbmQgYW4gSTJDCj4gPiA+Pj4gbXVs
dGlwbGV4ZXIsIGFzayB0aGVtIGlmIHRoZSBtdWx0aXBsZXhlciBpcyBJMkMtYmFzZWQgb3IgR1BJ
Ty1iYXNlZC4gSWYKPiA+ID4+PiBJMkMtYmFzZWQsIGFzayBmb3IgdGhlIG11bHRpcGxleGVyIHR5
cGUgYW5kIGFkZHJlc3MuIElmIEdQSU8tYmFzZWQsIGFzawo+ID4gPj4+IGZvciB0aGUgY2hpcCBu
YW1lIGFuZCBwaW4gbnVtYmVycyBmb3IgdGhlIEdQSU9zLiBJbiBib3RoIGNhc2UsIHBsZWFzZQo+
ID4gPj4+IGFzayB3aGljaCBHUElPIGNvbWJpbmF0aW9ucyBtYXAgdG8gd2hpY2ggbWVtb3J5IHNs
b3RzLgo+ID4gCj4gPiBJIGlubGluZWQgdGhlIGFib3ZlIGh1bmsgd2l0aCBteSBxdWVzdGlvbiwg
YW5kIHRoZSBmaXJzdCByZXNwb25zZSB3YXM6Cj4gPiAKPiA+ID4gUmVjZWl2ZWQgZmVlZGJhY2s7
IFRoZSBtZW1vcnkgYWRkcmVzcyBkb2VzIG5vdCB1c2UgbXV4LiAgSXQgaXMgaGFyZHdhcmUgZGVm
aW5lZCBieSBJbnRlbC4KPiA+IAo+ID4gU28gSSB3ZW50IGFuZCBjbGFyaWZpZWQgSSB3YXMgbm90
IHRhbGtpbmcgYWJvdXQgdGhlIEREUiBwaHlzaWNhbCBhZGRyZXNzIHNldHVwIGJ5IHRoZSBtZW1v
cnkgcmVmZXJlbmNlIGNvZGUsIGFuZCBJIGdvdDoKPiA+IAo+ID4gPiBQZXIgb3VyIGVuZ2luZWVy
OyBUaGVyZSBpcyBubyBoYXJkd2FyZSBjb25uZWN0aW5nIHRvIERJTU0uCj4gPiAKPiA+IEnigJlt
IG5vdCBzdXJlIEnigJl2ZSBmb3VuZCB0aGUgcmlnaHQgaGVscCBoZXJlLi4uCj4gPiAKPiBBY3R1
YWxseSB5b3UgbWlnaHQgaGF2ZS4gT24gc29tZSBIVyB0aGUgRElNTXMgYXJlIGNvbm5jZXRlZCB0
byBhIHNlcGFyYXRlCj4gU01CdXMgY2hhbm5lbCB3aGljaCBpcyBub3QgdmlzaWJsZSB0byBTVy4K
PiAKSSBoYWQgYSBxdWljayBnbGFuY2UgaW50byB0aGUgUGF0c2J1cmcgKGM2MDApIGRhdGFzaGVl
dC4gVGhlIGNoaXAgaGFzCnVwIHRvIGZvdXIgU01CdXMgY2hhbm5lbHMsIGRlcGVuZGluZyBvbiBj
aGlwIHZhcmlhbnQuIEFyZSB5b3Ugc3VyZQp0aGF0IHlvdSBhcmUgdGFsa2luZyB0byB0aGUgY29y
cmVjdCBvbmUgPyBXaGF0IGRvIHlvdSBzZWUgd2l0aCBsc3BjaSA/CgpUaGFua3MsCkd1ZW50ZXIK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxtLXNlbnNv
cnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNAbG0tc2Vuc29ycy5vcmcKaHR0cDovL2xpc3RzLmxt
LXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGluZm8vbG0tc2Vuc29ycw=

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Alun Evans]

[-- Attachment #1.1: Type: text/plain, Size: 1719 bytes --]


On 29 Jan 2014, at 17:30, Guenter Roeck <linux@roeck-us.net> wrote:

> On Wed, Jan 29, 2014 at 05:12:48PM -0800, Alun Evans wrote:
>> 
>> On 29 Jan 2014, at 11:48, Alun Evans <alun@badgerous.net> wrote:
>> 
>>> Thanks for the responses everyone, inline,
>>> 
>>> On 29 Jan 2014, at 10:25, Guenter Roeck <linux@roeck-us.net> wrote:
>>> 
>>>> On Wed, Jan 29, 2014 at 05:42:24PM +0100, Jean Delvare wrote:
>>>>> Hi Alun,
>>>>> <snip>
>>>> 
>>>>> 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 inlined the above hunk with my question, and the first response was:
>> 
>>> Received feedback; The memory address does not use mux.  It is hardware defined by Intel.
>> 
>> So I went and clarified I was not talking about the DDR physical address setup by the memory reference code, and I got:
>> 
>>> Per our engineer; There is no hardware connecting to DIMM.
>> 
>> I’m not sure I’ve found the right help here...
>> 
> Actually you might have. On some HW the DIMMs are connceted to a separate
> SMBus channel which is not visible to SW.

hmm, that was my worry.

Seemingly though IPMI is going via the BMC chip over an I2C bus to pull the temperatures from the DIMMs.

I wonder if I’m meant to be going that way as well to get the access to that I2C bus.


A.

-- 
Alun Evans

[-- Attachment #1.2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Alun Evans]

[-- Attachment #1.1: Type: text/plain, Size: 3019 bytes --]


On 29 Jan 2014, at 17:42, Guenter Roeck <linux@roeck-us.net> wrote:

> On Wed, Jan 29, 2014 at 05:30:14PM -0800, Guenter Roeck wrote:
>> On Wed, Jan 29, 2014 at 05:12:48PM -0800, Alun Evans wrote:
>>> 
>>> On 29 Jan 2014, at 11:48, Alun Evans <alun@badgerous.net> wrote:
>>> 
>>>> Thanks for the responses everyone, inline,
>>>> 
>>>> On 29 Jan 2014, at 10:25, Guenter Roeck <linux@roeck-us.net> wrote:
>>>> 
>>>>> On Wed, Jan 29, 2014 at 05:42:24PM +0100, Jean Delvare wrote:
>>>>>> Hi Alun,
>>>>>> <snip>
>>>>> 
>>>>>> 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 inlined the above hunk with my question, and the first response was:
>>> 
>>>> Received feedback; The memory address does not use mux.  It is hardware defined by Intel.
>>> 
>>> So I went and clarified I was not talking about the DDR physical address setup by the memory reference code, and I got:
>>> 
>>>> Per our engineer; There is no hardware connecting to DIMM.
>>> 
>>> I’m not sure I’ve found the right help here...
>>> 
>> Actually you might have. On some HW the DIMMs are connceted to a separate
>> SMBus channel which is not visible to SW.
>> 
> I had a quick glance into the Patsburg (c600) datasheet. The chip has
> up to four SMBus channels, depending on chip variant. Are you sure
> that you are talking to the correct one ? What do you see with lspci ?

I am talking to that one:

$ sudo lspci -v -v -v -s 0000:00:1f.3
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

Whether or not the DIMMs are connected to it is a good question.

It’s a C602:
http://www.supermicro.com/products/motherboard/xeon/c600/x9srg-f.cfm


Thinking about it, this Xeon has an integrated memory controller with 4 DDR3 channels, each of which can have 3 DIMMs per channel. That’s potentially 12 DIMMs on a board, which exceeds the 8 addressable SPDs given the 3 pins for addressing (SA{0-2}). While this board only has 8 DIMMs, it would make some sense if they were split in half with a mux somewhere.



A.

-- 
Alun Evans

[-- Attachment #1.2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Alun Evans]

[-- Attachment #1.1: Type: text/plain, Size: 4211 bytes --]


On 29 Jan 2014, at 19:39, Alun Evans <alun@badgerous.net> wrote:

> 
> On 29 Jan 2014, at 17:42, Guenter Roeck <linux@roeck-us.net> wrote:
> 
>> On Wed, Jan 29, 2014 at 05:30:14PM -0800, Guenter Roeck wrote:
>>> On Wed, Jan 29, 2014 at 05:12:48PM -0800, Alun Evans wrote:
>>>> 
>>>> On 29 Jan 2014, at 11:48, Alun Evans <alun@badgerous.net> wrote:
>>>> 
>>>>> Thanks for the responses everyone, inline,
>>>>> 
>>>>> On 29 Jan 2014, at 10:25, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>> 
>>>>>> On Wed, Jan 29, 2014 at 05:42:24PM +0100, Jean Delvare wrote:
>>>>>>> Hi Alun,
>>>>>>> <snip>
>>>>>> 
>>>>>>> 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 inlined the above hunk with my question, and the first response was:
>>>> 
>>>>> Received feedback; The memory address does not use mux.  It is hardware defined by Intel.
>>>> 
>>>> So I went and clarified I was not talking about the DDR physical address setup by the memory reference code, and I got:
>>>> 
>>>>> Per our engineer; There is no hardware connecting to DIMM.
>>>> 
>>>> I’m not sure I’ve found the right help here...
>>>> 
>>> Actually you might have. On some HW the DIMMs are connceted to a separate
>>> SMBus channel which is not visible to SW.
>>> 
>> I had a quick glance into the Patsburg (c600) datasheet. The chip has
>> up to four SMBus channels, depending on chip variant. Are you sure
>> that you are talking to the correct one ? What do you see with lspci ?
> 
> I am talking to that one:
> 
> $ sudo lspci -v -v -v -s 0000:00:1f.3
> 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
> 
> Whether or not the DIMMs are connected to it is a good question.
> 
> It’s a C602:
> http://www.supermicro.com/products/motherboard/xeon/c600/x9srg-f.cfm
> 
> 
> Thinking about it, this Xeon has an integrated memory controller with 4 DDR3 channels, each of which can have 3 DIMMs per channel. That’s potentially 12 DIMMs on a board, which exceeds the 8 addressable SPDs given the 3 pins for addressing (SA{0-2}). While this board only has 8 DIMMs, it would make some sense if they were split in half with a mux somewhere.
> 
> 

With some debug hacks to ipmi_devintf, running this:


$ 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)

Gets me a ton of:
ipmi-req: type:0xc chan:15
ipmi-rsp: type:0xc chan:15

then exactly this:

ipmi-req: type:0x1 chan:0
ipmi-rsp: type:0x1 chan:0
ipmi-req: type:0x1 chan:0
ipmi-rsp: type:0x1 chan:0
ipmi-req: type:0x1 chan:0
ipmi-rsp: type:0x1 chan:0

That type is

/* An IPMB Address. */
#define IPMI_IPMB_ADDR_TYPE		0x01

So looks like I enter this hunk:

https://github.com/mirrors/linux/blob/master/drivers/char/ipmi/ipmi_msghandler.c#L1559

And that bails if != IPMI_CHANNEL_MEDIUM_IPMB, and from

http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/second-gen-interface-spec-v2-rev1-4.pdf

6.5 Channel Medium Type 

1 IPMB (I2C)


Maybe I can convince the IPMI interface to take me out to the I2C bus then. Not sure how it is solving the addressing issue though.



A.

-- 
Alun Evans

[-- Attachment #1.2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Guenter Roeck]

On 01/29/2014 07:39 PM, Alun Evans wrote:
>
> On 29 Jan 2014, at 17:42, Guenter Roeck <linux@roeck-us.net> wrote:
>
>> On Wed, Jan 29, 2014 at 05:30:14PM -0800, Guenter Roeck wrote:
>>> On Wed, Jan 29, 2014 at 05:12:48PM -0800, Alun Evans wrote:
>>>>
>>>> On 29 Jan 2014, at 11:48, Alun Evans <alun@badgerous.net> wrote:
>>>>
>>>>> Thanks for the responses everyone, inline,
>>>>>
>>>>> On 29 Jan 2014, at 10:25, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>
>>>>>> On Wed, Jan 29, 2014 at 05:42:24PM +0100, Jean Delvare wrote:
>>>>>>> Hi Alun,
>>>>>>> <snip>
>>>>>>
>>>>>>> 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 inlined the above hunk with my question, and the first response was:
>>>>
>>>>> Received feedback; The memory address does not use mux.  It is hardware defined by Intel.
>>>>
>>>> So I went and clarified I was not talking about the DDR physical address setup by the memory reference code, and I got:
>>>>
>>>>> Per our engineer; There is no hardware connecting to DIMM.
>>>>
>>>> I’m not sure I’ve found the right help here...
>>>>
>>> Actually you might have. On some HW the DIMMs are connceted to a separate
>>> SMBus channel which is not visible to SW.
>>>
>> I had a quick glance into the Patsburg (c600) datasheet. The chip has
>> up to four SMBus channels, depending on chip variant. Are you sure
>> that you are talking to the correct one ? What do you see with lspci ?
>
> I am talking to that one:
>
> $ sudo lspci -v -v -v -s 0000:00:1f.3
> 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
>
Anything else that looks like an SMBus controller ? The datasheet says that "SRV/WS SKUs Only"
would have additional SMBus controllers.

> Whether or not the DIMMs are connected to it is a good question.
>
> It’s a C602:
> http://www.supermicro.com/products/motherboard/xeon/c600/x9srg-f.cfm
>

>
> Thinking about it, this Xeon has an integrated memory controller with 4 DDR3 channels, each of which can have 3 DIMMs per channel. That’s potentially 12 DIMMs on a board, which exceeds the 8 addressable SPDs given the 3 pins for addressing (SA{0-2}). While this board only has 8 DIMMs, it would make some sense if they were split in half with a mux somewhere.
>

Presumably there must be a means for the BIOS to read the SPD data to be able to
program the DRAM controller correctly. No idea how that works in detail, though.

Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Jean Delvare]

On Wed, 29 Jan 2014 19:23:23 -0800, Alun Evans wrote:
> Seemingly though IPMI is going via the BMC chip over an I2C bus to pull the temperatures from the DIMMs.
> 
> I wonder if I’m meant to be going that way as well to get the access to that I2C bus.

Well, as a side note, mixing IPMI and native access is not a good idea
anyway. So if you intend to use IPMI I suppose you should stick to that.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Reading SPD on Intel Patsburg on Supermicro X9SRG-F board

[Alun Evans]

[-- Attachment #1.1: Type: text/plain, Size: 1008 bytes --]


On 30 Jan 2014, at 09:01, Jean Delvare <khali@linux-fr.org> wrote:

> On Wed, 29 Jan 2014 19:23:23 -0800, Alun Evans wrote:
>> Seemingly though IPMI is going via the BMC chip over an I2C bus to pull the temperatures from the DIMMs.
>> 
>> I wonder if I’m meant to be going that way as well to get the access to that I2C bus.
> 
> Well, as a side note, mixing IPMI and native access is not a good idea
> anyway. So if you intend to use IPMI I suppose you should stick to that.

Yeah, I even tried:

> BMC Enable/Disable (JPB1)
> 
> JPB1 is used to enable or disable the BMC (Baseboard Management Control) chip and the onboard IPMI port. This jumper is used together with the IPMI settings in the BIOS. See the table on the right for jumper settings.

But that didn’t seem to help.

I’m going to shelve this project for now until I get a better contact in supermicro.

Thanks for all the help, I’ll followup when (if?) I eventually make some progress on this.


A.

-- 
Alun Evans

[-- Attachment #1.2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors