[haiku-development] Re: bug 2084
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 17 Feb 2009 20:19:40
> Perhaps it's an interrupt flood, what does the "ints" kdl command
> say?
Yes it most certainly is an interrupt storm. And you don't really need
to investigate the problem as it's pretty easy to explain: The
interrupt is shared among both the USB controller and the network card.
Both drivers install interrupt handlers on the same line but the
network card happens to be "before" the USB one in the list of
interrupt handlers. As long as there is nothing going on on the USB
bus, nothing will happen, but USB devices (hooked up to that/those
controller(s) sharing the interrupt) just wouldn't work. Now there are
known problems in the FreeBSD compatibility layer regarding interrupts.
Those aren't really bugs, because indeed with drivers from FreeBSD < 7
there is no way to know if a certain driver has handled an interrupt or
not. Therefore in some cases this information will be returned back
incorrectly, leading to the compat layer telling the system the
interrupt is handled (and therefore stopping the interrupt handler
chain) even though it really isn't handled at all. The driver for which
the interrupt was originally intended (the USB host controller driver
in this case) doesn't get the chance to properly handle that interrupt,
meaning it won't ackowledge the interrupt on the hardware. Since now
the interrupt state is uncleared, as soon as the interrupt handler
returns, another interrupt will be triggered. This completely locks up
the system then (unless you'd happen to have more than one CPU where
it's possible that the system will continue to be more or less
responsive even though pretty resource constrained of course).
The reason for the difference in when you plug in the device is simple
as well: The reason plugging in a device triggers this problem at all
is that it'll cause state change interrupts. When the device is already
plugged in at boot, those will be properly handled, because the USB
stack and the host controller drivers are loaded very early (to enable
USB booting), before the network drivers are loaded that would cause
the problem.
The proper solution to this is to simply update the compat layer and
the drivers to FreeBSD 7 level, where the needed info should be
available. If I'm not mistaken there's been a mail to this list of
someone who already updated the compat layer and sent a patch. Another
solution, if we can't get this to work properly for some reason, would
be to add those interrupt handlers with a special flag to indicate that
they do not know the handled state. 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.
Regards
Michael
Other related posts:
