There is a big difference between the driver, which just passes messages around mostly, and the sensor handling, which requires interpretation of SDRs and things like that. The driver should work with a 0.9 system, but the OpenIPMI library will not, for instance. I'd be willing to work on this (the driver part), but I'll need access to the system. -corey Stian Jordet wrote: > Andrew, > > Thanks for clarifying things a bit. (Or a lot, actually). I really > appreciate it :) > > Since I'm not able to code the decoding into human readable part my > self, it would be much easier to convince someone else to try if you > could show me some specifications or some other magic that needs to be > done different with IPMI 0.9? > > It seems most ipmiutil commands mostly works. I can read (and reset) the > System Event Log, I can show the watchdog timer (haven't tried doing > anything else with it) and I can get sensor readings (altough not > readable...). Although both "fru" and "health" commands quits with an > error message. > > But, most important for me; getting sensor-readings human readable. In > one form or another. So far I have made these observations: > > Corey Minyard wrote this: > > "It should work, the IPMI driver will work with an IPMI 0.9 system. I > looked in the technical specifications for the board, but I didn't see > any useful information about port numbers or such." > > So, the ipmi_si should work with IPMI 0.9. Why doesn't it? What does > ipmiutil do different than the ipmi_si module? > > Vladislav Bogdanov ported the original 2.4 kernel bmcsensors to work with IPMI 0.9. http://bubble.nsys.by/projects/ipmi/ > > > Second, Yani Ioannou - the author of the ipmisensors module, has earlier > (in 2005) written this: > http://archives.andrew.net.au/lm-sensors/msg29983.html > > "As a side note, I'm working on integrating the ipmi 0.9 patch into the > 2.6 bmcsensors driver, the original ipmi 0.9 patch was not as > significant as its size would lead one to believe (as you so noted), and > I'm trying to rework it so it is more maintainable and has less code > repetition." > > which is also confirmed in the source of the ipmisensors-module > (http://bmcsensors-26.sourceforge.net/ipmisensors/ipmisensors-20070630-1330.diff) > > /* If the ipmi version is 0.9 we have to remap some things. > * Yes this is very ugly, but we aren't the ones who > * implemented an incomplete spec! > */ > > So it seems both the ipmi_si module, and the ipmisensors-module is > supposed to work with IPMI 0.9. The main (and $10 000) question is what > is "wrong" with my SC450NX that won't make it recognized? > > If someone could figure that out, I'll be eternally grateful. I might > even be persuaded to donate some money to the person that makes it happen. > > Thanks for your splendid help so far! Really been helpful :) > > Regards, > Stian > > > Cress, Andrew R wrote: > >> Stian, >> >> OK, the GetDeviceID response being short indicates that it is >> pre-IPMI-1.0, probably IPMI 0.9. >> The actual displayed versions from the utilities are being picked out >> from the IPMI 1.0+ locations, so they are not valid. I don't remember >> the format of the IPMI 0.9 DeviceID response off-hand, but you do have >> something that works, mostly. >> >> Also, decoding the sensor readings in IPMI 0.9 must be different, but at >> least you can get the raw readings. >> There is an Intel IMB IPMI driver that does support IPMI 0.9, and there >> are several things that need to be handled differently in IPMI 0.9 (kcs >> state machine, GetDeviceID response, SendMessage/GetMessage is >> different, ...). >> >> Given that the ipmisensors module is probably coded to IPMI 1.0 and >> greater, using it wouldn't yield any advantage over what you currently >> get from "ipmiutil sensor", which did try to decode them but with >> 'unspecified' results. >> >> Decoding the sensor readings from raw form into human-readable form >> would have to be implemented for IPMI 0.9 in whatever utilities you >> pick. How big a deal is this? >> >> Andy >> >> -----Original Message----- >> From: openipmi-developer-bounces at lists.sourceforge.net >> [mailto:openipmi-developer-bounces at lists.sourceforge.net] On Behalf Of >> Stian Jordet >> Sent: Tuesday, October 02, 2007 2:39 AM >> To: Cress, Andrew R >> Cc: openipmi-developer at lists.sourceforge.net; yani.ioannou at gmail.com; >> slava at nsys.by; minyard at acm.org; lm-sensors at lm-sensors.org >> Subject: Re: [Openipmi-developer] IPMI and ipmisensors on an Intel >> SC450NX >> >> Andrew, >> >> first, I'm sorry I am not replying to you email, I accidentally deleted >> >> it :( >> >> Now we're getting somewhere: >> >> root at buick:~# ipmiutil health -x >> ipmiutil ver 2.0 >> bmchealth ver 1.15 >> ipmi_open: driver type = unknown >> ipmi_open_mv: cannot open /dev/ipmi/0 >> ipmi_open_mv: cannot open /dev/ipmi0 >> ipmi_open_mv: cannot open /dev/ipmidev0 >> ipmi_open_mv: cannot open /dev/ipmidev/0 >> imbapi.c ipmi_open_ia: open(/dev/imb) failed: No such file or directory >> ipmi_open_va: cannot open /dev/ipmikcs >> ipmi_open_va: cannot open /dev/ipmi/kcs >> SMBIOS Table is present at Physical Address 0x000eee60 ... >> No IPMI Data Structure Found in SMBIOS Table, >> Continuing with KCS on Default Port 0x0ca2 >> BMC Initialized. >> ipmidir Cmd=01 NetFn=06 Lun=00 Sa=20 Data(0): >> wait_for_OBF_set: max loop 5001 >> ipmidir Resp: status=0 cc=00 Data(6): 05 01 00 35 10 1f >> open_direct: status=0, KCS drv, ipmi=0 >> ipmi_open rc = 0 type = kcs >> Driver type kcs, open rc = 0 >> ipmidir Cmd=01 NetFn=06 Lun=00 Sa=20 Data(0): >> wait_for_OBF_set: max loop 5001 >> ipmidir Resp: status=0 cc=00 Data(6): 05 01 00 35 10 1f >> BMC version 0.35, IPMI version 0.1 >> BMC manufacturer = ca0000 , product = 0493 >> ipmidir Cmd=07 NetFn=06 Lun=00 Sa=20 Data(0): >> wait_for_OBF_set: max loop 5001 >> ipmidir Resp: status=0 cc=c1 Data(0): >> ccode c1: Invalid Command >> Cannot do ipmi_getpowerstate, ret = 193 >> >> Altough there still is something it doesn't like about my system, I at >> least get some output :P But IPMI Version 0.1? Is that a typo for 1.0? >> :) >> >> root at buick:~# ipmiutil sel >> ipmiutil ver 2.0 >> showsel: version 1.54 >> -- BMC version 0.35, IPMI version 0.1 >> SEL Ver 10 Support 2, Size = 488 records, Free space = 482 records >> RecId Date/Time_______ Source_ Evt_Type SensNum Evt_detail - Trig >> [Evt_data] >> 8001 01/01/70 01:00:07 BMC 05 Platform Security #33 - 03 [01 ff ff] >> 9001 09/30/07 22:54:23 0011 12 System Event #ef - e7 [01 ff ff] >> a001 01/01/70 01:00:07 BMC 05 Platform Security #33 - 03 [01 ff ff] >> b001 10/01/07 17:22:54 0011 12 System Event #ef - e7 [01 ff ff] >> c001 01/01/70 01:00:07 BMC 05 Platform Security #33 - 03 [01 ff ff] >> d001 10/01/07 17:35:21 0011 12 System Event #ef - e7 [01 ff ff] >> showsel: completed successfully >> >> >> root at buick:~# ipmiutil sensor >> ipmiutil ver 2.0 >> sensor: version 1.59 >> -- BMC version 0.35, IPMI version 0.1 >> _ID_ SDR_Type_xx Sz Own Typ S_Num Sens_Description Hex & Interp >> Reading >> 0020 SDR Full 01 39 20 a f8 snum 04 Baseboard -12V = 6a OK* >> 2520000212.00 unspecified >> 4020 SDR Full 01 3b 20 a f8 snum 14 Basebrd PCI Temp = 9c OK* >> 2360080184.00 unspecified >> 8020 SDR Full 01 3b 20 a f8 snum 15 Basebrd PXB Temp = a0 OK* >> 2360082240.00 unspecified >> c020 SDR Full 01 3b 20 a f8 snum 16 Processor 1 Temp = 9a OK* >> 2360079156.00 unspecified >> 0021 SDR Full 01 3b 20 a f8 snum 17 Processor 2 Temp = 9b OK* >> 2360079670.00 unspecified >> 4021 SDR Full 01 3b 20 a f8 snum 18 Processor 3 Temp = 9d OK* >> 2360080698.00 unspecified >> 8021 SDR Full 01 3b 20 a f8 snum 19 Processor 4 Temp = 9c OK* >> 2360080184.00 unspecified >> c021 SDR Full 01 37 20 a f8 snum 01 Baseboard 5V = bd OK* >> 440012474.00 unspecified >> 0022 SDR Full 01 38 20 a f8 snum 02 Baseboard 12V = aa OK* >> 440000340.00 unspecified >> 4022 SDR Full 01 39 20 a f8 snum 03 Baseboard 3.3V = df OK* >> 440000446.00 unspecified >> 8022 SDR Full 01 39 20 a f8 snum 0c Baseboard 2.5V = cb OK* >> 440000406.00 unspecified >> c022 SDR Full 01 39 20 a f8 snum 0b Baseboard 1.5V = 9b OK* >> 440000310.00 unspecified >> 0023 SDR Full 01 36 20 a f8 snum 13 SCSI-N Volt = ca OK* >> 440000404.00 unspecified >> 4023 SDR Full 01 3a 20 a f8 snum 1a Baseboard Fan 2 = 5e OK* >> 80000188.00 unspecified >> 8023 SDR Full 01 3a 20 a f8 snum 1b Baseboard Fan 1 = 63 OK* >> 80000198.00 unspecified >> c023 SDR Full 01 3a 20 a f8 snum 1c Baseboard Fan 4 = 5b OK* >> 80000182.00 unspecified >> 0024 SDR Full 01 3a 20 a f8 snum 1d Baseboard Fan 3 = 64 OK* >> 80000200.00 unspecified >> 4024 SDR Full 01 3a 20 a f8 snum 1e Baseboard Fan 5 = 5a OK* >> 80000180.00 unspecified >> 8024 SDR Full 01 3a 20 a f8 snum 1f Baseboard Fan 8 = 5c OK* >> 80000184.00 unspecified >> c024 SDR Full 01 3a 20 a f8 snum 20 Baseboard Fan 7 = 5f OK* >> 80000190.00 unspecified >> 0025 SDR Full 01 3a 20 a f8 snum 21 Baseboard Fan 6 = 5a OK* >> 80000180.00 unspecified >> 4025 SDR Full 01 39 20 a f8 snum 22 PwrShare Fan 1 = 57 OK* >> 80000174.00 unspecified >> 8025 SDR Full 01 39 20 a f8 snum 23 PwrShare Fan 2 = 55 OK* >> 80000170.00 unspecified >> c025 SDR Full 01 39 20 a f8 snum 24 PwrShare Fan 3 = 56 OK* >> 80000172.00 unspecified >> 0026 SDR Full 01 38 20 a f8 snum 2d PwrShare Temp = 9f OK* >> 2360081726.00 unspecified >> 4026 SDR Comp 02 25 20 a 49 snum 2c 3-4 L2 VID = c0 c0 fb b7 >> Deassert >> 7026 SDR Comp 02 25 20 a 49 snum 2b 1-2 L2 VID = c0 00 00 00 OK >> a026 SDR Comp 02 22 20 a 49 snum 31 oc Term = c0 00 00 00 OK >> d026 SDR Comp 02 26 20 a 09 snum 27 ssor 1 Stat = 80 80 00 00 >> Enabled >> 0027 SDR Comp 02 26 20 a 09 snum 28 ssor 2 Stat = 80 80 00 00 >> Enabled >> 3027 SDR Comp 02 26 20 a 09 snum 29 ssor 3 Stat = 80 80 00 00 >> Enabled >> 6027 SDR Comp 02 26 20 a 09 snum 2a ssor 4 Stat = 80 80 00 00 >> Enabled >> 9027 SDR Comp 02 25 20 a 49 snum 25 edund Lost = 00 80 00 00 OK >> c027 SDR Comp 02 20 20 a 09 snum 26 Unit = 00 00 00 00 >> NotAvailable >> f027 SDR Comp 02 24 20 a 49 snum 32 Post Code = 00 00 00 00 >> NotAvailable >> 2028 SDR Comp 02 26 20 a 49 snum 41 MP Password = c0 00 00 00 OK >> 5028 SDR Comp 02 26 20 a 49 snum 33 ntrusion ID = c1 00 00 00 OK >> 8028 SDR Comp 02 24 20 a 49 snum 36 rtPnl NMI = 00 80 00 00 OK >> b028 SDR Comp 02 22 20 a 49 snum 37 atchdog = 00 80 00 00 OK >> e028 SDR Comp 02 25 20 a 49 snum 34 Violation = c0 00 00 00 OK >> 1029 SDR Comp 02 1f 20 a 43 snum 35 tate = c0 00 00 00 OK >> 4029 SDR Comp 02 24 20 a 49 snum 2e are Sup 1 = 01 80 00 00 OK >> 7029 SDR Comp 02 24 20 a 49 snum 2f are Sup 2 = 01 80 00 00 OK >> a029 SDR Comp 02 24 20 a 49 snum 30 are Sup 3 = 01 80 00 00 OK >> d029 SDR Comp 02 1f 20 a 49 snum 38 tate = c0 00 00 00 OK >> 002a SDR Comp 02 26 20 a 49 snum 0d Term Vlt A1 = c0 00 00 00 OK >> 302a SDR Comp 02 26 20 a 49 snum 0e Term Vlt A2 = c0 00 00 00 OK >> 602a SDR Comp 02 26 20 a 49 snum 0f Term Vlt A3 = c0 00 00 00 OK >> 902a SDR Comp 02 26 20 a 49 snum 10 Term Vlt B1 = c0 00 00 00 OK >> c02a SDR Comp 02 26 20 a 49 snum 11 Term Vlt B2 = c0 00 00 00 OK >> f02a SDR Comp 02 26 20 a 49 snum 12 Term Vlt B3 = c0 00 00 00 OK >> 202b SDR Comp 02 24 c0 a 49 snum 01 rv Status = bd c0 00 00 OK >> 502b SDR Comp 02 26 c0 a 49 snum 07 rv Presence = 00 00 00 00 >> NotAvailable >> 802b SDR DLoc 10 1b dev: 20 00 00 05 00 bd Basbrd Mgmt Ctlr >> a02b SDR DLoc 10 1a dev: ae 50 00 20 08 00 Processor 1 FRU >> c02b SDR DLoc 10 1a dev: aa 50 00 20 08 00 Processor 2 FRU >> e02b SDR DLoc 10 1a dev: a6 50 00 20 08 00 Processor 3 FRU >> 002c SDR DLoc 10 1a dev: a2 50 00 20 08 00 Processor 4 FRU >> 202c SDR DLoc 10 17 dev: d0 40 00 20 09 02 PwrShare FRU >> 402c SDR DLoc 10 18 dev: c0 00 00 02 00 85 Hot Swap Ctlr >> 602c SDR DLoc 10 1b dev: aa 40 00 20 09 02 Memory Board FRU >> 802c SDR DLoc 10 1b dev: d2 40 00 20 09 02 Pwr Supply 1 FRU >> a02c SDR DLoc 10 1b dev: d4 40 00 20 09 02 Pwr Supply 2 FRU >> c02c SDR DLoc 10 1b dev: d6 40 00 20 09 02 Pwr Supply 3 FRU >> e02c SDR OEM c0 10 manuf=5391443: 20 56 65 72 73 69 6f 6e 20 31 2e 33 >> 37 >> sensor: completed successfully >> >> Is there anything that can be done, so that the ipmi_si module will work >> >> on this system? (And by extension, hopefully the ipmisensors module). >> >> Last, the fan and temperature readings, aren't they supposed to be human >> >> readable? >> >> Thanks for your great help, all of you! Much appreciated! >> >> Regards, >> Stian >> >> Stian Jordet wrote: >> >> >>> On man, 2007-10-01 at 05:53 -0700, Cress, Andrew R wrote: >>> >>> >>> >>>> Stian, >>>> >>>> I believe the port should be 0xCA2, not 0xCA0. >>>> According to the docs, it does have IPMI support, but it would be >>>> >>>> >> only >> >> >>>> local (no IPMI LAN). >>>> >>>> Try modprobe ipmi_si type="kcs" addrs="0xca0" >>>> or just modprobe ipmi_si >>>> >>>> >>>> >>> Unfortunately, neither of this works. I've tried >>> >>> root at buick:~# modprobe ipmi_si >>> FATAL: Error inserting ipmi_si >>> >>> >> (/lib/modules/2.6.21/kernel/drivers/char/ipmi/ipmi_si.ko): No such >> device >> >> >>> root at buick:~# modprobe ipmi_si type="kcs" ports="0xca0" >>> FATAL: Error inserting ipmi_si >>> >>> >> (/lib/modules/2.6.21/kernel/drivers/char/ipmi/ipmi_si.ko): No such >> device >> >> >>> root at buick:~# modprobe ipmi_si type="kcs" ports="0xca2" >>> FATAL: Error inserting ipmi_si >>> >>> >> (/lib/modules/2.6.21/kernel/drivers/char/ipmi/ipmi_si.ko): No such >> device >> >> >>> I don't really know if there is more to try. But as you say, the board >>> should support IPMI, so I don't really know why it doesn't seem to. >>> Hmm. >>> >>> I guess it was worth a try :) >>> >>> Thanks to everyone who replied :) >>> >>> Regards, >>> Stian >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Stian Jordet [mailto:liste at jordet.net] >>>> Sent: Monday, October 01, 2007 3:58 AM >>>> To: lm-sensors at lm-sensors.org >>>> Cc: yani.ioannou at gmail.com; Cress, Andrew R; slava at nsys.by >>>> Subject: IPMI and ipmisensors on an Intel SC450NX >>>> >>>> Hi, >>>> >>>> Sorry, this is going to be long and probably cross-posted too many >>>> places, but it isn't easy to know where to direct this! The persons >>>> >>>> >> in >> >> >>>> the CC-field I have found after searching on the net, hoping any of >>>> >>>> >> them >> >> >>>> have some bright ideas! >>>> >>>> I've used the weekend (again!) trying to get sensors working on my >>>> >>>> >> good >> >> >>>> old Intel SC450NX server, with no luck. >>>> >>>> First of all, I'm not even sure what IPMI version this system has. I >>>> found this mail: >>>> >>>> >>>> >>>> >> http://sourceforge.net/mailarchive/message.php?msg_id=74A9A71929931E4096 >> >> >>>> 7CA9F27B1D7396014D46A2%40hdsmsx401.amr.corp.intel.com >>>> >>>> where an Intel employee thinks it is IPMI 1.0, and either way it >>>> >>>> >> should >> >> >>>> work with the ipmi_imb emulation driver, which supposedly uses the >>>> >>>> >> same >> >> >>>> interface as the original Intel Server Manager uses. I'm still afraid >>>> >>>> >> it >> >> >>>> is IPMI 0.9 I have. >>>> >>>> I have updated both BIOS, BMC and FRUSDR (whatever that is) to the >>>> latest available versions. dmidecode doesn't have any traces of ipmi. >>>> But lm-sensors sensors-detect reports this: >>>> >>>> [...] >>>> Probing for `IPMI BMC KCS' at 0xca0... Success! >>>> (confidence 4, driver `ipmisensors') >>>> Probing for `IPMI BMC SMIC' at 0xca8... No >>>> [...] >>>> >>>> which at least gave me some hope. The ipmisensors page says I need to >>>> use ipmi_si before loading the ipmisensors-module. I then tried >>>> >>>> >> loading >> >> >>>> some modules... >>>> >>>> root at buick:~# modprobe ipmi_si >>>> IPMI System Interface driver. >>>> ipmi_si: Unable to find any System Interface(s) >>>> FATAL: Error inserting ipmi_si >>>> (/lib/modules/2.6.21/kernel/drivers/char/ipmi/ipmi_si.ko): No such >>>> device >>>> >>>> root at buick:~# modprobe ipmi_si type="kcs" addrs="0xca0" >>>> IPMI System Interface driver. >>>> ipmi_si: Trying hardcoded-specified kcs state machine at mem address >>>> 0xca0, slave address 0x0, irq 0 >>>> Could not set up I/O space >>>> ipmi_si: Unable to find any System Interface(s) >>>> FATAL: Error inserting ipmi_si >>>> (/lib/modules/2.6.21/kernel/drivers/char/ipmi/ipmi_si.ko): No such >>>> device >>>> >>>> After applying ipmi_emu.diff from http://openipmi.sf.net, I tried the >>>> earlier promised ipmi_imb driver: >>>> >>>> root at buick:~# modprobe ipmi_imb >>>> ipmi: can't create user -22 >>>> FATAL: Error inserting ipmi_imb >>>> (/lib/modules/2.6.21/kernel/drivers/char/ipmi/ipmi_imb.ko): Invalid >>>> argument >>>> >>>> Not looking that good... What does "can't create user -22" mean? I >>>> >>>> >> found >> >> >>>> this in my dmesg: >>>> >>>> pnp: 00:01: ioport range 0xca0-0xca7 has been reserved >>>> >>>> Which gave me hope that pnp was "locking" the ipmi addresses. Booted >>>> with pnpbios=no and pnpacpi=off and even acpi=off, no difference. >>>> >>>> I ran the FRUSDR utility from a boot disk, and got this output: >>>> >>>> a:\>frusdr /p /d fru >>>> >>>> FRU & SDR Load Utility Version 3.4 >>>> >>>> FRU IMBDEVICE on bus FFh, IMB address 20h, LUN 00 >>>> >>>> Display Header Area >>>> Common Header Area (Version 1, Length 8) >>>> Internal Area Offset = 01h >>>> Chassis Area Offset = 1Ah >>>> Board Area Offset = 1Eh >>>> Product Area Offset = 26h >>>> Multirecord Area Offset = 00h >>>> PAD = 00h >>>> CHECKSUM = A0h >>>> >>>> Don't know what any of this means, except it kinda says it does have >>>> >>>> >> a >> >> >>>> "imbdevice" (Which I had some hopes the ipmi_imb driver would >>>> support...) >>>> >>>> Ok, I found this http://bubble.nsys.by/projects/ipmi/ and this >>>> http://archives.andrew.net.au/lm-sensors/msg29983.html on the web, >>>> showing at least two attempts trying to get bmcsensors working with >>>> >>>> >> IPMI >> >> >>>> 0.9 (if that's what my system has), but I haven't found any sign of >>>> success or not. I am especially curious as to whether Yani's attempt >>>> >>>> >> to >> >> >>>> make bmcsensors working with IPMI 0.9 will have any effect now that >>>> ipmisensors seems to use ipmi_si and OpenIPMI does not suppoert IPMI >>>> 0.9... >>>> >>>> Anyone have any bright ideas where to look next? Or am I really out >>>> >>>> >> of >> >> >>>> luck? >>>> >>>> Thanks. >>>> >>>> Regards, >>>> Stian >>>> >>>> >>>> >>>> >>> >>> >> ------------------------------------------------------------------------ >> - >> >> >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Openipmi-developer mailing list >>> Openipmi-developer at lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/openipmi-developer >>> >>> >>> >>> >> ------------------------------------------------------------------------ >> - >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Openipmi-developer mailing list >> Openipmi-developer at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/openipmi-developer >> >> >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Openipmi-developer mailing list > Openipmi-developer at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openipmi-developer >
