On Thursday 19 July 2007 10:32:11 am Jordan_Hargrave@xxxxxxxx wrote: > From Bjorn: > >> 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. > > Yeah but it gets even better, that bugfix has a bug itself.. the acpi_walk_resources > function also passes the end-of-list (79 00) marker into the callback. This isn't a > resource I/O type, so the motherboard object is failing to attach to any PNP0C01 > device. This is why the IPMI driver can find the IPI0001 device on RHEL5 but not on > RHEL4/SLES10/SLES9. Beginning with 2.6.16, acpi_walk_resources() passes the end tag to the callback. We had a little discussion about this in January, 2006: http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg00117.html The conclusion was that the callback must be able to handle any resource type (ignoring ones it doesn't know about), so it should be harmless and potentially useful to pass the end tag to the callback. RHEL4/SLES10/SLES9 do this correctly (they ignore unknown resource types and claim PNP0C01 devices, which prevents the IPMI driver from claiming IPI0001 devices that have PNP0C01 _CIDs). RHEL5 is broken (bombs out on unknown resource types and fails to claim PNP0C01 devices, which happens to make the IPMI driver claim work). 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
