OSDev.org

The Place to Start for Operating System Developers
It is currently Sat Aug 19, 2017 12:58 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: ACPI: Spurious SCI
PostPosted: Tue Feb 28, 2017 2:48 pm 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 283
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


Top
 Profile  
 
 Post subject: Re: ACPI: Spurious SCI
PostPosted: Wed Mar 01, 2017 8:39 am 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 161
Location: Ukraine, Bachmut
If Enable bit is not set, status bit set should not generate SCI.
Quote:
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.

_________________
future big goal: ANT - NT-like OS for mips, arm and x86 (and, possibly, ppc and itanium, hehehe).
current smaller goal: efify - UEFI for a couple of boards (mips and arm).


Top
 Profile  
 
 Post subject: Re: ACPI: Spurious SCI
PostPosted: Wed Mar 01, 2017 8:14 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8054
Location: At his keyboard!
Hi,

zaval wrote:
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: ACPI: Spurious SCI
PostPosted: Thu Mar 02, 2017 12:20 pm 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 283
Brendan wrote:
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.

Brendan wrote:
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!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot] and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group