Re: [Openipmi-developer] acpi_find_bmc() and acpi_get_table()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I"m not sure how close we are on this, but I'm getting ready to release the 2.6.22 version of the driver, and I'd really like to get this in for testing if possible. Jordan, do you have any idea on how long it will be before this is resolved?

-corey

Bjorn Helgaas wrote:
On Wednesday 18 July 2007 10:49:58 am Jordan_Hargrave@xxxxxxxx wrote:
I've done some more investigating on this and found why this works
in RHEL5 but not other releases (RHEL4/SLES9/SLES10).
The acpi motherboard driver is claiming all devices with _HID or
_CID of PNP0C01.  Our BIOS declares the IPI0001 with a _CID of
PNP0C01, so the acpi motherboard driver normally claims it.  When
the IPMI driver loads it can't find the IPI0001 device as it is
already claimed.

I think this is dumb.  PNP0C01 is a generic "system board" identifier
with no clear programming model that I can see.  What good does it
do to have a _CID of PNP0C01?  The only useful thing that happens in
Linux is that the "motherboard" driver claims PNP0C01 devices and
reserves their resources.  But PNP ought to reserve the resources of
*all* active devices, even if no driver claims them.

So I think this sounds like a BIOS defect.  Of course, I'm sure it's
already in the field, so even if we agree that it's a BIOS problem,
we'd have to work around it in Linux.  What if we had some sort of
quirk that removes that _CID?

In RHEL5 there was a change made to the acpi motherboard driver to
not attach if any of the _CRS values are not I/O ports.

Yes.  This is part of linux-2.6-x86_64-memory-hotplug.patch, and it
apparently helps fix a bug:
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208445,
But I can't read the bugzilla, so I don't know exactly how.  I suspect
some hot-addable memory device also had a _CID of PNP0C01, and they
had the same problem you now have with IPMI.

But making the motherboard driver ignore devices if they have any
non-I/O port resources seems like the wrong fix.

Technically the only reason it is working in RHEL5 is due to the
bug of the motherboard driver not attaching.

Right.  I'm sure you've noticed that the ACPI motherboard driver has
been removed completely upstream.  It's been replaced by the PNP
"system" driver, which claims all PNP0C01 and PNP0C02 devices regardless
of what sort of resources they have.

So using acpi_bus_register_driver looks like it won't work as a general solution.
I'm investigating walking the whole namespace to detect the IPI0001 device.

I think we should make acpi_bus_register_driver() work.  It looks like
we already have two cases (IPMI and memory hotplug), so I'd like to
have a general solution rather than a collection of workarounds.

Bjorn

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux