Dell ipmi-oem chassis slot availability?
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Dell ipmi-oem chassis slot availability?
by DeRamus, Chris-2
::
Rate this Message:
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 Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: Dell ipmi-oem chassis slot availability?
by Ryan Cox
::
Rate this Message:
Chris,
I'm not sure how to do it with any ipmi-based commands, but "dmidecode -s baseboard-serial-number" should return that information from the OS. On my Dell systems, it returns two rows of information. The first contains the system's service tag, the board's serial number (ipmi-fru's first entry), and the slot number separated by period characters. The second line is the chassis' serial number and the slot number, similarly separated. We don't have asset tags set, so those may show up in there to if you use them. Information can be pulled from HP systems in a similar fashion with "dmidecode -t 204 |grep 'Server Bay'" or just "dmidecode |grep 'Server Bay'" This information is also available remotely via SNMP to the iDRAC: "snmpget -t 1 -r 1 -c public -v2c -O qve $yourhost-idrac DELL-RAC-MIB::drsProductSystemSlot.0". You'll have to download the MIBs from support.dell.com. By the way, we also do inventory tracking in a similar fashion to what you're moving towards. It works quite nicely when everything is set up. I've looked before at doing this via IPMI but also came up short. Ryan On 12/18/2011 07:39 AM, 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 > Freeipmi-users@... > https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Ryan Cox Systems Administrator Fulton Supercomputing Lab Brigham Young University http://tech.ryancox.net _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: Dell ipmi-oem chassis slot availability?
by Albert Chu
::
Rate this Message:
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 > Freeipmi-users@... > https://lists.gnu.org/mailman/listinfo/freeipmi-users Albert Chu chu11@... Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: Dell ipmi-oem chassis slot availability?
by Ryan Cox
::
Rate this Message:
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. 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 >> Freeipmi-users@... >> https://lists.gnu.org/mailman/listinfo/freeipmi-users >> -- Ryan Cox Systems Administrator Fulton Supercomputing Lab Brigham Young University http://tech.ryancox.net _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: Dell ipmi-oem chassis slot availability?
by DeRamus, Chris-2
::
Rate this Message:
Yes, I actually ran through those same tests myself yesterday and came up empty. I've started trying to get an answer from Dell directly, but have found it difficult to do so with legacy hardware that currently all has expired support contracts :).
-----Original Message----- From: freeipmi-users-bounces+cderamus=ea.com@... [mailto:freeipmi-users-bounces+cderamus=ea.com@...] On Behalf Of Ryan Cox Sent: Tuesday, December 20, 2011 2:20 PM To: Albert Chu Cc: freeipmi-users@... Subject: Re: [Freeipmi-users] Dell ipmi-oem chassis slot availability? 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. 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 >> Freeipmi-users@... >> https://lists.gnu.org/mailman/listinfo/freeipmi-users >> -- Ryan Cox Systems Administrator Fulton Supercomputing Lab Brigham Young University http://tech.ryancox.net _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: Dell ipmi-oem chassis slot availability?
by Albert Chu
::
Rate this Message:
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 > >> Freeipmi-users@... > >> https://lists.gnu.org/mailman/listinfo/freeipmi-users > >> > > > Albert Chu chu11@... Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: Dell ipmi-oem chassis slot availability?
by Ryan Cox
::
Rate this Message:
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 >>>> Freeipmi-users@... >>>> https://lists.gnu.org/mailman/listinfo/freeipmi-users >>>> >> >> -- Ryan Cox Systems Administrator Fulton Supercomputing Lab Brigham Young University http://tech.ryancox.net _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
by Albert Chu
::
Rate this Message:
[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 > >>>> Freeipmi-users@... > >>>> https://lists.gnu.org/mailman/listinfo/freeipmi-users > >>>> > >> > >> > > Albert Chu chu11@... Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
by Albert Chu
::
Rate this Message:
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 > > >>>> Freeipmi-users@... > > >>>> https://lists.gnu.org/mailman/listinfo/freeipmi-users > > >>>> > > >> > > >> > > > > Albert Chu chu11@... Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
by DeRamus, Chris-2
::
Rate this Message:
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 [chu11@...] Sent: Tuesday, December 20, 2011 4:49 PM To: Ryan Cox Cc: freeipmi-devel@...; 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 > > >>>> Freeipmi-users@... > > >>>> https://lists.gnu.org/mailman/listinfo/freeipmi-users > > >>>> > > >> > > >> > > > > Albert Chu chu11@... Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
by DeRamus, Chris-2
::
Rate this Message:
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:chu11@...] Sent: Tuesday, December 20, 2011 4:47 PM To: Ryan Cox Cc: freeipmi-devel@...; 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 > >>>> Freeipmi-users@... > >>>> https://lists.gnu.org/mailman/listinfo/freeipmi-users > >>>> > >> > >> > > Albert Chu chu11@... Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
by Ryan Cox
::
Rate this Message:
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. 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 >>>>>> Freeipmi-users@... >>>>>> https://lists.gnu.org/mailman/listinfo/freeipmi-users >>>>>> >>>> >> -- Ryan Cox Systems Administrator Fulton Supercomputing Lab Brigham Young University jkrfghglkfgklsdaklglhsaglhkag _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
by Ryan Cox
::
Rate this Message:
And the results of 0xE0-0xEF:
================================================ [root@m6-35-6 computenodehealthcheck.d]# for a in {0..9} A B C D E F; do for selector in {0..1}; do for blocksel in {0..15}; do echo -ne "\n0xE$a $selector $blocksel: "; ipmi-raw 0 6 59 0 0xE$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 0xE0 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 " 0xE0 1 0: rcvd: 59 00 11 01 38 2E 32 30 38 2E 39 35 3A 34 34 33 00 => " 8 . 2 0 8 . 9 5 : 4 4 3 " 0xE1 0 0: rcvd: 59 00 11 01 => " " 0xE5 0 0: rcvd: 59 00 11 03 => " " 0xE5 1 0: rcvd: 59 00 11 03 => " " 0xE8 0 0: rcvd: 59 00 11 01 00 01 01 00 01 00 00 00 00 => " " 0xE8 1 0: rcvd: 59 00 11 01 00 01 01 00 01 00 00 00 00 => " " 0xE9 0 0: rcvd: 59 00 11 0C 01 95 31 00 AD 00 80 01 00 00 26 B9 00 00 00 00 00 00 => " � 1 � � & � " 0xE9 1 0: rcvd: 59 00 11 0C 02 95 31 00 AD 00 80 01 00 00 26 B9 00 00 00 00 00 00 => " � 1 � � & � " 0xEA 0 0: rcvd: 59 00 11 54 01 00 54 01 F2 00 00 00 00 00 00 => "T T � " 0xEA 1 0: rcvd: 59 00 11 88 04 01 54 01 F2 00 00 00 00 00 00 => "� T � " 0xEB 0 0: rcvd: 59 00 11 4A 00 5B 00 78 00 75 00 => "J [ x u " 0xEB 1 0: rcvd: 59 00 11 4A 00 5B 00 78 00 75 00 => "J [ x u " 0xEC 0 0: rcvd: 59 00 11 4F 00 7E 00 B4 00 B4 00 10 AB F0 4E 02 9E F0 4E E6 4F F0 4E E6 4F F0 4E => "O ~ � � � � N � � N � O � N � O � N " 0xEC 1 0: rcvd: 59 00 11 4F 00 7E 00 B4 00 B4 00 10 AB F0 4E 02 9E F0 4E E6 4F F0 4E E6 4F F0 4E => "O ~ � � � � N � � N � O � N � O � N " 0xED 0 0: rcvd: 59 00 11 47 00 42 00 42 00 40 00 3E AB F0 4E 7C A1 F0 4E 7C A1 F0 4E 84 F3 ED 4E => "G B B @ > � � N | � � N | � � N � � � N " 0xED 1 0: rcvd: 59 00 11 47 00 42 00 42 00 40 00 3E AB F0 4E 7C A1 F0 4E 7C A1 F0 4E 84 F3 ED 4E => "G B B @ > � � N | � � N | � � N � � � N " ================================================ 0xE0 - enclosure's web interface URL spread across two set selectors. Also, 0xF3 shows "https://[]:443". We don't have IPv6 set up anywhere, but I'll have to test that out when I get back from Christmas holidays. 0xF0, 0xF2, 0xF3, 0xF4, and 0xF6 showed information, but only 0xF3 (IPv6 URL) and 0xF2 showed anything interesting: 0xF2 0 0: rcvd: 59 00 11 00 00 37 00 01 00 00 00 00 00 00 00 00 00 00 00 00 => " 7 ". Not sure what 0xF2 is. 0xC0-0xCF revealed nothing new beyond what's in ipmi-oem. 0xA0-0xBF returned nothing. If there's anything else worthwhile to check, let me know. Ryan On 12/20/2011 03:34 PM, 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. > > 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 >>>>>>> Freeipmi-users@... >>>>>>> https://lists.gnu.org/mailman/listinfo/freeipmi-users >>>>>>> >>>>> >>> > > -- Ryan Cox Systems Administrator Fulton Supercomputing Lab Brigham Young University http://tech.ryancox.net _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
by Albert Chu
::
Rate this Message:
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 > >>>>>> Freeipmi-users@... > >>>>>> https://lists.gnu.org/mailman/listinfo/freeipmi-users > >>>>>> > >>>> > >> > > > -- > Ryan Cox > Systems Administrator > Fulton Supercomputing Lab > Brigham Young University > jkrfghglkfgklsdaklglhsaglhkag > Albert Chu chu11@... Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
by Ryan Cox
::
Rate this Message:
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 >>>>>>>> Freeipmi-users@... >>>>>>>> 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 _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
by DeRamus, Chris-2
::
Rate this Message:
I ran this against our 500 M600 blades and am happy to report it's working flawlessly. The only other Dell hardware that we have are 1U/2U rack mountable PowerEdge servers and when ran against those nothing is returned which is what I would expect :).
PowerEdge 2950: #> ipmi-raw 0 6 59 0 0xDC 0 0 -h 192.168.100.140 rcvd: 59 80 Thanks again for all of your help on this guys. Enjoy your holiday season. -----Original Message----- From: freeipmi-users-bounces+cderamus=ea.com@... [mailto:freeipmi-users-bounces+cderamus=ea.com@...] On Behalf Of Ryan Cox Sent: Tuesday, December 20, 2011 7:00 PM To: Albert Chu Cc: freeipmi-devel@... Subject: Re: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot availability? 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 >>>>>>>> Freeipmi-users@... >>>>>>>> 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 _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
by Albert Chu
::
Rate this Message:
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 > >>>>>>>> Freeipmi-users@... > >>>>>>>> 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 chu11@... Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
by Albert Chu-2
::
Rate this Message:
Hey Ryan,
Hmmmm. You're pretty deep into the set selectors by that point. I'm wondering if you may have wandered into a region of data that we normally shouldn't wander into (i.e. the IPMI get system info command may just be reading memory at whatever pointer it is told). In this particular case, there's a lot of the 0xD4 data earlier on that we're still not clear about what it is. Al On Tue, Dec 20, 2011 at 4:00 PM, Ryan Cox <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 >>>>>>>>> Freeipmi-users@... >>>>>>>>> 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 > > > > _______________________________________________ > Freeipmi-users mailing list > Freeipmi-users@... > https://lists.gnu.org/mailman/listinfo/freeipmi-users _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
Re: [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
by Albert Chu
::
Rate this Message:
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 > > >>>>>>>> Freeipmi-users@... > > >>>>>>>> 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 > chu11@... > Computer Scientist > High Performance Systems Division > Lawrence Livermore National Laboratory > > > > _______________________________________________ > Freeipmi-users mailing list > Freeipmi-users@... > https://lists.gnu.org/mailman/listinfo/freeipmi-users Albert Chu chu11@... Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list Freeipmi-users@... https://lists.gnu.org/mailman/listinfo/freeipmi-users |
|
|
|
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
