On Fri, 2006-11-17 at 09:53 -0600, Corey Minyard wrote: > > oopses (appended below). Does this patch require one or more of the > > other patches in the 39.1 set to be happy (for instance, the > > allow-hot-smi-remove patch), or am I running into some other issue? > > > I looked at this yesterday and today, I cannot figure out what would be > different between the two scenarios. I could not reproduce this, and > it's probably best to just take all the patches as that is what I > tested. I did test different loading orders in my testing. > > I'll try to look at this again today.
I totally agree that it would be best to use all the patches rather than to just pull out a few of them and I would always prefer to do that but in the case of the particular scenario/issue I'm currently working on, it won't be possible in the near-term. :-( I did try loading the ipmi-allow-hot-smi-remove patch along with the other 4 patches I listed and it did seem to fix the driver-load-order oops. Is that a stand-alone patch or are there others in the set that need to be loaded along with it? I ran some tests with this new 5-patch subset and didn't find any problems but my testing wasn't exhaustive so I'm hoping to verify that grabbing only these 5 alone won't introduce some other issue in some area I didn't touch in my testing. > > I got a bit of info about the order in which the SMBIOS table is > > populated and found out that it's currently populated in order of > > increasing KCS I/O address but that this isn't necessarily an ordering > > scheme that can be assumed for the future. Also, regarding changing the > > BIOS to make the deviceID unique across BMCs, I was told that if these > > changes were made, we would likely be facing many issues such as > > DeviceID mismatches with what's coded up in the SDR data, etc. So I > > suspect it's something that might not happen anytime soon (if ever). > > > That really doesn't make any sense. The only place I could find where > this Device ID is used is in the type 13 SDR: "Management Controller > Confirmation Record". This record is used by utility software to record > that it found a specific management controller in the system. It seems > of limited value to me, anyway, and having different device IDs would > seem to make this easier, not harder, to identify the different > management controllers. From what I can tell, the use of this is for > system software to record the current management controller > configuration. Then if system software finds something different, it > can say "Hey, something changed" and handle it. > > Note that the term "Device ID" is heavily overloaded in the IPMI spec. > It also has "FRU Device ID" and "Device ID String", but those are > completely different things. > > I see no other reliable mechanism to correlate management controllers > with nodes, especially if nodes ever become dynamic. I really doubt you > will have any issues unless you have software that is hardcoded to > handle this. That doesn't seem so, since they are all the same and it > doesn't provide any real useful information. Perhaps the group doing > the work can suggest a reliable way to correlate the nodes and the > management controllers? > Thanks very much for your input on this. I'll take what you've said back to the BIOS folks and re-open the discussion. :-) Thank you very much again for your ongoing and excellent help. :-) Carol ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
