On 29 Jan 2014, at 19:39, Alun Evans <alun@xxxxxxxxxxxxx> wrote: > > On 29 Jan 2014, at 17:42, Guenter Roeck <linux@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote: >>>> >>>>> 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, >>>>>>> <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:
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
