pci_cfgintr: can't route an interrupt ...
Barry Bouwsma
freebsd-misuser at remove-NOSPAM-to-reply.NOSPAM.dyndns.dk
Mon Dec 22 16:09:03 PST 2003
[Drop my IPv6-only address for any replies, or hostname-only for IPv4...]
There was a thread about this in this list back in late may of 2003.
I recently found a mainboard which exhibits this problem with one particular
card I have -- a combi OHCI+EHCI USB card with firewire, and an on-card
HiNT PCI-PCI bridge.
This card worked mostly fine on a probably-older DEC Venturis machine.
A roughly-same-age-as-the-found-board machine was tried before the boot-
time interrupt storm was discovered and solved with -stable months ago,
so I can't say how well it worked there. I can only quote from a NetBSD
boot somewhat later in this message.
I'm using FreeBSD-4 with hacked source from around September-ish right now,
and here's part of the verbose boot on the ``new'' found machine that
has this problem (166MHz Pentium)...
bios32: Found BIOS32 Service Directory header at 0xc00fb950
bios32: Entry = 0xfbdd0 (c00fbdd0) Rev = 0 Len = 1
pcibios: PCI BIOS entry at 0xbe00
pnpbios: Found PnP BIOS data at 0xc00fcab0
pnpbios: Entry = f0000:cad8 Rev = 1.0
Other BIOS signatures found:
ACPI: 00000000
[...]
pcib1: <PCI to PCI bridge (vendor=3388 device=0021)> at device 10.0 on pci0
found-> vendor=0x1033, dev=0x0035, revid=0x41
class=0c-03-10, hdrtype=0x00, mfdev=1
subordinatebus=0 secondarybus=0
intpin=a, irq=12
map[10]: type 1, range 32, base d0000000, size 12
found-> vendor=0x1033, dev=0x0035, revid=0x41
class=0c-03-10, hdrtype=0x00, mfdev=0
subordinatebus=0 secondarybus=0
intpin=b, irq=255
map[10]: type 1, range 32, base d0001000, size 12
found-> vendor=0x1033, dev=0x00e0, revid=0x02
class=0c-03-20, hdrtype=0x00, mfdev=0
subordinatebus=0 secondarybus=0
intpin=c, irq=255
map[10]: type 1, range 32, base d0002000, size 8
found-> vendor=0x1106, dev=0x3044, revid=0x46
class=0c-00-10, hdrtype=0x00, mfdev=0
subordinatebus=0 secondarybus=0
intpin=a, irq=12
map[10]: type 1, range 32, base d0003000, size 11
map[14]: type 1, range 32, base 0000e000, size 7
pci1: <PCI bus> on pcib1
ohci0: <NEC uPD 9210 USB controller> mem 0xd0000000-0xd0000fff irq 12 at device
8.0 on pci1
using shared irq12.
usb0: OHCI version 1.0
usb0: <NEC uPD 9210 USB controller> on ohci0
usb0: USB revision 1.0
uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
[...]
ohci1: <NEC uPD 9210 USB controller> mem 0xd0001000-0xd0001fff at device 8.1 on
pci1
pci_cfgintr: can't route an interrupt to 1:8 INTB
ohci1: Could not allocate irq
device_probe_and_attach: ohci1 attach returned 6
pci1: <USB controller> (vendor=0x1033, dev=0x00e0) at 8.2
fwohci0: <VIA VT6306> port 0xe000-0xe07f mem 0xd0003000-0xd00037ff irq 12 at dev
ice 11.0 on pci1
I'm able to use ohci0 as well as fwohci0; ohci1 and the ehci controller
get irq=255 which -STABLE doesn't seem to be able to handle.
On the other old machine, where it works, IRQs are assigned as shown:
bios32: Found BIOS32 Service Directory header at 0xc00fff70
bios32: Entry = 0xfc716 (c00fc716) Rev = 0 Len = 1
pcibios: PCI BIOS entry at 0x246
pnpbios: Found PnP BIOS data at 0xc00f5870
pnpbios: Entry = f0000:ae95 Rev = 1.0
Other BIOS signatures found:
ACPI: 00000000
[...]
pcib1: <PCI to PCI bridge (vendor=3388 device=0021)> at device 11.0 on pci0
found-> vendor=0x1033, dev=0x0035, revid=0x41
class=0c-03-10, hdrtype=0x00, mfdev=1
subordinatebus=0 secondarybus=0
intpin=a, irq=11
map[10]: type 1, range 32, base fcfff000, size 12
found-> vendor=0x1033, dev=0x0035, revid=0x41
class=0c-03-10, hdrtype=0x00, mfdev=0
subordinatebus=0 secondarybus=0
intpin=b, irq=10
map[10]: type 1, range 32, base fcffe000, size 12
found-> vendor=0x1033, dev=0x00e0, revid=0x02
class=0c-03-20, hdrtype=0x00, mfdev=0
subordinatebus=0 secondarybus=0
intpin=c, irq=9
map[10]: type 1, range 32, base fcffdc00, size 8
found-> vendor=0x1106, dev=0x3044, revid=0x46
class=0c-00-10, hdrtype=0x00, mfdev=0
subordinatebus=0 secondarybus=0
intpin=a, irq=11
map[10]: type 1, range 32, base fcffd000, size 11
map[14]: type 1, range 32, base 0000fc80, size 7
pci1: <PCI bus> on pcib1
ohci0: <NEC uPD 9210 USB controller> mem 0xfcfff000-0xfcffffff irq 11 at device
8.0 on pci1
[...]
ohci1: <NEC uPD 9210 USB controller> mem 0xfcffe000-0xfcffefff irq 10 at device
8.1 on pci1
ehci0: <NEC uPD 720100 USB 2.0 controller> mem 0xfcffdc00-0xfcffdcff irq 9 at de
vice 8.2 on pci1
[...]
fwohci0: <VIA VT6306> port 0xfc80-0xfcff mem 0xfcffd000-0xfcffd7ff irq 11 at dev
ice 11.0 on pci1
using shared irq11.
As I said, it appears to work without problem, though just before I swapped
that old machine for the found board, I lost function of the USB mouse
after many days of working flawlessly together with firewire disk activity,
which problem I didn't bother to track down since it was the first time any
such thing has happened to me.
As I noted, I also tried this card under NetBSD many months ago on a
motherboard of roughly the same vintage. Here's what NetBSD had to say
at boot about it on that machine:
BIOS32 rev. 0 found at 0xf8080
[...]
ppb0 at pci0 dev 11 function 0: HiNT HB1 PCI-PCI Bridge (rev. 0x11)
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
ohci0 at pci1 dev 8 function 0: NEC USB Host Controller (rev. 0x41)
ohci0: interrupting at irq 9
ohci0: OHCI version 1.0
usb at ohci0 not configured
ohci1 at pci1 dev 8 function 1: NEC USB Host Controller (rev. 0x41)
ohci1: interrupting at irq 9
ohci1: OHCI version 1.0
usb at ohci1 not configured
ehci0 at pci1 dev 8 function 2: NEC USB Host Controller (rev. 0x02)
ehci0: interrupting at irq 9
ehci0: EHCI version 0.95
ehci0: companion controllers, 3 ports each: ohci0 ohci1
usb1 at ehci0: USB revision 2.0
uhub1 at usb1
uhub1: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub1: 5 ports with 5 removable, self powered
fwohci0 at pci1 dev 11 function 0: VIA Technologies VT3606 OHCI IEEE 1394 Contro
ller (rev. 0x46)
fwohci0: interrupting at irq 9
fwohci0: OHCI 1.0, 00:10:74:70:00:10:0b:f3, 400Mb/s, 2048 max_rec, 8 ir_ctx, 8 i
t_ctx
(hrm, haven't tried anything but FreeBSD 3.x and 4.x on the problematic
newly-acquired board, sorry to say)
Now, the ``new'' board appears to wedge solid at times with this card,
accessing a firewire-attached drive. No debugger, no keyboard input,
no numlock, no nuthin' that I can see, just power-cycle the thing.
Would this probably be an interrupt issue? If so, would it possibly be
related to fwohci sharing interrupts with many other cards, including the
usb ohci? (my ohci code dates from a few months back, and I know there
have been a good number of fixes) The devices sharing this IRQ are
pcm0: <Forte Media FM801 Audio Controller> port 0x6100-0x617f irq 12 at device 9
.0 on pci0
ohci0: <NEC uPD 9210 USB controller> mem 0xd0000000-0xd0000fff irq 12 at device
8.0 on pci1
fwohci0: <VIA VT6306> port 0xe000-0xe07f mem 0xd0003000-0xd00037ff irq 12 at dev
ice 11.0 on pci1
uhci0: <VIA 83C572 USB controller> port 0x6300-0x631f irq 12 at device 11.0 on p
ci0
pci0: <USB controller> (vendor=0x1106, dev=0x3104) at 11.2 irq 12
At the moment, I'm running this machine with the combi-ohci+fw card
swapped out for two separate uhci usb and fwohci firewire cards, also
at irq12. No wedges yet after a day of operation.
Now, I'll quote from this thread back late May, and pose questions:
M. Warner Losh:
> : > You lose. W/o a pci interrupt router, you can't use the cardbus
> : > bridge.
> : Good - so who/what should set up a PCI router ? the Bios ?
> It depends. Really old machines routed interrupts to all PCI slots
> and assigned devices found there an interrupt. Newer old machines
> expect the PCI bridge driver of the OS to cope. Newer old machines
> provide a BIOS interface to route them (which we can use). Newer
> machines with ACPI have ACPI to do the routing. You might want to do
Would my newly-found motherboard be a Really Old Machine, or is that
what is happening in the DEC Venturis machine where it works? As shown
above, they both have PCIBIOS shown in the verbose boot...
This isn't a cardbus bridge, rather an on-card PCI bridge, for whatever
difference that makes.
I have at hand no newer machines than 100+MHz pentium vintage at least
six years old -- certainly no ACPI -- so I can't compare in newer
boxes, sorry. I could try NetBSD, which disk is currently in use in a
different machine, to see how it copes with this board/card combination.
thanks
barry bouwsma
dumpster-diving for motherboards better off left behind
More information about the freebsd-hackers
mailing list