From owner-freebsd-current Mon Mar 20 16:17:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA15322 for current-outgoing; Mon, 20 Mar 1995 16:17:49 -0800 Received: from FileServ1.MI.Uni-Koeln.DE (FileServ1.MI.Uni-Koeln.DE [134.95.212.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id QAA15315 for ; Mon, 20 Mar 1995 16:17:44 -0800 Received: by FileServ1.MI.Uni-Koeln.DE id AA05446 (5.67b/IDA-1.5 for current@freebsd.org); Tue, 21 Mar 1995 01:16:57 +0100 Message-Id: <199503210016.AA05446@FileServ1.MI.Uni-Koeln.DE> From: se@MI.Uni-Koeln.DE (Stefan Esser) Date: Tue, 21 Mar 1995 01:16:56 +0100 In-Reply-To: "Justin T. Gibbs" "Re: Sharing interrupts with PCI devices?" (Mar 18, 11:43) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current@FreeBSD.org Subject: Re: Sharing interrupts with PCI devices? Sender: current-owner@FreeBSD.org Precedence: bulk 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. } 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: 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. 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 -- Stefan Esser Internet: Zentrum fuer Paralleles Rechnen Tel: +49 221 4706019 Universitaet zu Koeln FAX: +49 221 4705160 Weyertal 80 50931 Koeln