Messages in this thread | | | Subject | Re: enable_ioapic_irq broken in arch/i386/kernel/irq.c | From | Claus-Justus Heine <> | Date | 26 Apr 1998 17:40:49 +0200 |
| |
Linus Torvalds <torvalds@transmeta.com> writes:
> On 26 Apr 1998, Claus-Justus Heine wrote: > > > > Will check tomorrow, just too tired. For ftape it will most probably > > work fine. Only problem could be for dunno what driver/hardware > > combination that disable_irq() really discards interrupts. > > Yes. There's some #ifdef code there that should fix this, but it is
Yes, I saw it.
Mmmh. I'm writing this with a 2.1.98 + your irq patches running. So at least it seems not to be completely broken.
Recompilation of the kernel tree with "make -j" completed successfully.
> currently disabled because there seem to be some problems with it.
I'll next hack the /proc filesystem to give me some statistics about how often a disabled IRQ is ignored.
Instead of resending the IPI, couldn't we simply check each time an interrupt occurs whether there are other interrupts pending for previously disabled IRQs? At least the timer IRQ will occur sufficiently often.
Are there principal problems with resending the IPI, or are there just some obscure deadlocks where it isn't really clear where they come from?
I'll also check what happens if I dare to enable the "#if 0"-ed code.
BTW, I'm using a Gigabyte DLX mb with two PII/266. One scsi disk, one ide disk, ide cdrom, network adapter with de4x5 driver.
Claus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |