Date: Sat, 16 Nov 1996 22:37:13 +0100 From: se@freebsd.org (Stefan Esser) To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, se@freebsd.org, hackers@freebsd.org, mrcpu@cdsnet.net Subject: Re: IRQ sharing on PCI? Message-ID: <199611162138.WAA00542@x14.mi.uni-koeln.de> In-Reply-To: <199611161657.DAA23158@godzilla.zeta.org.au>; from Bruce Evans on Nov 17, 1996 03:57:21 %2B1100 References: <199611161657.DAA23158@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 17, bde@zeta.org.au (Bruce Evans) wrote:
> >This means that there are in fact four PCI Int lines, but
> >most PCI cards will only use Int A. multi-function devices
> >will use Int A and Int B, if two functions are implemented
> >(see the AMD SCSI+Ethernet Combo chip), or all four lines
> >if there are four functions on a chip (announced 4 channel
> >Ethernet cards). And if you are using a PCI to PCI bridge
> >(current 4 channel Ethernet cards and the AH3940 or PCI bus
> >extender boxes, for example), then the PCI Int lines used
> >will depend on the slots used on the secondary side of the
> >PCI bridge. (The scheme used is meant to randomize PCI Int
>
> But these aren't typical :-). Now that Pentiums and PCI are
Well, we are lucky that the PCI-SIG didn't decide to only
support the "typical" PC ... I wasn't interested in the
result, if they had ... :)
> common in typical (cheap) systems, I guess that a typical
> PCI system has 0 or 1 (unused) PCI interrupts depending on
I assume you mean IRQs, not PCI interrupts ?
> whether vga0 has one :-]. Why aren't PCI interrupts used
> for motherboard i/o, at least optionally?
Hmmm, I don't quite understand this question.
I surely would prefer, if PCI was defined to use a reasonable
interrupt controller, seperate from the ISA PIC. But in order
to support fully ISA compatible PCI cards (for example some
BusLogic SCSI controllers and some Eternet cards, well and all
the VGA cards ...) they didn't say anything about interrupts,
except that they must be shareable.
> BTW, `pciconf -r' dumps core after printing the usage message.
Really ? It was supposed to panic your system :)
The following patch fixes this (and adds printing of the header
type register, which will be required for yet to be released
PCI chips).
Regards, STefan
Index: /usr/src/usr.sbin/pciconf/pciconf.c
===================================================================
RCS file: /usr/cvs/src/usr.sbin/pciconf/pciconf.c,v
retrieving revision 1.1.1.1
diff -C2 -r1.1.1.1 pciconf.c
*** pciconf.c 1996/10/22 20:27:47 1.1.1.1
--- pciconf.c 1996/11/16 21:23:14
***************
*** 54,57 ****
--- 54,58 ----
"\t%s [-r|-w] [-bh] sel addr [value]\n",
argv0, argv0);
+ exit (1);
}
***************
*** 132,139 ****
for (p = conf; p < &conf[pc.pci_len / sizeof conf[0]]; p++) {
! printf("pci%d:%d:%d:\tclass=0x%06x card=0x%08lx chip=0x%08lx rev=0x%02x\n",
p->pc_sel.pc_bus, p->pc_sel.pc_dev, p->pc_sel.pc_func,
p->pc_class >> 8, p->pc_subid,
! p->pc_devid, p->pc_class & 0xff);
}
}
--- 133,140 ----
for (p = conf; p < &conf[pc.pci_len / sizeof conf[0]]; p++) {
! printf("pci%d:%d:%d:\tclass=0x%06x card=0x%08lx chip=0x%08lx rev=0x%02x hdr=0x%02x\n",
p->pc_sel.pc_bus, p->pc_sel.pc_dev, p->pc_sel.pc_func,
p->pc_class >> 8, p->pc_subid,
! p->pc_devid, p->pc_class & 0xff, p->pc_hdr);
}
}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611162138.WAA00542>