Date: Mon, 20 Mar 1995 18:08:18 -0800 From: "Justin T. Gibbs" <gibbs@estienne.CS.Berkeley.EDU> To: se@MI.Uni-Koeln.DE (Stefan Esser) Cc: current@FreeBSD.org Subject: Re: Sharing interrupts with PCI devices? Message-ID: <199503210208.SAA02500@estienne.cs.berkeley.edu> In-Reply-To: Your message of "Tue, 21 Mar 1995 01:16:56 %2B0100." <199503210016.AA05446@FileServ1.MI.Uni-Koeln.DE>
next in thread | previous in thread | raw e-mail | index | archive | help
>On Mar 18, 11:43, "Justin T. Gibbs" wrote: >} Subject: Re: Sharing interrupts with PCI devices? > >} >Shared interrupts are a requirement for >} >PCI, if you want to deal with 4 channel >} >Ethernet cards, or with PCI to PCI bridges >} >in general. >} > >} >The PCI shared interrupt code can be >} >implemented architecture independent (i.e. >} >is not bound to PC compatible hardware), >} >while moving that code into the ISA tree >} >means it sure can't be used for other >} >machines with PCI bus, and will have to >} >be reimplemented. >} > >} >I can live without shared ISA interrupts, >} >but we need them for PCI. >} >} I don't see why the two are mutually exclusive. I'd like >} to be able to share EISA interrrupts too. > >Yes, nothing keeps you from adding >this for EISA devices ... > >In fact, the PCI interrupt sharing >will probably be directly applicable >to EISA devices, too. > >The only new requirement is, that the >interrupt handler returns '0' in case >that device didn't cause the interrupt, >a '1' if it did ... > >We don't have any EISA system to test >this on, but the PCI interrupt code >will use a two layer approach: > >1) If only one interrupt is assigned to > some IRQ, then the current code will > be used. > >2) If interrupts are shared, then there > is a generic handler, which will call > each the handler for each device, after > masking those device classes interrupts. > (I.e. IRQ9 is used for DEC Ethernet and > NCR SCSI: The 'ed' handler will be called > with netmask, the NCR handler with biomask > applied.) > >This results in low overhead operation >in the non shared case, and in interrupts >masked for as short a period of time as >possible in the shared case. > >*** *** *** *** *** *** *** *** *** *** *** > >I will apply the PCI SHARED INTERRUPT patch >tomorrow. All PCI device drivers will have >been checked to conform to the return value >convention described above ! > >EISA devices will work with shared interrupts, >too, if their drivers are patched accordingly. >Somebody else will have to patch their interrupt >handlers and write some simple eisa_map_int() >function, similar to the NEW pci_map_int(), that >I'm going commit to -current tomorrow. > >*** *** *** *** *** *** *** *** *** *** *** > >} >If both your AIC devices are mapped >} >to use IRQ 10 (you are using the >} >pci_map_int() call, which will use >} >the BIOS supplied value), then this >} >is what you specified in the BIOS. >} > >} >I don't know which motherboard you >} >use, but it may help, if you send >} >me the boot message log. >} >} I'm using an Intel Altair motherboard. Its something they ship out >} to special customers or something. Its on loan from an Intel employee. > >Hmm, I still don't know, whether that >onboard SCSI chip is a PCI device (i.e. >can be configured as such). If it is on >ISA, then you can specify the IRQ to use >in the kernel config file. If it is hard >wired to some IRQ line, then you ought >to be able to set the Adaptec card to use >another IRQ. The aic7870 on board is a PCI device as well as the 2940. > >} One other funny thing. If you look at how aic7870.c is now, I call >} pci_map_int after I scan the bus. It would make more sense to map >} the interrupt handler (and deal with interrupt collisions) before >} scanning the bus (ahc_attach). Unfortunately, when I call pci_map_int >} first, the bus probe hangs. Its almost as if the code is relying on >} interrupts now that a handler is installed but since this is during >} boot/probe time, interrupts are disabled. Where it is now, works for >} one card. The ncr driver maps the interrupt first. Any ideas? > >Sorry. I'm very busy right now ... >If the Adaptec signals an interrupt >condition before being initialised, >then I'd understand, why the bus probe >would appear to hang if pci_map_int() >was called forst: I initialize the card and once I've initialized it sucessfully, I map in the interrupt handler. >The interrupt handler for the Adaptec >would be called immediately, would find >nothing to do, return, and because of PCI >interrupts being Level triggered, this >would result in another call of the same >interrupt handler immediately again. This just rang a bell. Is it usual to get a stray interrupt like this at map time? If so, I think I've found my bug! There's a nasty piece of code from the aic7770 driver that I've never seen get hit, that will try to switch the interrupt type (edge/level) if we see a stray before we probe the card. I'm almost positive now that we're hitting this in the aic7870 case and switching the interrupt type to the wrong kind. >Might help to printf() the interrupt status >register on entry to the IRQ handler ... >This way you would detect the infinite >interruptt handler "loop" and possibly the >cause. (Switching to Edge triggered interrupts >might be a preliminary workaround.) > >Regards, STefan Thanks STefan! > >-- > Stefan Esser Internet: <se@ZPR.Uni-Koeln.DE> > Zentrum fuer Paralleles Rechnen Tel: +49 221 4706019 > Universitaet zu Koeln FAX: +49 221 4705160 > Weyertal 80 > 50931 Koeln -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ==============================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503210208.SAA02500>