[haiku-development] Re: bug 2084

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 17 Feb 2009 23:56:52 +0100

Michael Lotz wrote:
> They could then just always be 
> added to the very end of the interrupt handler list, meaning they won't 
> be able to steal interrupts from anyone.

If an interrupt handler cannot tell whether or not the interrupt was
generated by its device, it should always return B_UNHANDLED_INTERRUPT.
This is what the "fast" interrupt handler of the FreeBSD compatibility
layer already does; since FreeBSD 7 it could check the return value of
the interrupt handling function, though (it currently doesn't).

However, most FreeBSD drivers are using "slow" interrupts which means
the actual interrupt only triggers a task queue to be serviced.
This is where drivers ported to Haiku need to be more careful, and with
the current interrupt model, it might be impossible to port a driver
correctly due to this.

Basically, if the HAIKU_CHECK_DISABLE_INTERRUPTS() function is not
correctly implemented, it would cause a lock up with other interrupt
users (this could also be a FreeBSD compatibility driver, so having it
last is not really an option. I guess it would help if the
implementation of the HAIKU_CHECK_DISABLE_INTERRUPTS() function would
allow to return the proper value to return.
The other problem I see is that the PCI interrupt is acknowledged too
early (before the interrupt in the device was acknowledged), so that
another interrupt could be triggered due to that. Not sure this happens,
 but if that happens with a device, we couldn't properly port it right now.

I was thinking to overhaul the interrupt handling in the compatibility
layer at some point, but I didn't get around to actually do so. When I
finally get to port the "jme" driver to Haiku, I might have another look
at it.


Other related posts: