lkml.org 
[lkml]   [1998]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: IRQ Probing partially broken in 2.1.102


On Mon, 18 May 1998, mlord wrote:
>
> Something in patch-2.1.102 has caused IRQ probing
> to fail *sometimes* on my machine.
>
> The IDE driver probes ide1 for my tape drive (hdd)
> and fails the IRQ probe, while finding the drive.

I suspect that what is going on is that this will happen if there are any
previously pending interrupts on that interrupt, and it's a
level-triggered interrupt: the probe code will enable the interrupt but
immediately decide that it got a spurious interrupt due to an older
interrupt being pending.

Can you test whether the problem changes at all by adding this one-liner
to "probe_irq_on()":

for (i = NR_IRQS-1; i > 0; i--) {
if (!irq_desc[i].action) {
+ irq_desc[i].events = 0;
irq_desc[i].handler->enable(i);
irqs |= (1 << i);
}
}

which should hopefully make the kernel "forget" any old pending events.

There is still the possibility that the "pending" interrupt will have been
buffered by the hardware and that would also mark it spurious. But test
the above first, as it's the simplest fix I can think of, and it may be
sufficient.

We probably do need to have some way of handling shared interrupt probing
too. Right now the irq probe code simply cannot handle shared interrupts
at all, and it should be possible to handle those too without undue
problems (install a shared fake irq handler for all irq's etc).

Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.031 / U:1.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site