I have made a few observations in the past few days:
1) Unique IPMI device ID's did not seem to make a difference.
Stratus still could not hot remove one of the KCS interfaces.
2) From what I see in IPMI spec section 20.1, having unique
device ID's is not required:
Controllers that
Well, the built-in driver works on systems that have more than one interface
and more than one BMC, and multiple IPMBs (and all of the other channel
types for that matter, and the driver handles all the multiplexing and nasty
addressing). There is, in fact, no arbitrary limit, and IBM tested
On 12/14/2012 10:25 AM, Evans, Robert wrote:
Corey,
Thanks for the thoughtful reply. Below I respond in detail to
these three points.
1) Why building a variant kernel with ipmi_si as a module is not
feasible.
2) User mode access to IPMI on Stratus systems (e.g. ipmitool).
3) ipmi_si hot
RHEL builds the ipmi_si into the kernel by default, rather than as a
module, because it is required early in order to be available for ACPI
opregion access. However, it appears that some of our customers have
custom ipmi drivers, and this gets in their way.
Stratus is currently evaluating your
Original Message
Subject: Re: [PATCH] ipmi: add new kernel options to prevent automatic
ipmi init
Date: Thu, 13 Dec 2012 13:51:23 -0600
From: Corey Minyard tcminy...@gmail.com
Reply-To: miny...@acm.org
To: Tony Camuso tcam...@redhat.com
CC: devicetree-discuss@lists.ozlabs.org
On 12/14/2012 12:02 PM, Corey Minyard wrote:
On 12/14/2012 10:25 AM, Evans, Robert wrote:
Corey,
Thanks for the thoughtful reply. Below I respond in detail to
these three points.
1) Why building a variant kernel with ipmi_si as a module is not
feasible.
2) User mode access to IPMI on
