freeipmi-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: DeRamus, Chris
Subject: Re: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
Date: Tue, 20 Dec 2011 14:12:15 -0800

Looks like that is it. I just confirmed the output on three separate blades:

M600 in slot 11:
#> ipmi-raw 0 6 59 0 0xDC 0 0 -h 192.168.100.196
rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 31 00 00 00 00 00 00 00

M600 in slot 13:
#> ipmi-raw 0 6 59 0 0xDC 0 0 -h 192.168.100.210
rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 33 00 00 00 00 00 00 00

M600 in slot 03:
#> ipmi-raw 0 6 59 0 0xDC 0 0 -h 192.168.100.214
rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 30 33 00 00 00 00 00 00 00

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

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]