Axel Thimm said...
> On Tue, Apr 10, 2001 at 09:51:18AM -0700, Manuel A. McLure wrote:
> > I have the same motherboard with the same lspci output
> (i.e. I get the "pin
> > ?" part), but I don't see any problems running 2.4.3 or
> 2.4.3-ac[23]. I am
> > only using a trackball on my USB port - what problems are
> you seeing?
>
> Well, a part of the attached dmesg output yields:
>
> > PCI: Found IRQ 11 for device 00:07.2
> > IRQ routing conflict in pirq table for device 00:07.2
> > IRQ routing conflict in pirq table for device 00:07.3
> > PCI: The same IRQ used for device 00:0e.0
> > uhci.c: USB UHCI at I/O 0x9400, IRQ 5
>
> and later:
>
> > uhci: host controller process error. something bad happened
> > uhci: host controller halted. very bad
>
> 0.7.[2,3] are the usb devices. BIOS (and 2.2 kernels) had
> them at IRQ 5. 2.4
> somehow picks the irq of the ethernet adapter, iqr 11, instead.
>
> At least usb is then unusable.
>
> As you say that you have the same board, what is the output
> of dump_pirq - are
> your link values in the set of {1,2,3,5} or are they
> continuous 1-4? Maybe you
> are lucky - or better say, I am having bad luck :(
> --
> [email protected]
>
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 <[email protected]>
Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What
about-?" M: "It's fixed." SG: "Eh, good. Good."
On Tue, 10 Apr 2001, Manuel A. McLure wrote:
> 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.
Correct, it's perfectly fine to do that on all machines (not just Via).
Users should also set "PNP OS: No" for Linux 2.2...
Other BIOS settings to verify:
Assign IRQ to VGA: no (optional, but you probably don't need a VGA IRQ)
Operating System: other (or Unix, depending on the BIOS)
Memory hole: no
Unless you are using ISA cards, make sure all your PCI plug-n-play
IRQ settings are set to "PCI/PnP" not "ISA/ICU".
hmmm, maybe I should write a Linux kernel BIOS guide/FAQ...
Jeff
On Tue, Apr 10, 2001 at 01:38:32PM -0400, Jeff Garzik wrote:
> Axel Thimm wrote:
> > 0.7.[2,3] are the usb devices. BIOS (and 2.2 kernels) had them at IRQ 5.
> > 2.4 somehow picks the irq of the ethernet adapter, iqr 11, instead.
> > At least usb is then unusable.
> > As you say that you have the same board, what is the output of dump_pirq -
> > are your link values in the set of {1,2,3,5} or are they continuous 1-4?
> > Maybe you are lucky - or better say, I am having bad luck :(
> 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.
OK, gzip-attached to this mail.
> 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.
I had the problems with both settings (but I have tried so many patches and
kernels, that I cannot be sure about the combinations).
> Note that you should have "Plug-n-Play OS: Yes" when generated the
> requested 'dmesg' output.
O.K.
On Tue, Apr 10, 2001 at 01:01:07PM -0500, Jeff Garzik wrote:
> On Tue, 10 Apr 2001, Manuel A. McLure wrote:
> > 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.
>
> Correct, it's perfectly fine to do that on all machines (not just Via).
> Users should also set "PNP OS: No" for Linux 2.2...
>
> Other BIOS settings to verify:
> Assign IRQ to VGA: no (optional, but you probably don't need a VGA IRQ)
left to yes then, to keep the same BIOS settings/errors.
> Operating System: other (or Unix, depending on the BIOS)
n/a
> Memory hole: no
O.K.
> Unless you are using ISA cards, make sure all your PCI plug-n-play
> IRQ settings are set to "PCI/PnP" not "ISA/ICU".
O.K.
> hmmm, maybe I should write a Linux kernel BIOS guide/FAQ...
Yes, please!
And here are my FAQs with what I think are the answers (which means they are
possibly wrong, but then you get the idea, what some ppl might misunderstand):
Q) What does Plug-and-Play BIOS setting do?
A) It allows the OS to reassign IRQ/ports to devices (?)
Q) When should I turn it on or off?
A) If your BIOS is doing the right thing for you it's safe to turn it
off. If you trust your OS more, turn it on. (?)
Q) Which OSes should I trust? What about multiboot systems?
A) Linux > 2.4.x, M$ xxx, etc. (?)
Q) What bad thing might happen, if a non P&P OS has in the BIOS a P&P setting
or vice versa?
A) ... (?)
Thanks, Axel.
--
[email protected]
Le 10-Apr-2001, Manuel A. McLure ?crivait :
> 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.
I've been told it affects the way IRQs are assigned; With "PnP OS: No", some
boards (seen on several Asus mainboards, ie Phoenix-Award BIOS) try to
share IRQs as much as possible; It usually works, but the performance may
suffer a bit.
--
We are the dot in 0.2 Kb/s