Hey Peter, I think I figured it out, I introduced a sequence number wrap around bug in 0.8.1 when I was "cleaning up" some code. Most motherboards don't have anywhere near the number of sensors that the Dell ones do, so they never reach that point. I'll put up a beta tar.gz tomorrow.
Al On Thu, 2010-02-11 at 16:44 -0800, Al Chu wrote: > Hi Peter, > > > First of all let me thank you for the great work that you and other > > developers are doing, this is truly a very helpful tool. > > You're definitely welcome. > > > I was thinking of submitting this problem through the GNU FreeIPMI > > project bugs page but did not see any activity there so decided to > > mail you directly. I hope that that is OK. > > No problem, but in the future it's best to e-mail the > [email protected] list (I'm CCing it now). > > > Now to the problem. When running ipmi-* tools that can generate SDR cache > > such as ipmimonitoring and ipmi-sensors with driver type (-D LAN_2_0), the > > SDR cache generation freezes after some record and then gives the following > > error, 'ipmi_sdr_cache_create: internal IPMI error'. > > That's definitely not good. > > > After the error I can rerun the command with driver type LAN, and > > everything succeeds. From that point on I can use driver type LAN_2_0 again > > and everything will work fine. So it looks like that only SDR cache > > generation does not seem to work with LAN_2_0 driver. Just for testing I > > ran a similar command to read the SDR data using ipmitool and using > > ipmitool's equivalent of LAN_2_0 and everything seemed to work fine. > > > > I have observed this behavior on Dell PowerEdge R300, R610 and R710. And at > > every run the error will be generated after the same SDR record for each > > platform. Below are the errors for each one of those server types: > > Luckily, I have a PowerEdge R610 and I've reproduced the bug. I need to > figure this out, it's definitely odd. It does appear to be specific to > the Dell motherboards. I'm not sure what the issue is. > > Thanks for bringing it to my attention. I'll look into it and get back > to you. > > Al > > > > > > > R300 (DRAC5): > > > > -------------------------------- > > > > Caching SDR record 61 of 80 (current record ID 61) > > > > ipmi_sdr_cache_create: internal IPMI error > > > > -------------------------------- > > > > > > > > R610 (iDRAC): > > > > -------------------------------- > > > > Caching SDR record 58 of 124 (current record ID 58) > > > > ipmi_sdr_cache_create: internal IPMI error > > > > -------------------------------- > > > > > > > > R710 (iDRAC): > > > > -------------------------------- > > > > Caching SDR record 59 of 115 (current record ID 59) > > > > ipmi_sdr_cache_create: internal IPMI error > > > > -------------------------------- > > > > > > > > If you have a time and opportunity to look at this problem is there > > > > anything I can provide you with that will make this task easier? > > On Thu, 2010-02-11 at 15:47 -0800, Peter Bisroev wrote: > > Hello Albert, > > > > > > > > My name is Peter Bisroev and I am using the FreeIPMI package to monitor a > > > > number of DELL servers from a scripted environment. > > > > > > > > First of all let me thank you for the great work that you and other > > > > developers are doing, this is truly a very helpful tool. I was thinking of > > > > submitting this problem through the GNU FreeIPMI project bugs page but did > > > > not see any activity there so decided to mail you directly. I hope that > > > > that is OK. > > > > > > > > Now to the problem. When running ipmi-* tools that can generate SDR cache > > > > such as ipmimonitoring and ipmi-sensors with driver type (-D LAN_2_0), the > > > > SDR cache generation freezes after some record and then gives the following > > > > error, 'ipmi_sdr_cache_create: internal IPMI error'. > > > > > > > > After the error I can rerun the command with driver type LAN, and > > > > everything succeeds. From that point on I can use driver type LAN_2_0 again > > > > and everything will work fine. So it looks like that only SDR cache > > > > generation does not seem to work with LAN_2_0 driver. Just for testing I > > > > ran a similar command to read the SDR data using ipmitool and using > > > > ipmitool's equivalent of LAN_2_0 and everything seemed to work fine. > > > > > > > > I have observed this behavior on Dell PowerEdge R300, R610 and R710. And at > > > > every run the error will be generated after the same SDR record for each > > > > platform. Below are the errors for each one of those server types: > > > > > > > > R300 (DRAC5): > > > > -------------------------------- > > > > Caching SDR record 61 of 80 (current record ID 61) > > > > ipmi_sdr_cache_create: internal IPMI error > > > > -------------------------------- > > > > > > > > R610 (iDRAC): > > > > -------------------------------- > > > > Caching SDR record 58 of 124 (current record ID 58) > > > > ipmi_sdr_cache_create: internal IPMI error > > > > -------------------------------- > > > > > > > > R710 (iDRAC): > > > > -------------------------------- > > > > Caching SDR record 59 of 115 (current record ID 59) > > > > ipmi_sdr_cache_create: internal IPMI error > > > > -------------------------------- > > > > > > > > If you have a time and opportunity to look at this problem is there > > > > anything I can provide you with that will make this task easier? > > > > > > > > PS: I would be more than happy to submit a patch for the problem but my > > > > knowledge of IPMI protocol is almost non existent so that is not an option > > > > for the meantime. > > > > > > > > Thanks you. > > > > > > > > Best Regards, > > > > Peter > > > > -- Albert Chu [email protected] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/freeipmi-users
