I ran this against our 500 M600 blades and am happy to report it's working flawlessly. The only other Dell hardware that we have are 1U/2U rack mountable PowerEdge servers and when ran against those nothing is returned which is what I would expect :).
PowerEdge 2950: #> ipmi-raw 0 6 59 0 0xDC 0 0 -h 192.168.100.140 rcvd: 59 80 Thanks again for all of your help on this guys. Enjoy your holiday season. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ryan Cox Sent: Tuesday, December 20, 2011 7:00 PM To: Albert Chu Cc: [email protected] Subject: Re: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot availability? Al, Sounds good. Just so you know, 0xDA and "ipmi-oem dell get-system-info mac-addresses" don't return anything useful for 11G systems. The ipmi-oem command does work on an M600 (which it gets from 0xCB based on my reading of the source code). The MAC address for an M610 is actually at 0xD4: 0xD4 10 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 => " " 0xD4 11 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 => " " 0xD4 12 0: rcvd: 59 00 11 00 00 00 00 00 1F 0F 00 00 23 AE FC => " # " 0xD4 13 0: rcvd: 59 00 11 E6 D4 1F 00 00 23 AE FC E6 D5 0F 01 => " # " 0xD4 14 0: rcvd: 59 00 11 00 23 AE FC E6 D6 1F 01 00 23 AE FC => " # # " 0xD4 15 0: rcvd: 59 00 11 E6 D7 17 00 00 00 00 00 00 00 17 00 => " " 0xD4 16 0: rcvd: 59 00 11 00 00 00 00 00 00 17 00 00 00 00 00 => " " 0xD4 17 0: rcvd: 59 00 11 00 00 17 00 00 00 00 00 00 00 17 00 => " " <Name> <Presence> <BMC MAC Address> <NIC1 MAC Address> <NIC2 MAC Address> Server-16 Present 00:23:AE:FB:8D:FF 00:23:AE:FC:E6:D4 00:23:AE:FC:E6:D6 It appears consistent for an M600 and may be a more portable option: 0xD4 10 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 => " " 0xD4 11 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 => " " 0xD4 12 0: rcvd: 59 00 11 00 00 00 00 00 1F 0E 00 00 22 19 7B => " " { " 0xD4 13 0: rcvd: 59 00 11 25 93 1E 00 00 22 19 7B 25 94 0E 01 => "% " { % " 0xD4 14 0: rcvd: 59 00 11 00 22 19 7B 25 95 1E 01 00 22 19 7B => " " { % " { " 0xD4 15 0: rcvd: 59 00 11 25 96 16 00 00 00 00 00 00 00 16 00 => "% " 0xD4 16 0: rcvd: 59 00 11 00 00 00 00 00 00 16 00 00 00 00 00 => " " 0xD4 17 0: rcvd: 59 00 11 00 00 16 00 00 00 00 00 00 00 1F 00 => " " Server-15 Present 00:22:19:7B:2C:58 00:22:19:7B:25:93 00:22:19:7B:25:95 I'm going to be out of the office for the holidays starting now, so I may or may not be able to respond to any emails for a while. I also need to investigate higher numbered set selectors more. I'm getting results for some up to 0x30 that I spot checked. Ryan On 12/20/2011 04:18 PM, Albert Chu wrote: > Hey Ryan, > > On Tue, 2011-12-20 at 14:34 -0800, Ryan Cox wrote: >> Al, >> >> I should have caught that it was ASCII :) >> >> Please pardon the horrific line noise.... Here's the output for an >> M610 using a very ugly command I strung together: >> ================================================ >> >> # for a in {0..9} A B C D E F; do for selector in {0..15}; do for >> blocksel in {0..15}; do echo -ne "\n0xD$a $selector $blocksel: "; >> ipmi-raw 0 6 59 0 0xD$a $selector $blocksel | perl -e '$s =<>; chomp >> $s; print "$s => \""; @bytes = split /\s+/, $s; @bytes; if($bytes[2] >> ne >> "00") { print "Error code $bytes[2] returned\n"; exit; } for($a=4; >> $a<$#bytes+1; $a++) { printf "%s ", chr(hex($bytes[$a])); } print >> "\"\n";'; done; done; done |grep -v Error |grep -a rcvd >> 0xD1 0 0: rcvd: 59 00 11 00 00 0F 50 6F 77 65 72 45 64 67 65 20 4D 36 >> 31 >> 30 => " P o w e r E d g e M 6 1 0" >> 0xD1 1 0: rcvd: 59 00 11 01 00 => "" >> 0xD1 2 0: rcvd: 59 00 11 02 => "" >> 0xD1 3 0: rcvd: 59 00 11 03 => "" >> 0xD2 0 0: rcvd: 59 00 11 01 => "" >> 0xD3 0 0: rcvd: 59 00 11 00 00 => "" >> 0xD4 1 0: rcvd: 59 00 11 02 01 C2 06 02 00 50 5F 53 31 00 00 => " >> P _ S 1 " >> 0xD4 2 0: rcvd: 59 00 11 02 02 C2 06 02 00 50 5F 53 31 00 00 => " >> P _ S 1 " >> 0xD4 3 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 => "" >> 0xD4 4 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 => "" >> 0xD4 5 0: rcvd: 59 00 11 01 00 00 00 00 00 00 00 00 00 00 00 => "" >> 0xD4 6 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 => "" >> 0xD4 7 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 => "" >> 0xD4 8 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 => "" >> 0xD4 9 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 => "" >> 0xD4 10 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 => "" >> 0xD4 11 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 => "" >> 0xD4 12 0: rcvd: 59 00 11 00 00 00 00 00 1F 05 00 00 26 B9 FC => " & " >> 0xD4 13 0: rcvd: 59 00 11 B2 7C 15 00 00 26 B9 FC B2 7D 05 01 => " >> | & } " >> 0xD4 14 0: rcvd: 59 00 11 00 26 B9 FC B2 7E 15 01 00 26 B9 FC => "& >> ~ & " >> " 0: rcvd: 59 00 11 B2 7F 0D 00 00 00 00 00 00 00 0D 00 => " >> 0xD5 1 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 => "" >> 0xD5 2 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 => "" >> 0xD5 3 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 => "" >> 0xD5 4 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 => "" >> 0xD5 5 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 => "" >> 0xD5 6 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 => "" >> 0xD5 7 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 => "" >> 0xD5 8 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 => "" >> 0xD5 9 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 => "" >> 0xD6 0 0: rcvd: 59 00 11 00 01 0F 00 => " " >> 0xDC 0 0: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 30 36 00 00 00 00 00 >> 00 >> 00 => " S L O T - 0 6" >> 0xDC 1 0: rcvd: 59 00 11 01 00 00 => "" >> 0xDC 2 0: rcvd: 59 00 11 02 => "" >> 0xDC 3 0: rcvd: 59 00 11 03 => "" >> 0xDD 0 0: rcvd: 59 00 11 00 00 27 00 01 C0 A8 D2 8A 00 00 00 00 00 00 >> 00 >> 00 => " ' " >> 0xDD 1 0: rcvd: 59 00 11 01 00 00 00 00 33 2E 30 35 20 28 42 75 69 6C >> 64 >> 20 => " 3 . 0 5 ( B u i l d" >> 0xDD 2 0: rcvd: 59 00 11 02 31 29 00 00 00 00 00 00 0B => " 1 ) " >> 0xDD 3 0: rcvd: 59 00 11 03 00 00 00 00 D8 3A 8D BE D7 39 8D BE 00 00 >> 00 >> 00 => " : 9 " >> 0xDD 4 0: rcvd: 59 00 11 04 02 00 00 00 24 7A 2A 40 DC 72 02 00 01 00 >> 00 >> 00 => " $ z * @ r " >> 0xDE 0 0: rcvd: 59 00 11 00 00 1B 68 74 74 70 73 3A 2F 2F 31 39 32 2E >> 31 >> 36 => " h t t p s : / / 1 9 2 . 1 6" >> 0xDE 1 0: rcvd: 59 00 11 01 38 2E 32 31 30 2E 31 33 38 3A 34 34 33 => >> " >> 8 . 2 1 0 . 1 3 8 : 4 4 3 " >> 0xDE 2 0: rcvd: 59 00 11 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 >> 00 => "" >> 0xDE 3 0: rcvd: 59 00 11 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 >> 00 => "" >> 0xDE 4 0: rcvd: 59 00 11 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 >> 00 => "" >> 0xDE 5 0: rcvd: 59 00 11 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 >> 00 => "" >> 0xDE 6 0: rcvd: 59 00 11 06 00 00 00 00 00 00 00 00 06 00 00 00 00 00 >> 00 >> 00 => " " >> 0xDF 0 0: rcvd: 59 00 11 00 00 29 00 01 C0 A8 D0 5F 00 00 00 00 00 00 >> 00 >> 00 => " ) _" >> 0xDF 1 0: rcvd: 59 00 11 01 00 00 00 00 33 2E 30 33 00 00 00 00 00 00 >> 00 >> 00 => " 3 . 0 3" >> 0xDF 2 0: rcvd: 59 00 11 02 00 00 00 00 00 00 00 00 09 01 03 => " " >> 0xDF 3 0: rcvd: 59 00 11 03 => "" >> >> >> >> ================================================ >> >> >> Observations:: >> 0xD1 - the system type >> 0xD4 - shows something... not sure what it is 0xDC - the slot number >> 0xDD - the iDRAC version including build number 0xDE - the iDRAC web >> interface URL (IP and port) 0xDF - the enclosure's CMC version >> >> * These observations are consistent for: M610, M910, M600, M610x >> (M610x requires both 0 and 1 sets for 0xD1 so that the "x" shows up). >> * It does NOT work at all on an R200 (fairly old iDRAC firmware) >> * An R710 shows 0xD1, 0xD4 (no clue what it is) and 0xDE only, though >> the R710's iDRAC firmware is much older. The R710 returns zero bytes >> for most of the others but doesn't error out. > Cool. 0xD1 is already done in ipmi-oem as well as 0xDA (MAC address). > > Going through and re-learning this code in ipmi-oem, it seems a number > of these map to this format: > > * Parameter data response formatted: > * > * Set Selector 0: > * > * 1st byte = set selector > * 2nd byte = encoding > * 3rd byte = string length > * ? bytes = string > * > * Set Selector> 0 > * > * 1st byte = set selector > * ? bytes = string > > I'm in the middle of something right now, but I'll try to get this > into ipmi-oem sometime soon and send you link to a code tree w/ beta code. > I'll probably need your guy's help to write the manpage entries and > such since you guys know the hardware better :-) > > Al > > P.S. the FreeIPMI 1.1.1 beta is about to come out, so I doubt it'll > get into that. 1.1.2 is a more likely target. > >> Multiple set selectors (correct term?) are required for at least 0xDD >> and 0xDE. The block selector seemed to do nothing. >> >> >> Ryan >> >> On 12/20/2011 02:47 PM, Albert Chu wrote: >>> [moving thread to freeipmi-devel] >>> >>> Hey Ryan, >>> >>> This looks very interesting. 0xDC isn't one I know of yet. It >>> could totally be available and just not published by Dell yet. >>> >>> rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 36 00 00 00 00 00 00 00 >>> >>> the 0x59 is the command byte (same as in the input command line). >>> The next 0x00 is the completion code (0 = success). >>> >>> In similar formats from Dell (see ipmi-oem-dell.c), the byte >>> afterwards is typically a length/count of some sort, 0x11 = 17, >>> which does equal the remaining number of bytes. So we're on the right >>> track. >>> >>> I took a guess that this might be ascii, lookie at what it maps too. >>> >>> 53 = S >>> 4C = L >>> 4F = O >>> 54 = T >>> 2D = - >>> 31 = 1 >>> 36 = 6 >>> >>> only the 0x10 = DLE is an oddity. Do 0xD1 - 0xDF output anything >>> similar? I'm wondering if this data is a part of additional data. >>> Could you also fiddle with: >>> >>> /usr/sbin/ipmi-raw 0 6 59 0 0xDC XX YY >>> >>> the XX& YY bytes. They are the set selector/block selector fields. >>> Perhaps there is additional string data surrounding this. >>> >>> If it's consistent across all slots, systems, and we can figure this >>> all out, we can get this into ipmi-oem. Chris can you also verify >>> on your systems? >>> >>> Al >>> >>> On Tue, 2011-12-20 at 12:43 -0800, Ryan Cox wrote: >>>> Al, >>>> >>>> I just found this on 0xDC for a blade in slot 16: >>>> # ipmi-raw 0 6 59 0 0xDC 0 0 >>>> rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 36 00 00 00 00 00 00 00 >>>> >>>> You'll have to bear with me on this since I'm not sure of what the >>>> standard is for counting bytes when referring to the data returned >>>> from ipmi-raw, so I'll assume the "59" is byte 0. >>>> >>>> Bytes 11 and 12 ("31" and "36" above) have the slot number for each >>>> of the M610s, M910s, M600s, and M610X that I tested. It's a weird >>>> way of encoding it but it has worked everywhere I have tested. Bit >>>> 0 of byte >>>> 11 is the first *decimal* digit of the slot number (i.e. 0 or 1). >>>> I assume that other bits could be used if Dell comes out with a >>>> chassis that holds more blades but, of course, have no way to test >>>> that. Bits >>>> 0-3 of byte 12 are the second decimal digit of the slot number (i.e. 0-9). >>>> >>>> I've tested on close to 100 blades and it is consistent. >>>> >>>> Examples: >>>> >>>> Slot 15: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 35 00 00 00 00 >>>> 00 00 00 Slot 05: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 30 35 00 >>>> 00 00 00 00 00 00 Slot 02: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D >>>> 30 32 00 00 00 00 00 00 00 Slot 14: rcvd: 59 00 11 00 00 10 53 4C >>>> 4F 54 2D 31 34 00 00 00 00 00 00 00 >>>> >>>> Ryan >>>> >>>> On 12/20/2011 12:50 PM, Albert Chu wrote: >>>>> On Tue, 2011-12-20 at 11:20 -0800, Ryan Cox wrote: >>>>>> Al, >>>>>> >>>>>> I tried iterating from 0xC0 through 0xCF on some Dell M610s and >>>>>> didn't find the slot number. I compared the results of several >>>>>> that were in the same chassis so that most of the information >>>>>> would be the same. I saw no differences that seemed to indicate >>>>>> the slot number. The only differences at all that I saw from >>>>>> blades in the same chassis were at >>>>>> 0xC3 and 0xC5 (expected). We don't have asset tags set or I >>>>>> would expect to see differences in 0xC4. >>>>> Sorry it didn't work. It was worth a shot :-) >>>>> >>>>> Al >>>>> >>>>>> Ryan >>>>>> >>>>>> On 12/19/2011 11:04 AM, Albert Chu wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> I might be misunderstanding your question, but it seems you want >>>>>>> to figure out what type of board is inside each slot? I assume >>>>>>> the ipmi-oem Dell command 'get-system-info' isn't enough b/c you >>>>>>> only get the board name and not the slot number? >>>>>>> >>>>>>> I don't know of any OEM commands for this, so the first thing is >>>>>>> I'd bug Dell, b/c someone there might be able to provide it (you >>>>>>> will have to fight them to get to the right people, the first >>>>>>> line support will likely have no idea). If you get something >>>>>>> from them, please let the list know and we can put it in ipmi-oem. >>>>>>> >>>>>>> Depending on your willingness to try and reverse engineer >>>>>>> something, there might be a way to determine it. The following >>>>>>> is an ipmi-raw that should implement the same thing as "ipmi-oem >>>>>>> dell get-system-info asset-tag" >>>>>>> >>>>>>> /usr/sbin/ipmi-raw 0 6 59 0 0xC4 0 0 >>>>>>> >>>>>>> In ipmi-oem here's a comment on the parameter numbers: >>>>>>> >>>>>>> * guid parameter = 0xC3 >>>>>>> * asset-tag parameter = 0xC4 >>>>>>> * service-tag parameter = 0xC5 >>>>>>> * chassis-service-tag parameter = 0xC6 >>>>>>> * chassis-related-service-tag parameter = 0xC7 >>>>>>> * board-revision parameter = 0xC8 >>>>>>> >>>>>>> This is what we know of or have been told. It wouldn't be hard >>>>>>> to imagine that 0xC9, 0xCA ,0xCB might return your slot number. >>>>>>> >>>>>>> Al >>>>>>> >>>>>>> On Sun, 2011-12-18 at 06:39 -0800, DeRamus, Chris wrote: >>>>>>>> I've just learned about the wonders of IPMI this past month and have >>>>>>>> re-written our inventory system from scratch to take advantage of the >>>>>>>> data the FreeIPMI suite of tools provides easy access to. Right now >>>>>>>> the only drawback is that I have to run a secondary script at each >>>>>>>> co-location to access each of our Dell M1000e chassis, running >>>>>>>> proprietary racadm command over SSH to correlate which 10g/11g >>>>>>>> PowerEdge blades are running in the various slots. I've been digging >>>>>>>> through the documentation in hopes of finding either a oem command >>>>>>>> that I can run or even a ipmi-raw command that can be passed to each >>>>>>>> blade to pull this data, but so far I've come up short. >>>>>>>> >>>>>>>> Has anyone on this list been able to identify a method to capture this >>>>>>>> particular information? Dell's OMSA utility also provides the slot >>>>>>>> information as seen in the output below. >>>>>>>> >>>>>>>> #> omreport chassis info >>>>>>>> Chassis Information >>>>>>>> >>>>>>>> Index : 0 >>>>>>>> Chassis Name : Main System Chassis >>>>>>>> Host Name : xxxxxxxxxxxx >>>>>>>> iDRAC6 Version : 1.60 >>>>>>>> Chassis Model : PowerEdge M600 >>>>>>>> Chassis Lock : Not Present >>>>>>>> Chassis Service Tag : XX11YY2 >>>>>>>> Server Module Service Tag : YY11XX2 >>>>>>>> Server Module Location : Slot 14<-- This is what I >>>>>>>> need >>>>>>>> Flash chassis identify LED state : Off >>>>>>>> Flash chassis identify LED timeout value : 300 >>>>>>>> >>>>>>>> Thanks in advance for the time guys. >>>>>>>> >>>>>>>> --Chris >>>>>>>> _______________________________________________ >>>>>>>> Freeipmi-users mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.gnu.org/mailman/listinfo/freeipmi-users >>>>>>>> >> >> -- >> Ryan Cox >> Systems Administrator >> Fulton Supercomputing Lab >> Brigham Young University >> >> http://tech.ryancox.net -- Ryan Cox Systems Administrator Fulton Supercomputing Lab Brigham Young University http://tech.ryancox.net _______________________________________________ Freeipmi-users mailing list [email protected] https://lists.gnu.org/mailman/listinfo/freeipmi-users _______________________________________________ Freeipmi-users mailing list [email protected] https://lists.gnu.org/mailman/listinfo/freeipmi-users
