Al, Works fantastic, I just ran it against the bulk of our hardware without issue.
> ./ipmi-oem -h 192.168.100.166 dell get-system-info slot-number SLOT-10 > ./ipmi-oem -h 192.168.100.166 dell get-system-info idrac-info IP Address : 10.18.245.166 IP Configuration : DHCP iDRAC Firmware Version : 1.55 (Build 2) iDRAC Type : Dell Poweredge 10G --Chris ________________________________________ From: DeRamus, Chris Sent: Friday, December 23, 2011 6:03 PM To: [email protected]; [email protected]; DeRamus, Chris Cc: [email protected] Subject: Re: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot availability? I will give this a shot this weekend and report back on Monday. Thanks ! Chris DeRamus Online Operations Team Bioware Mythic 703.877.8726 ----- Reply message ----- From: "Albert Chu" <[email protected]> Date: Fri, Dec 23, 2011 4:39 pm Subject: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot availability? To: "Ryan Cox" <[email protected]>, "DeRamus, Chris" <[email protected]> Cc: "[email protected]" <[email protected]> Hey Ryan, Chris, At this branch I added new Dell additions to ipmi-oem. If you could try them out, I'd appreciate it. The branch for this new code is at: svn co http://svn.savannah.gnu.org/svn/freeipmi/branches/ipmioemdellgetsysteminfo after checking out: ./autogen.sh ; ./configure --enable-debug ; make and then ipmi-oem/ipmi-oem dell get-system-info X (of course run w/ outofband options as needed.) the new options are Option: slot-number (0xDC) Option: system-revision (0xF4) Option: idrac-info (0xDD) Option: idrac-ipv4-url (0xDE) Option: idrac-gui-webserver-control (0xE1) Option: cmc-ipv4-url (0xE0) Option: cmc-ipv6-info (0xF2) Option: cmc-ipv6-url (0xF3) Option: snmp-ipv6-info (0xF0) I also added 12G mac address support w/ "mac-addresses". Unsure if that will fix your earlier described problem. I found a Poweredge R610 and could verify idrac-info, idrac-ipv4-url, idrac-gui-webserver-control. None of the rest have been verified to work. There might be others we can add to this list once we learn more. We'll need to iterate a tad to figure it all out. Please let me know if you find any issues. Al On Thu, 2011-12-22 at 15:23 -0800, Albert Chu wrote: > Hi Ryan, > > I totally forgot: > > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_LCD_STRING > 0xC1 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_LCD_CONFIGURATION > 0xC2 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_SYSTEM_GUID > 0xC3 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_SYSTEM_ASSET_TAG > 0xC4 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_SYSTEM_SERVICE_TAG > 0xC5 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_CHASSIS_SERVICE_TAG > 0xC6 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_CHASSIS_RELATED_SERVICE_TAG > 0xC7 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_BOARD_REVISION > 0xC8 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_SYSTEM_ID > 0xC9 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_BIOS_FEATURE > 0xCA > /* Only for 10G systems */ > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_EMBEDDED_NICS_MAC_ADDRESSES > 0xCB > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_EMBEDDED_NICS_CAPABILITY > 0xCE > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_PLATFORM_MODEL_NAME > 0xD1 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_LOCAL_CONSOLE_LOCKOUT > 0xD6 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_POWER_STAGGERING_AC_RECOVERY > 0xD8 > /* achu: this one is taken from code, is correct name? */ > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_11G_MAC_ADDRESSES > 0xDA > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_IDRAC_INFO > 0xDD > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_IDRAC_IPV4_URL > 0xDE > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_CMD_IPV4_URL > 0xE0 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_GUI_WEBSERVER_CONTROL > 0xE1 > #define > IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_PLATFORM_SPECIFIC_DEVICE_INFORMATION 0xE3 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_LCD_STATUS > 0xE7 > /* achu: this one is taken from code, is correct name? */ > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_POWER_CAPACITY > 0xEA > #define > IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_AVERAGE_POWER_CONSUMPTION_STATISTICS 0xEB > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_MAX_POWER_CONSUMPTION_STATISTICS > 0xEC > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_MIN_POWER_CONSUMPTION_STATISTICS > 0xED > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_EMBEDDED_VIDEO_STATUS > 0xEE > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_ISCSI_NICS_MAC_ADDRESSES > 0xEF > #define > IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_IPV6_SNMP_TRAP_DESTINATION_ADDRESS 0xF0 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_INTERNAL_STORAGE_SLOT_INFO > 0xF1 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_CMC_IPV6_INFO > 0xF2 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_CMC_IPV6_URL > 0xF3 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_SYSTEM_REVISION > 0xF4 > #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_REDUNDANCY_POLICY > 0xFE > > Some are implemented/hidden within other ipmi-oem Dell command's b/c the > output format is unique/different (most notably the power consumption > stuff). However, many were not implemented for simple reason that I did > not have access to a motherboard that supported them or I found the info > not useful. > > I'll start adding a few I wasn't interested in before (like idrac info) > and a few of those we discussed earlier. Play around with the other > ones and LMK what works for you. I can add them and we can iterate as I > add them to ipmi-oem. Note that many don't output in ASCII, we're > mostly just looking for a successful return was non-zero output. > > Al > > On Tue, 2011-12-20 at 16:00 -0800, Ryan Cox wrote: > > 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 > > > -- > 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 -- 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
