Re: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot availability?

[Albert Chu]

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
> >>>>>> address@hidden
> >>>>>> https://lists.gnu.org/mailman/listinfo/freeipmi-users
> >>>>>>
> >>>>
> >>
> 
> 
> --
> Ryan Cox
> Systems Administrator
> Fulton Supercomputing Lab
> Brigham Young University
> jkrfghglkfgklsdaklglhsaglhkag
> 
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory