[haiku-development] Re: bug 2084

  • From: Peter Kerpedjiev <pkerpedjiev@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 17 Feb 2009 12:25:32 -0800

Michael Lotz 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.


You guys are both right. There's a ton of interrupts being handled on that line.

Thanks for the excellent explanation. I'll see if I can find the compat layer patch and try it out.


Other related posts: