[haiku-development] Re: bug 2084

On Tue, Feb 17, 2009 at 8:19 PM, Michael Lotz <mmlr@xxxxxxxx> wrote:
>> 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
>
>

So might this also explain the complete freeze-ups I get on the AMD
Geode board?  It's got an RTL8139 network chip on it.  If I boot
without a USB mouse plugged in and then plug it in after it's running,
things seem to run fine, but if I plug it in before powering it up the
board only runs for a few minutes and then completely freezes up, even
blocking the f12 via a ps/2 connected keyboard.
-scottmc

Other related posts: