On 2/2/06, Julian Elischer <julian_at_elischer.org> wrote: > > the big "workaround" that may save lives would be to have a "storm > detection" that detects that > an interrupt is not being reset, say, by noticing that the same > interrupt has fired 32 times without > ever giving the system a chance to even get out of the interrupt > handling layer, > and then on detection call the interrupt routine sof EVERY DRIVER that > is registerred > for interrupts. > > I have done similar to this on one of our machines where the redirected > interrupt is being sent > to the interrupt used by em4, when em0 gets delayed. > > My solution for this embedded hardware is to add a hack so that when em4 > gets an interrupt and there > isn't one, it goes and services all the other em devices as well. > (remember this is for a particular hardware config so I can use > non-general solutions).. > > Another way to achieve this would be to have a special driver that you > register on the 'target' > interrupt, that when run, calls the correct interrupt handlers :-) > you could have a kernel module that you compile up with the correct two > interrupts in it > and on loading it would do the trick.. I have a feeling that the real fix is something down in the bottom half of the kernel where interrupt routing is set up. I think something is wonky down there on some new chip sets, but I'm not sure without more research. Anyone else looking at that perhaps? JackReceived on Fri Feb 03 2006 - 00:01:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:51 UTC