I am getting IRQ routing conflict messages:
Apr 8 21:32:47 ulthar kernel: usb.c: registered new driver usbdevfs
Apr 8 21:32:47 ulthar kernel: usb.c: registered new driver hub
Apr 8 21:32:47 ulthar kernel: usb-uhci.c: $Revision: 1.251 $ time 18:28:42
Apr
6 2001
Apr 8 21:32:47 ulthar kernel: usb-uhci.c: High bandwidth mode enabled
Apr 8 21:32:47 ulthar kernel: PCI: Found IRQ 11 for device 00:07.2
Apr 8 21:32:47 ulthar kernel: IRQ routing conflict in pirq table for device
00
:07.2
Apr 8 21:32:47 ulthar kernel: IRQ routing conflict in pirq table for device
00
:07.3
Apr 8 21:32:47 ulthar kernel: PCI: The same IRQ used for device 00:0a.0
Apr 8 21:32:47 ulthar kernel: PCI: The same IRQ used for device 00:0e.0
Apr 8 21:32:47 ulthar kernel: usb-uhci.c: USB UHCI at I/O 0xa400, IRQ 9
Apr 8 21:32:47 ulthar kernel: usb-uhci.c: Detected 2 ports
Apr 8 21:32:47 ulthar kernel: usb.c: new USB bus registered, assigned bus
numb
er 1
Apr 8 21:32:47 ulthar kernel: hub.c: USB hub found
Apr 8 21:32:47 ulthar kernel: hub.c: 2 ports detected
Apr 8 21:32:47 ulthar kernel: PCI: Found IRQ 11 for device 00:07.3
Apr 8 21:32:47 ulthar kernel: IRQ routing conflict in pirq table for device
00
:07.2
Apr 8 21:32:47 ulthar kernel: IRQ routing conflict in pirq table for device
00
:07.3
Apr 8 21:32:47 ulthar kernel: PCI: The same IRQ used for device 00:0a.0
Apr 8 21:32:47 ulthar kernel: PCI: The same IRQ used for device 00:0e.0
Apr 8 21:32:47 ulthar kernel: usb-uhci.c: USB UHCI at I/O 0xa800, IRQ 9
Apr 8 21:32:47 ulthar kernel: usb-uhci.c: Detected 2 ports
Apr 8 21:32:47 ulthar kernel: usb.c: new USB bus registered, assigned bus
numb
er 2
Apr 8 21:32:47 ulthar kernel: hub.c: USB hub found
Apr 8 21:32:47 ulthar kernel: hub.c: 2 ports detected
However I am not seeing any problems caused by this (however I do not use
USB very much, as I mentioned - only for a trackball). I also got the same
messages on my K7T Pro which used the KT133 chipset, however, so I don't
think this is a KT133/KT133A issue.
I can't seem to find dump_pirq on my system (Red Hat 7) - I can run it if I
find it...
Jeff Garzik said:
>Changing '#undef DEBUG' to '#define DEBUG 1' in
>arch/i386/kernel/pci-i386.h is also very helpful. Can you guys do so,
>and post the 'dmesg -s 16384' results to lkml? This includes the same
>information as dump_pirq, as well as some additional information.
I'll do that and get back to you - I'll have to physically be at my machine
to reset the BIOS to "PNP: Yes" so it won't be until I get home from work.
>Note that turning "Plug-n-Play OS" off in BIOS setup typically fixes
>many interrupt routing problems -- but Linux 2.4 should now have support
>for PNP OS:Yes. Clearly there appear to be problems with that support
>on some Via hardware.
>
>Note that you should have "Plug-n-Play OS: Yes" when generated the
>requested 'dmesg' output.
This may be the difference - I always set "Plug-n-Play OS: No" on all my
machines. Linux works fine and it doesn't seem to hurt Windows 98 any.
-- Manuel A. McLure - Unify Corp. Technical Support <mmt@unify.com> Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What about-?" M: "It's fixed." SG: "Eh, good. Good." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/