On Fri, Jul 27, 2007 at 11:12:48AM -0400, Jeff Garzik wrote: > Matthew Wilcox wrote: > >On Fri, Jul 27, 2007 at 10:57:16AM -0400, Jeff Garzik wrote: > >>Matthew Wilcox wrote: > >>>On Fri, Jul 27, 2007 at 10:49:17AM -0400, Jeff Garzik wrote: > >>>>I thought you had multiple scsi hosts per board? Thus multiple scsi > >>>>hosts per interrupt? > >>>Right. We'll request the interrupt twice, each time with a different > >>>scsi_host. > >>ewwwwww. That's, um, broken :) > >> > >>I presume request_irq() will fail on non-ISA for subsequent calls, and > >>your interrupt handler gets called -twice- for every single interrupt. > > > >I don't have any of these boards, so I may be labouring under a false > >apprehension here. It seems that PCI cards with multiple hosts are > >actually one host per function (ie just like sym2, and dissimilar to > >aic7xyz). With EISA, we set IRQF_SHARED, so we can request the same > >interrupt twice, each time with a different Scsi_Host. I think the VLB > >card is probably stuffed -- need to set IRQF_SHARED for that case. > > We need an ancient-hardware expert here. To say the least, this is > abuse of request_irq() and highly irregular. I wound not count on this > highly unusual behavior working at all. I don't see why. request_irq is entirely a software notion; if we choose to have two handlers for one physical device, that should be fine. > At the very least, it violates the Principle of Least Surprise and IMO > should not be done this way at all. > > Yuck, yuck, yuck. It's a high-overhead, highly fragile hack that no one > else would ever do. > > Note I never said 'NAK' with any patches, but I have to NAK this change. I still say it's an improvement over scanning the list of scsi hosts looking for any that have work pending whenever any interrupt comes in. -- "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
