Eric J. Bowersox wrote: > On Fri, 2008-11-07 at 15:42 -0600, Corey Minyard wrote: > >> Maybe you are connecting to a different system over the LAN. The >> easiest way to tell for sure would be to use the GUID, if your system >> supports that. >> > > I modified my test program to get the GUID from the domain and display > it. Accessing it from both LAN and SMI returns the GUID > 020000ff-fe00-0000-0809-0a0b0c0d0e0f. While this is good--the return is > the same--it leads me to think the GUID either needs to be configured, > or has just been defaulted by the manufacturer. > Hmm. If you have connected with OpenIPMI with another system with the same GUID, it's going to use the other system's information from its local database. Remove ~/.OpenIPMI_db and see if that makes a difference.
GUIDs are *supposed* to be unique, but like you said, the one you have looks fairly suspicious. > But I think I'm accessing the same BMC. It was all set up by our other > engineers; the system is sitting in our assembly area right now. > They've told me what the IP address of that BMC is, and I have no reason > to think it's anything other than advertised. > > >> It's a bug in the OpenIPMI. I kind of doubt it, though, it's layered >> and the access type shouldn't really matter. But you could try ipmitool >> to double-check this possibility. >> > > Using ipmi-sensors from the FreeIPMI toolkit gives more reasonable > values (CPU temperatures of 24 and 21 degrees, system temperature of > 43). Using ipmitool directly on the node returns similar values. > > >> It's a bug in the BMC. Knowing BMC implementations, this is a possibility. >> > > Given that this is the same BMC that had the network issue for which you > gave me that one patch already, I have ZERO trouble believing this. The > trouble is convincing my boss. :-) > > I don't know if it's related, but, when accessing the > "new" (problematic) node with my test program, there's a lot less delay > in bringing the domain "up" than there is when I access a different node > (that gives more reasonable values). Could this be a clue? I can try > to get numbers on that if you need them. > Ah, yes. That's a big clue that my previous suggestion will help. OpenIPMI will cache data locally and only fetch it if it has changed. It tells different systems apart using the GUID. It tells if it has change by the timestamp on the data. I suspect that both of those are broken. -corey > Eric > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ------------------------------------------------------------------------ > > _______________________________________________ > Openipmi-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openipmi-developer > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
