On Thu, 03 Apr 2008 16:30:18 -0800 Carol Hebert <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-04-03 at 15:29 -0700, Andrew Morton wrote: > > On Thu, 03 Apr 2008 17:09:48 -0500 > > Corey Minyard <[EMAIL PROTECTED]> wrote: > > > > > Carol Hebert wrote: > > > > Hi Corey, > > > > > > > > This patch does not appear to be in the 2.6.25-rc8 kernel although you > > > > sent it in to lkml over 6 weeks back. We were sort of expecting (and > > > > counting on) it to be included in the mainline kernel by now. Is there > > > > anything we can do to encourage the kernel folks to pull this patch in > > > > soon? > > > > > > > > Thank you very much for all your help, :-) > > > > > > > Well, we can try, but it might be a little late. > > > > > > Andrew, could we get this patch pushed to the mainstream kernel? > > > > > > > yes, but... > > > > > > > > > Carol Hebert > > > > > > > > On Wed, 2008-02-13 at 10:22 -0600, Corey Minyard wrote: > > > > > > > >> From: Carol Hebert <[EMAIL PROTECTED]> > > > >> > > > >> Currently, on systems with multiple BMC interfaces, the ipmi device > > > >> names are being created in reverse order relative to how they are > > > >> discovered on the system (e.g. on an IBM x3950 multinode server with N > > > >> nodes, the device name for the BMC in the first node is /dev/ipmiN-1 > > > >> and > > > >> the device name for the BMC in the last node is /dev/ipmi0, etc.). The > > > >> problem is caused by the list handling routines chosen in dmi_scan.c. > > > >> Using list_add() causes the multiple ipmi devices to be added to the > > > >> device list using a stack-paradigm and so the ipmi driver subsequently > > > >> pulls them off during initialization in LIFO order. This patch changes > > > >> the dmi_save_ipmi_device() list handling paradigm to a queue, thereby > > > >> allowing the ipmi driver to build the ipmi device names in the order in > > > > So the device nodes are enumerated in reverse order relative to their > > order-of-discovery. The changelog doesn't actually explain why this is a > > problem. It should do so. > > > > It sounds to me like someone has an expectation which is just unreasonable, > > and is fragile. But from this changelog, I just don't know what the problem > > is. > > > > It also appears that this change will cause breakage for all those people > > who are relying upon the existing enumeration scheme? > > > > 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!) > Also, if there is any software that people are using which depends on > historical ipmi device node order, it will break without this patch. > > Thank you very much for your help, > > Carol Hebert > ------------------------------------------------------------------------- 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
