I have recently had a problem with the fdomain driver initialisation and
have found the problem to be the way in which it requests the irq. Here is
my patch that has so far work ok.
--- linux/drivers/scsi/fdomain.c Thu Jul 5 13:35:41 2001
+++ fdomain.c Thu Jun 28 08:08:03 2001
@@ -981,8 +981,8 @@
} else {
/* Register the IRQ with the kernel */
- retcode = request_irq( interrupt_level,
- do_fdomain_16x0_intr, 0, "fdomain", NULL);
+ retcode = request_irq( shpnt->irq,
+ do_fdomain_16x0_intr, SA_SHIRQ, "fdomain", shpnt);
if (retcode < 0) {
if (retcode == -EINVAL) {
Hope this is correct.
Regards
Grant Fribbens
> I have recently had a problem with the fdomain driver initialisation and
> have found the problem to be the way in which it requests the irq. Here is
> my patch that has so far work ok.
I've seen this patch before. It needs at least one change
> - do_fdomain_16x0_intr, 0, "fdomain", NULL);
> + retcode = request_irq( shpnt->irq,
> + do_fdomain_16x0_intr, SA_SHIRQ, "fdomain", shpnt);
Only set SA_SHIRQ if PCI - say -
pdev?SA_SHIRQ:0
The other problem is that the code doesnt have support for handling IRQ
source checking, so if the line it shares with generates interrupts we might
sometimes do the right thing
I have a long outstanding request with adaptec (who bought future domain)
for the info needed to fix this, but obviously its a dead product, from a
bought company and hardly on their priorities.
I suspect the IRQ handler needs to either
A. Check bit 0 of the status port and return
B. Check bit 4 or bit 9 of the interrupt control register
Without docs someone would need to play with the various combinations and
see what happened
On Thu, Jul 05, 2001 at 07:16:26PM +0100, Alan Cox wrote:
> > I have recently had a problem with the fdomain driver initialisation and
> > have found the problem to be the way in which it requests the irq. Here is
> > my patch that has so far work ok.
>
> I've seen this patch before. It needs at least one change
>
> > - do_fdomain_16x0_intr, 0, "fdomain", NULL);
> > + retcode = request_irq( shpnt->irq,
> > + do_fdomain_16x0_intr, SA_SHIRQ, "fdomain", shpnt);
>
> Only set SA_SHIRQ if PCI - say -
>
> pdev?SA_SHIRQ:0
>
> The other problem is that the code doesnt have support for handling IRQ
> source checking, so if the line it shares with generates interrupts we might
> sometimes do the right thing
>
> I have a long outstanding request with adaptec (who bought future domain)
> for the info needed to fix this, but obviously its a dead product, from a
> bought company and hardly on their priorities.
>
> I suspect the IRQ handler needs to either
>
> A. Check bit 0 of the status port and return
>
> B. Check bit 4 or bit 9 of the interrupt control register
>
> Without docs someone would need to play with the various combinations and
> see what happened
Uhmmm, an idea would be to look in fd_mcs.c as that driver already has
working support for irq-sharing.
/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
> > A. Check bit 0 of the status port and return
> >
> > B. Check bit 4 or bit 9 of the interrupt control register
> >
> > Without docs someone would need to play with the various combinations and
> > see what happened
>
> Uhmmm, an idea would be to look in fd_mcs.c as that driver already has
> working support for irq-sharing.
Doh.
Ok that indeed shows you check bit 0 if the status port.
Right I'll add shared IRQ support to that driver