acpi_find_bmc() and acpi_get_table()

Cory,
acpi_find_bmc() appears to be searching for multiple SPMI tables in the RSDT and running try_init_acpi() on each of them
until it doesn't find any more.

Is that the intent?

Are here systems with multiple SPMI tables?

static __devinit void acpi_find_bmc(void)

{
        acpi_status      status;
        struct SPMITable *spmi;
        int              i;

        if (acpi_disabled)
                return;

        if (acpi_failure)
                return;

        for (i = 0; ; i++) {
                status = acpi_get_table(ACPI_SIG_SPMI, i+1,
                                        (struct acpi_table_header **)&spmi);
                if (status != AE_OK)
                        return;

                try_init_acpi(spmi);
        }
}

I speculated recently that the only table signature
that is (supposed to be) repeated in the RSDT is an SSDT. Maybe that speculation is wrong if there can be multiple SPMI tables...

...the IPMI spec states that in the case
of multiple interfaces, a unique SPMI table should be provided for each of those interfaces. So the IPMI spec seems to require support more than one.

acpi_find_bmc() appears to be searching for multiple SPMI tables in the RSDT and running try_init_acpi() on each of them
until it doesn't find any more.

Quoted 4 lines · Len Brown

acpi_find_bmc() appears to be searching for multiple SPMI tables in the RSDT and running try_init_acpi() on each of them
until it doesn't find any more.

I can't remember why we look at the SPMI table(s) rather than registering a normal ACPI (or even PNP) driver. Unless we need to poke the BMC very early, wouldn't it be better to rely on the device description in the namespace?

Quoted 8 lines · Bjorn Helgaas

Quoted 5 lines · Len Brown

acpi_find_bmc() appears to be searching for multiple SPMI tables in the RSDT and running try_init_acpi() on each of them
until it doesn't find any more.

Quoted 5 lines

I can't remember why we look at the SPMI table(s) rather than registering a normal ACPI (or even PNP) driver. Unless we need to poke the BMC very early, wouldn't it be better to rely on the device description in the namespace?

For some strange reason the normal ACPI information does not have all the information needed by the driver. It doesn't have register size or spacing information.

Quoted 16 lines · Corey Minyard

Quoted 8 lines · Bjorn Helgaas

Quoted 5 lines · Len Brown

acpi_find_bmc() appears to be searching for multiple SPMI tables in the RSDT and running try_init_acpi() on each of them
until it doesn't find any more.

Quoted 6 lines

I can't remember why we look at the SPMI table(s) rather than registering a normal ACPI (or even PNP) driver. Unless we need to poke the BMC very early, wouldn't it be better to rely on the device description in the namespace?

Quoted 4 lines

For some strange reason the normal ACPI information does not have all the information needed by the driver. It doesn't have register size or spacing information.

I guess that would be a defect in the way ACPI is being used, wouldn't it? A PNP ID should define the device programming model, including things like register size and spacing. It sounds like somebody didn't define a new PNP ID when he should have. I wonder whether it's worth trying to fix this.

Bjorn
-

Quoted 21 lines · Bjorn Helgaas

Quoted 9 lines · Corey Minyard

Quoted 7 lines · Bjorn Helgaas

Quoted 5 lines · Len Brown

acpi_find_bmc() appears to be searching for multiple SPMI tables in the RSDT and running
try_init_acpi() on each of them
until it doesn't find any more.

Quoted 9 lines

Quoted 5 lines

I can't remember why we look at the SPMI table(s) rather than registering a normal ACPI (or even PNP) driver. Unless we need to poke the BMC very early, wouldn't it be better to rely on the device description in the namespace?

For some strange reason the normal ACPI information does not have all the information needed by the driver. It doesn't have register size or spacing information.

Quoted 7 lines

I guess that would be a defect in the way ACPI is being used, wouldn't it? A PNP ID should define the device programming model, including things like register size and spacing. It sounds like somebody didn't define a new PNP ID when he should have. I wonder whether it's worth trying to fix this.

Yes, it is considered an ACPI fault. Could you please describe in detail, which registers miss the information? And probably your acpidump will help as well.

Quoted 29 lines · Alexey Starikovskiy

Quoted 21 lines · Bjorn Helgaas

Quoted 9 lines · Corey Minyard

Quoted 7 lines · Bjorn Helgaas

Quoted 5 lines · Len Brown

acpi_find_bmc() appears to be searching for multiple SPMI tables in the RSDT and running
try_init_acpi() on each of them
until it doesn't find any more.

Quoted 9 lines

Quoted 5 lines

I can't remember why we look at the SPMI table(s) rather than registering a normal ACPI (or even PNP) driver. Unless we need to poke the BMC very early, wouldn't it be better to rely on the device description in the namespace?

For some strange reason the normal ACPI information does not have all the information needed by the driver. It doesn't have register size or spacing information.

Quoted 7 lines

I guess that would be a defect in the way ACPI is being used, wouldn't it? A PNP ID should define the device programming model, including things like register size and spacing. It sounds like somebody didn't define a new PNP ID when he should have. I wonder whether it's worth trying to fix this.

Quoted 3 lines

Yes, it is considered an ACPI fault. Could you please describe in detail, which registers miss the information? And probably your acpidump will help as well.

I don't have a machine with an ACPI description of the BMC. I'll copy the mailing list to see if anyone has an ACPI-described BMC.

I don't know that much about ACPI, so maybe that information is described somehow in a way the IPMI spec doesn't talk about directly, like in the _CRS object.

Quoted 29 lines · Alexey Starikovskiy

Quoted 21 lines · Bjorn Helgaas

Quoted 9 lines · Corey Minyard

Quoted 7 lines · Bjorn Helgaas

Quoted 5 lines · Len Brown

acpi_find_bmc() appears to be searching for multiple SPMI tables in the RSDT and running
try_init_acpi() on each of them
until it doesn't find any more.

Quoted 9 lines

Quoted 5 lines

I can't remember why we look at the SPMI table(s) rather than registering a normal ACPI (or even PNP) driver. Unless we need to poke the BMC very early, wouldn't it be better to rely on the device description in the namespace?

For some strange reason the normal ACPI information does not have all the information needed by the driver. It doesn't have register size or spacing information.

Quoted 7 lines

I guess that would be a defect in the way ACPI is being used, wouldn't it? A PNP ID should define the device programming model, including things like register size and spacing. It sounds like somebody didn't define a new PNP ID when he should have. I wonder whether it's worth trying to fix this.

Quoted 3 lines

Yes, it is considered an ACPI fault. Could you please describe in detail, which registers miss the information? And probably your acpidump will help as well.

I don't have a machine with an ACPI description of the BMC. I'll copy the mailing list to see if anyone has an ACPI-described BMC.

I don't know that much about ACPI, so maybe that information is described somehow in a way the IPMI spec doesn't talk about directly, like in the _CRS object.

Here is the patch (RHEL5 base code) I've been testing that detects the ACPI namespace object.

Here is the patch (RHEL5 base code) I've been testing that detects the ACPI namespace object.

Correct, the parseresource code really should look for IRQ/MEM, but I haven't yet seen any ACPI namespaces that use memory or IRQ resources with IPI0001 for testing. (I have a huge collection of DSDTs from my OpenBSD work).

Corey,

Here is the patch (RHEL5 base code) I've been testing that detects the ACPI namespace object.
The IPI0001 device doesn't contain the register spacing directly; it has a _CRS resource object that
(for KCS) has two I/O port entries. I save the first port in io.addr_data, then calculate the register spacing based on subtracting the 2nd port address and the 1st.

I'm thinking of changing the register spacing to using an array of port/memory addresses to make calculating interface addresses more generic.

eg.
static unsigned char port_inb(struct si_sm_io *io, unsigned int offset)

{
        unsigned int addr = io->addr_data;

        return inb(addr + (offset * io->regspacing));
}

would become something like:
static unsigned char port_inb(struct si_sm_io *io, unsigned int offset)

{
        unsigned int addr = io->addr_data[offset];

        return inb(addr);
}

--jordan hargrave
Dell Enterprise Linux Engineering

Corey,

Here is the patch (RHEL5 base code) I've been testing that detects the ACPI namespace object.
The IPI0001 device doesn't contain the register spacing directly; it has a _CRS resource object that
(for KCS) has two I/O port entries. I save the first port in io.addr_data, then calculate the register spacing based on subtracting the 2nd port address and the 1st.

I'm thinking of changing the register spacing to using an array of port/memory addresses to make calculating interface addresses more generic.

eg.
static unsigned char port_inb(struct si_sm_io *io, unsigned int offset)

{
        unsigned int addr = io->addr_data;

        return inb(addr + (offset * io->regspacing));
}

would become something like:
static unsigned char port_inb(struct si_sm_io *io, unsigned int offset)

{
        unsigned int addr = io->addr_data[offset];

        return inb(addr);
}

--jordan hargrave
Dell Enterprise Linux Engineering

The reason for the acpi_bus_register/unregister is to get the handle of the IPMI ACPI object. There isn't a way to get the device handle otherwise. Once it gets the handle it doesn't need the ACPI device anymore.

Quoted 5 lines · On Wednesday 28 February 2007 15:05, [email protected] wrote:

The reason for the acpi_bus_register/unregister is to get the handle of the IPMI ACPI object. There isn't a way to get the device handle otherwise. Once it gets the handle it doesn't need the ACPI device anymore.

Well, but in a world of truth and beauty, we should treat the interface as an ACPI device, and we really should only be using it after acpi_ipmi_add() and before acpi_ipmi_remove(). So that implies that we shouldn't call acpi_bus_unregister_driver() until we're ready to unload the driver.

I have no idea how multiple IPMI devices should be handled. But some HP systems have several, and I think they can be hot-added and removed.

Here is the patch (RHEL5 base code) I've been testing that detects the ACPI namespace object.
The IPI0001 device doesn't contain the register spacing directly; it has a _CRS resource object that
(for KCS) has two I/O port entries. I save the first port in io.addr_data, then calculate the register spacing based on subtracting the 2nd port address and the 1st.

Quoted 4 lines · On Monday 26 February 2007 11:30, [email protected] wrote:

Here is the patch (RHEL5 base code) I've been testing that detects the ACPI namespace object.
The IPI0001 device doesn't contain the register spacing directly; it has a _CRS resource object that
(for KCS) has two I/O port entries. I save the first port in io.addr_data, then calculate the register spacing based on subtracting the 2nd port address and the 1st.

Whatever happened with this patch? I think we should pursue it, but I don't see it in -mm.

Bjorn

Quoted 7 lines · Bjorn Helgaas

Quoted 4 lines · On Monday 26 February 2007 11:30, [email protected] wrote:

Here is the patch (RHEL5 base code) I've been testing that detects the ACPI namespace object.
The IPI0001 device doesn't contain the register spacing directly; it has a _CRS resource object that
(for KCS) has two I/O port entries. I save the first port in io.addr_data, then calculate the register spacing based on subtracting the 2nd port address and the 1st.

Quoted 5 lines

Whatever happened with this patch? I think we should pursue it, but I don't see it in -mm.

Bjorn

Sorry, I was under the impression that more work was required here dealing with the irqs. Is that not the case?

Quoted 29 lines · Alexey Starikovskiy

Quoted 21 lines · Bjorn Helgaas

Quoted 9 lines · Corey Minyard

Quoted 7 lines · Bjorn Helgaas

Quoted 5 lines · Len Brown

acpi_find_bmc() appears to be searching for multiple SPMI tables in the RSDT and running
try_init_acpi() on each of them
until it doesn't find any more.

Quoted 9 lines

Quoted 5 lines

I can't remember why we look at the SPMI table(s) rather than registering a normal ACPI (or even PNP) driver. Unless we need to poke the BMC very early, wouldn't it be better to rely on the device description in the namespace?

For some strange reason the normal ACPI information does not have all the information needed by the driver. It doesn't have register size or spacing information.

Quoted 7 lines

I guess that would be a defect in the way ACPI is being used, wouldn't it? A PNP ID should define the device programming model, including things like register size and spacing. It sounds like somebody didn't define a new PNP ID when he should have. I wonder whether it's worth trying to fix this.

Quoted 3 lines

Yes, it is considered an ACPI fault. Could you please describe in detail, which registers miss the information? And probably your acpidump will help as well.

I don't have a machine with an ACPI description of the BMC. I'll copy the mailing list to see if anyone has an ACPI-described BMC.

I don't know that much about ACPI, so maybe that information is described somehow in a way the IPMI spec doesn't talk about directly, like in the _CRS object.

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.

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.

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

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.

From Bjorn:

Quoted 2 lines

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.

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.

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.

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

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.

From Bjorn:

Quoted 9 lines

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 9 lines · On Wednesday 18 July 2007 10:49:58 am [email protected] 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?

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 3 lines

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

From Bjorn:

Quoted 9 lines

Quoted 2 lines

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.

Quoted 2 lines

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.