On Thu, 2008-04-03 at 21:33 -0500, Corey Minyard wrote: > Andrew Morton wrote: > > On Thu, 03 Apr 2008 16:30:18 -0800 Carol Hebert <[EMAIL PROTECTED]> wrote: > > > > > >> Hi, > >> > >> This reverse enumeration scheme is actually different from how the ipmi > >> driver has worked in the past. The BMCs in multinode systems were > >> historically named by the ipmi driver in the order in which they were > >> probed. As such, current multinode users are expecting ipmi0 to > >> reference the BMC in their first node, ipmi1 to reference the BMC in > >> their second node, etc. as was always the case in the past. Without > >> this patch, they will unknowingly be addressing the wrong BMC. This > >> could conceivably cause operations to be erroneously executed that could > >> result in data loss, etc. > >> > > > > In which kernel version did this behavioural change occur? > > > > (this is a hard way to write a changelog!) > > > The change occurred in 2.6.14, when the DMI scanning was moved out of > the IPMI driver and into the DMI code. So it's been a while. > > But the trouble is, no one cared since no one had more than one IPMI > controller in a system. But now IBM has come up with the machines with > a boatload of them. As far as I know, that IBM machine is the only one > that will care. > > IMHO, the best way to handle this is to use udev to properly name the > devices. That was not an option for Carol, though. And having them in > the opposite order of the firmware violates the principle of least > surprise. So I went ahead and took the patch. > > -corey
Hi Corey, Thank you very much for the info on the timing of the 2.6.14 dmi code change. :-) Although the list_add call in the dmi code originates from the 2.6.14 kernel, I seem to believe that the issue with the reverse naming started more recently -- namely that it began when the ipmi driver interfaces changed from an array table to a linked list. I may be totally wrong (it's been a couple of months since I looked at that code), but I thought I remembered that the array table set the ipmi interfaces in the table in probe order but that the new(er) ipmi linked list interface allowed the dmi code's stack-type paradigm to cause a reversal of the interface naming order. I'll try to find code to back up (or negate) what I'm saying -- or maybe you can answer the question right off? Either way, thank you very much for all your help, --Carol ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
