> Why do you need to fiddle with the 8259A's IMR at all? What's wrong with
> cli?
Only Phoenix developers can answer this.
In principle not even cli is necessary because, all interrupts are
automatically disabled upon entry into SMM mode. The bios does mask
the PIC, though, probably because it is possible for SMI handlers to
reenable interrupts while in SMM mode. AFAIK, our BIOS does _not_
include such handlers, but Phoenix seems to have put in that code
so that it is possible to write them if desired. It appears that the
Phoenix programmers overlooked the fact that the PIC might be in poll
mode when they try to read the IMR. Our Bios people are trying to
contact Phoenix about this.
> The current code is correct, written to 8259A's specs. I used original
> ones ("8259A Programmable Interrupt Controller (8259A/8259A-2)", Intel's
> order number 231468) as a reference to assure whatever happens is
> well-specified and not an implementation-specific quirk. The SMI code is
> broken for not being transparent (or for existing at all, but that's
> another matter).
Can you tell me how the SMI code could correctly transparently reestablish
the 8259A state in the situation we are facing?
I can't think of an algorithm that would put the PIC in exactly the same
state that it was in before the SMI, not to talk about the time elapsed
during SMI, which easily comes up to a few 100 us on our system.
> That's not the normal mode -- that's the through-8259A mode workaround
> designed originally for i82357 (ISP) based EISA systems. The chip
> predates the APIC and does not make IRQ 0 from its internal 8254 core
> available externally. I am actually very surprised to see new systems not
> connecting IRQ 0 to the I/O APIC.
Oops - I will contact our hardware guys about this.
Thanks for your comments,
Martin
-- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/