ACPI: Spurious SCI

[Korona]

Hi,

I'm currently testing my OS on some ICH7 computer and I get a spurious SCI as soon as I enter ACPI mode. That is something that I don't see on other platforms. Has anyone ever encountered the same situation and knows how to fix/handle this?

Some information:

• SCI is routed to IRQ 9 which is identically mapped by level-triggered active-high. This is expected and matches the ICH documentation.
• I'm using the I/O APIC that has IRQ 9 programmed to exactly that configuration.
• No other device shares the IRQ 9 line.
• No GPE or fixed event enable bit is set when the IRQ fires.
• If I just ack the SCI everything continues as expected. It does not stay high after assertion. Later SCIs (e.g. the power button) work as expected.
• The whole code is based on ACPICA.

I'm 99% sure that this is a bug in my code but I'm not sure what I'm doing wrong.

Thanks,
Alexander

[zaval]

If Enable bit is not set, status bit set should not generate SCI.

Also, the enable bit has no effect on the setting or resetting
of the status bit; it only determines if the SET status bit will
generate an “Event Output,” which generates an SCI when set if
its enable bit is set.

Status bit is set by hardware, software can only clear it (sticky bit). SCI should only be generated
if both are set. It looks more like a hardware inconsistency.

[Brendan]

Hi,

Status bit is set by hardware, software can only clear it (sticky bit). SCI should only be generated
if both are set. It looks more like a hardware inconsistency.

I agree; but only if other possible causes have been ruled out.

My first guess was that the IO APIC (or PIC?) wasn't configured correctly (e.g. SCI configured as "level-triggered active-high" when it's supposed to be something else); but I looked into that yesterday and found that "level-triggered active-high" is correct (according to Intel's ICH7 datasheet).

My second guess would be some form of race condition. For example; installing the SCI handler and enabling the IRQ in the PIC or IO APIC before the chipset/motherboard has disabled its SMI (before or after "ACPI_ENABLE" is sent to "SMI_CMD"); causing whatever triggered the event to be handled by firmware's SMM code before the operating system's SCI handler is started.


Cheers,

Brendan

[Korona]

My first guess was that the IO APIC (or PIC?) wasn't configured correctly (e.g. SCI configured as "level-triggered active-high" when it's supposed to be something else); but I looked into that yesterday and found that "level-triggered active-high" is correct (according to Intel's ICH7 datasheet).

Level-triggered active-high is indeed a strange configuration because the XT PIC does not support this configuration at all. However I guess the ICH does a traditional PIC in hardware anyways and just emulates the register interface to software so that does not matter.

My second guess would be some form of race condition. For example; installing the SCI handler and enabling the IRQ in the PIC or IO APIC before the chipset/motherboard has disabled its SMI (before or after "ACPI_ENABLE" is sent to "SMI_CMD"); causing whatever triggered the event to be handled by firmware's SMM code before the operating system's SCI handler is started.

It turns out that this was indeed the case. The SCI had nothing to do with ACPI_ENABLE; it also happens if I do not switch to ACPI mode at all. The sequence of events was

Disable interrupts => Unmask I/O APIC => Some time passes => IRQ 9 level is asserted (probably by the PM timer or some SMI/TCO/whatever stuff?) => Enable ACPI => Enable Interrupts => IRQ 9 is delivered to the CPU

when I move the unmask after ACPI_ENABLE no IRQ is raised (i.e. the IRQ is swallowed by the masked APIC).

The behavior is strange because I don't remember ever getting random IRQs when I used the XT PIC. However my current kernel only supports the I/O APIC so I cannot verify that. I guess I'll have to implement XT PIC support in order to further investigate that issue.

Thanks for your comments!