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. 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
