Hi Corey, > So now that that information is dynamic, why not make guid and > channel information dynamic, too? It could theoretically > change, even though guid is not supposed to, it could be > added in a new firmware version. > > I fixed the locking problem you found by using memory barriers > and temporary holding places instead of locks. > > So as I kept finding things, I kept fixing things and it went > on and on until I got to 20 patches. And getting all the > locking right was a big pain. > > Some of these are not strictly necessary for you, they are > fixes for other things I found on the way. And the conversion > to guid_t probably doesn't matter to you, unless you want a > correct guid reported in the BMC.
I've given these patches a spin on our machines (using the powernv SI driver), and all looks good. Thanks for your (re)work on those! The periodic GUID refresh is a little unexpected - but as long as it can handle the BMC disappearing temporarily (say, during BMC reboot), then we should be okay. This would probably be justification for us removing some level of IPMI logging in OPAL firmware, as we'd now be seeing continued IPMI transactions in stable operation. Perhaps something to look at later would be to allow the SI driver to notify when to requery the BMC. Regardless, I'm happy with the series as is, and seems to work well. Tested-by: Jeremy Kerr <j...@ozlabs.org> Cheers, Jeremy ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
