Hi Corey,
There seems to be an issue with the creation of ipmi device nodes on
multinode systems in which the nodes are being created in the reverse
order of how they are found on the system (e.g. the BMC in the last node
of a multinode stack ends up being /dev/ipmi0, etc.). This is causing
quite a bit of confusion to both applications as well as users who are
attempting to communicate with specific BMCs in multinode systems.
It appears the issue is in 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 when the ipmi calls
dmi_find_device, the ipmi devices are peeled off the list in this
last-in, first-out order. Changing the list_add() in
dmi_save_ipmi_device() to a list_add_tail() changes the list paradigm to
a queue and fixes the device order/naming issue. It might make sense
to similarly change the other calls to list_add() in dmi_scan.c as well.
Anyway, I'm attaching a one-line patch that addresses just the ipmi
device issue (2.6.23 kernel). If you think this issue should be handled
in a different way, please let me know what other approach you'd like me
to try.
Thank you very much, :-)
Carol Hebert
----------------------------
--- dmi_scan.c.orig 2007-10-09 13:31:38.000000000 -0700
+++ dmi_scan.c 2008-01-18 10:24:17.000000000 -0800
@@ -217,7 +217,7 @@
dev->name = "IPMI controller";
dev->device_data = data;
- list_add(&dev->list, &dmi_devices);
+ list_add_tail(&dev->list, &dmi_devices);
}
/*
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
