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 [[email protected]] Sent: Tuesday, December 20, 2011 4:49 PM To: Ryan Cox Cc: [email protected]; 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 > > >>>> [email protected] > > >>>> https://lists.gnu.org/mailman/listinfo/freeipmi-users > > >>>> > > >> > > >> > > > > -- Albert Chu [email protected] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list [email protected] https://lists.gnu.org/mailman/listinfo/freeipmi-users
