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