Ok. I've found the culprit but don't understand why. Working on the theory that the problem was A. virtualization technology, B. the 1394 controller or C. my Hauppauge PVR-500 card I disabled or removed each one at a time. After removing the PVR-500 card the firewire controller shows up as one device. I took lspci -vvv and dmesg output from each of the four scenarios: 1. Virtualization enabled, PVR card installed and 1394 controller enabled 2. Virtualization DISABLED, PVR card installed and 1394 controller enabled 3. Virtualization enabled, PVR card installed and 1394 controller DISABLED 4. Virtualization enabled, PVR card REMOVED and 1394 controller enabled Nothing changed until I removed the PVR card. The output of all four are quite lengthy. Can I add attachments on this list? -Alan On Mon, Jul 18, 2011 at 3:14 AM, Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> wrote: > On Jul 18 Alan Evans wrote to linux1394-user: >> I have never paid much attention to firewire support but now I am >> building a media player and plan to scrape video via firewire so I >> have to pay attention! >> >> Anyway, my motherboard has 2 onboard firewire ports (one on ATX rear >> panel and 1 header which is unconnected) but lspci shows the device 33 >> times! What gives? > > lspci should show only one VT6307 device. The two physical ports are both > attached to a single link layer controller device i.e. FireWire-to-PCI > bridge device. > > I have never heard of such a problem before. It is not a FireWire problem > but a PCI problem. Hence I Cc'd linux-pci. > > VT6307 is a PCI device and is surely located behind a PCIe-to-PCI bridge. > Perhaps that bridge doesn't work right. > > Alan, could you please reply-to-all with the output of "dmesg" attached, > beginning at the boot of the system? > > Maybe a BIOS update can fix it? > >> Secondly I am seeing a bunch of "Failed to reset ohci card" messages >> that coincide with the extra devices. >> >> ...snip... >> [ 37.619910] firewire_ohci 0000:04:12.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 >> [ 38.618540] firewire_ohci: Failed to reset ohci card. >> [ 38.618607] firewire_ohci 0000:04:12.0: PCI INT A disabled >> [ 38.618615] firewire_ohci: probe of 0000:04:12.0 failed with error -16 >> ...snip... > > Well, if the kernel driver core binds firewire-ohci to devices that don't > actually exist, there are bound to be initialization failures. > >> lspci >> ...snip... >> 03:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) >> 04:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) >> 04:01.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) >> 04:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) >> ...omitted for brevity... >> 04:1e.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) >> 04:1f.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) >> ...snip... >> >> Any thoughts? >> >> Regards, >> -Alan > > I suppose the one VT6307 at bus 03 is for real, and the 32 ones on bus 04 > are ghosts. > -- > Stefan Richter > -=====-==-== -=== =--=- > http://arcgraph.de/sr/ > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
