Hey Holger, (BTW, I'm splitting this thread into two, so the response to the other part is in the new thread). > I had intended to add this into ipmi-sel, but w/o a mobo to test on I > > let it pass. If you're game to test a patch for me, I'd be glad to > > implement it into ipmi-sel. I'm busy right now, so it may take some > > time for me to get a patch together. > > I can try to understand/dive into ipmi-sel and come up with something > for review. This would definitely be the better place to implement > this feature.
If you can, that'd be great (LMK if you begin something, so I won't start to work on it too). Because this wouldn't be a straight OEM code -> string conversion (you're instead calling another Fujitsu IPMI call), there will be subtleties that I know I'm going to mess up on that you may just know off the top of your head. The key OEM extension support would be added into libfreeipmi/src/sel-parse/. If you take a look in there, you'll already see a whole bunch of files for SEL OEM extension support for Dell, Inventec, Quanta, etc. I imagine a Fujitsu equivalent could just be plugged right in. Based on the Dan's e-mail: ---- System Firmware Progress | System Firmware Error ; Unspecified ; OEM Event Data3 code = 5Fh ---- This would need a "ipmi_sel_parse_output_fujitsu_event_data3_discrete_oem" equivalent call, so that the event data 3 OEM code could be converted into a string. I imagine other situations that perhaps you'd also want to implement a ipmi_sel_parse_output_fujitsu_event_data2_event_data3() equivalent function when event data 2 & 3 are OEM codes. Note that when you're putting things into the functions I've listed, the output from the ipmi-sel tool wouldn't be like Dan's patch. Instead you would see: System Firmware Progress | System Firmware Error ; Unspecified ; FUJITSU OEM OUTPUT instead of System Firmware Progress | FUJITSU OEM OUTPUT Now ---- <snip> OEM Reserved | Event Offset = 00h ; OEM Event Data2 code = 83h ; OEM Event Data3 code = 4Dh ---- Is a different beast. I imagine we'd want an output of: OEM Reserved | FUJITSU OEM OUTPUT instead of OEM Reserved | EVENT STRING ; FUJITSU OEM OUTPUT The situation of OEM event in data 1, 2, and 3 does not have a "callback". So we'd have to stick one in for that. > > Short term, I think we can add this patch into ipmi-oem as an extra OEM > > option for Fujitsu motherboards. > > > > BTW, what mobo are you running this on, so I can document in the future. > > > > This feature/OEM command is available on all current BMC's from > Fujitsu, even on the previous generation. The intention is to provide > a consistent SEL translation and severity assignment across different > tools. That's definitely a good thing. Unfortunately, not all vendors are that consistent. So internally I've added motherboard product IDs as I can verify the OEM support works for a particular product ID. In manpages/documents I list the specific motherboards I've testd on. But since you work with Fujitsu, if you can verify a range of Fujitsu products, we can support/document that range. Al > This also works for time stamped OEM SEL entries which we use for a > limited auditing (e.g. login or power control from IP a.b.c.d). > Unfortunately due to memory constrains in the previous BMC generation > the maximum length of a single response is limited to 64bytes, while > on the current product line you should be able to get the full > 100bytes translated SEL text with a single request at least over LAN. > Maximum (non standard) KCS transfer size is also different between > current (255) and previous (64) generation, so the code should compare > the data received with the total length reported in the response. > > If you want to double check for support of this OEM command beforehand, you > can evaluate the Get Device Id response: > Vendor ID: 0x2880 > ProductId: should be >= 0x0200 On Tue, 2010-08-17 at 08:14 -0700, Liebig, Holger wrote: > > > > Hi Dan, > > > > > In the fact, it would be better to use the function as part of > > > interpret-oem-data within ipmi-sel, but it require better knowledge of > > > current implementation of ipmi-sel than I have. Someone with better > > > skills may implement it (using the code from patch). Then I can help > > > with testing, if necessary. > > > > I had intended to add this into ipmi-sel, but w/o a mobo to test on I > > let it pass. If you're game to test a patch for me, I'd be glad to > > implement it into ipmi-sel. I'm busy right now, so it may take some > > time for me to get a patch together. > > I can try to understand/dive into ipmi-sel and come up with something for > review. This would definitely be the better place to implement this feature. > But first I have to find an issue with the SDR cache: Al any idea why Get SDR > might try to read only 5 Bytes from Offset 0 instead of the previous 16bytes > when reading the last record 1770 (see attached debug output)? > > > > > Short term, I think we can add this patch into ipmi-oem as an extra OEM > > option for Fujitsu motherboards. > > > > BTW, what mobo are you running this on, so I can document in the future. > > > > This feature/OEM command is available on all current BMC's from Fujitsu, even > on the previous generation. The intention is to provide a consistent SEL > translation and severity assignment across different tools. This also works > for time stamped OEM SEL entries which we use for a limited auditing (e.g. > login or power control from IP a.b.c.d). > Unfortunately due to memory constrains in the previous BMC generation the > maximum length of a single response is limited to 64bytes, while on the > current product line you should be able to get the full 100bytes translated > SEL text with a single request at least over LAN. Maximum (non standard) KCS > transfer size is also different between current (255) and previous (64) > generation, so the code should compare the data received with the total > length reported in the response. > > If you want to double check for support of this OEM command beforehand, you > can evaluate the Get Device Id response: > Vendor ID: 0x2880 > ProductId: should be >= 0x0200 > > Holger > -- Albert Chu [email protected] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/freeipmi-devel
