On Mon, 10 Dec 2001, Benjamin Herrenschmidt wrote:
While looking at the Heathrow.cpp code to compare with what I'm doing
in Linux (chasing a lost interrupt problem with the PMU that occurs
occasionally), I found something weird in the Darwin implementation.
Hey, Ben. At least it only occurs occasionally for you. In MkLinux, it's relatively easy to trigger. :-|
That gives on a wallstreet the NMI & cascade (second heathrow) beeing
edge (while the NMI is specifically level triggered on openpic machines
and that makes more sense to have it level triggered)
Not sure on the NMI.
, while all others
beeing edge (especially IDE disk interrupts which are usually known to
be level interrupts as the disk assert them until the status register
is read)
My gut is telling me that continuing to trigger interrupts until the status register is read could generate spurious interrupts that would cause performance problems. After all, clearing the interrupt bit happens in the interrupt context, but reading the status bit probably happens in a kernel thread. Just my gut.
There's also a typo in the code for handling lost interrupts which
uses the first level register in the code for checking the second
register set (I just posted a bug report about this).
Cough. Guess Darwin doesn't lose many interrupts or someone would have noticed this. :-)
Finally, the code og getVectorType() is confusing. It should probably
test the vector is in the range of the first register set before
doing (1 << vectorNumber) for completeness. The current code works
as long as (1 << X) with X >= 32 returns 0 but I did see compilers
optimizing this badly, so I feel this is dangerous coding.
I don't seem to have the Heathrow driver handy, but looking at the GC driver (which should be very similar, I hope), it's being &ed with kTypeLevelMask, which is a 32 bit quantity. How could that be non-zero? Later, David --------------------------------------------------------------------- Check out my weekly web comic: http://www.techmagazine.org