From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 22 16:09:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E087916A4CE for ; Mon, 22 Dec 2003 16:09:02 -0800 (PST) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (does-d9b90acd.pool.mediaWays.net [217.185.10.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9020143D41 for ; Mon, 22 Dec 2003 16:08:24 -0800 (PST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk (NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk [2002:d9b9:acd:0:200:c0ff:fefc:19aa]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id hBN07lX30429 verified NO) for ; Tue, 23 Dec 2003 01:07:49 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost)hBN07lr03615; Tue, 23 Dec 2003 01:07:47 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Tue, 23 Dec 2003 01:07:47 +0100 (CET) Message-Id: <200312230007.hBN07lr03615@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk> X-Authentication-Warning: NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk: beer set sender to bounce@NOSPAM.dyndns.dk using -f To: Hackers Haven From: Barry Bouwsma X-Mailman-Approved-At: Mon, 22 Dec 2003 17:24:13 -0800 Subject: pci_cfgintr: can't route an interrupt ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2003 00:09:03 -0000 [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: 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: on pcib1 ohci0: mem 0xd0000000-0xd0000fff irq 12 at device 8.0 on pci1 using shared irq12. usb0: OHCI version 1.0 usb0: 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: 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: (vendor=0x1033, dev=0x00e0) at 8.2 fwohci0: 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: 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: on pcib1 ohci0: mem 0xfcfff000-0xfcffffff irq 11 at device 8.0 on pci1 [...] ohci1: mem 0xfcffe000-0xfcffefff irq 10 at device 8.1 on pci1 ehci0: mem 0xfcffdc00-0xfcffdcff irq 9 at de vice 8.2 on pci1 [...] fwohci0: 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: port 0x6100-0x617f irq 12 at device 9 .0 on pci0 ohci0: mem 0xd0000000-0xd0000fff irq 12 at device 8.0 on pci1 fwohci0: port 0xe000-0xe07f mem 0xd0003000-0xd00037ff irq 12 at dev ice 11.0 on pci1 uhci0: port 0x6300-0x631f irq 12 at device 11.0 on p ci0 pci0: (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