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

[DeRamus, Chris]

Not that I can see Al:

#> ipmi-fru -h 192.168.100.254 -vv
FRU Inventory Device: Default FRU Device (ID 00h)

  FRU Board Language: English
  FRU Board Manufacturing Date/Time: 01/01/96 - 00:00:00
  FRU Board Manufacturer: DELL
  FRU Board Product Name: PowerEdgeM600
  FRU Board Serial Number: CN2314024S01MJ
  FRU Board Part Number: 0MYA33A01

________________________________________
From: Albert Chu address@hidden
Sent: Tuesday, December 20, 2011 4:49 PM
To: Ryan Cox
Cc: address@hidden; DeRamus, Chris
Subject: Re: [Freeipmi-devel] Dell ipmi-oem chassis slot availability?

One extra thing I just thought of.  The data that Dell typically pulls
asset-tag, board-revision, etc. is actually stored in the same place as
the FRU.  Did you guys check the FRU via ipmi-fru?  Perhaps with
ipmi-fru -vv?  Is it possible the slot data is hidden in there
somewhere?

Al

On Tue, 2011-12-20 at 13:47 -0800, 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
> > >>>>
> > >>
> > >>
> >
> >
--
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory