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