On Thu, 2 Feb 2006, Jack Vogel wrote: > 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? > > Jack > It's quite common for laptop motherboard makers to route lots of interrupts onto the same physical line. It saves a small fraction of a penny in costs. My last Dell notebook was that way, regardless of Windows, Linux, or FreeBSD. ScottReceived on Fri Feb 03 2006 - 00:05:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:51 UTC