Carol Hebert wrote: > Hi Corey, > > I wanted to let you know about some of the testing I've done with some > of the new 39.1 patches and also to ask you about an issue I found. > > First, I wanted to ask you about the ipmi-remove-device-interface-limits > patch. It seems that when I have this patch loaded (along with just the > 3 multinode fix patches listed below), the drivers work fine if ipmi_si > is loaded last, but if ipmi_si loaded before ipmi_devintf, the system > 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. > Also, I wanted to let you know that I was able to get some time on an > 8-way node and tested the following 39.1 patches: > ipmi-fix-device-model-name.patch, > ipmi-remove-interface-number-limits.patch > ipmi-handle-sysfs-errors.patch > ipmi-pass-sysfs-name-from-lower-level-driver.patch > > They seemed to work fine (with the drivers loaded in the "good" order > described above). All 8 device nodes were created and seemed to be > equally usable. > Ok, thanks. > 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 -Corey ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
