RE: Still IRQ routing problems with VIA

RE: Still IRQ routing problems with VIA

[Manuel A. McLure]

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 :(
> -- 
> Axel.Thimm@physik.fu-berlin.de
> 

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."

RE: Still IRQ routing problems with VIA

[Jeff Garzik]

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

RE: Still IRQ routing problems with VIA (was: VIA KT133 chipset P CI crazyness...)

[Manuel A. McLure]

Axel Thimm said...
> Several weeks ago there had been a thread on the pirq 
> assignments of newer VIA
> and SiS chipsets ending with everybody happy.
> 
> Everybody? Not everybody - there is a small village of 
> chipsets resisting the
> advent of 2.4.x :(
> 
> The system is a KT133A (MSI's K7T Turbo MS-6330 board)/Duron 700
> system. Kernel 2.4.x have IRQ routing problems and USB 
> failures (the latter
> will most probably be due to IRQ mismatches, I believe).
> 
> 2.2 kernel = 2.2.17 RH-kernel
> 2.4 kernel = 2.4.3 kernel with 'yes ""|make config' (I also 
> tried configuring
>              and -ac3 patches to no avail.)
> 
> I attached dmesg, lspci -vvvxxx (under both 2.2 and 2.4), and 
> dump_irq (which
> is the same for both kernels)
> 
> As far as I could follow the discussion back in January a 
> problem seem to be
> that different chipset vendors may arbitrary map pirq to 
> links ('A' vs 1
> etc.). On my board I see that there is a rather strange 
> mapping. Maybe this
> confuses 2.4.3?
> 
> Most prominent difference in the lspci -vvvxxx output (to me) 
> is the interrupt
> with the unknown pin:
> 
> > @@ -162,6 +162,7 @@
> >  00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 
> [Apollo Super ACPI] (rev 40)
> >         Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- 
> VGASnoop- ParErr- Stepping- SERR- FastB2B-
> >         Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- 
> DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> > +       Interrupt: pin ? routed to IRQ 11
> >         Capabilities: [68] Power Management version 2
> >                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> >                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> Maybe it is a KT133A != KT133 issue. Note that the analysis 
> above is the best
> I can provide, which has nothing to do with a good analysis.
> 
> Any help mostly appreciated! My board wants to run 2.4.x!!!
> 
> BTW kernel 2.2.x does not give any irq related messages in 
> its logs. Does this
> mean that 2.2.x works well, or that the errors are just not displayed?
> 
> Thanks, Axel.
> -- 
> Axel.Thimm@physik.fu-berlin.de
> 

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?

--
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."

Re: Still IRQ routing problems with VIA

[Axel Thimm]

On Tue, Apr 10, 2001 at 09:51:18AM -0700, Manuel A. McLure wrote:
> Axel Thimm said...
> > Several weeks ago there had been a thread on the pirq assignments of newer
> > VIA and SiS chipsets ending with everybody happy.
> > Everybody? Not everybody - there is a small village of chipsets resisting
> > the advent of 2.4.x :(
> > The system is a KT133A (MSI's K7T Turbo MS-6330 board)/Duron 700
> > system. Kernel 2.4.x have IRQ routing problems and USB failures (the
> > latter will most probably be due to IRQ mismatches, I believe).
> 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 :(
-- 
Axel.Thimm@physik.fu-berlin.de

Re: Still IRQ routing problems with VIA

[Jeff Garzik]

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.

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.

Regards,

	Jeff


-- 
Jeff Garzik       | Sam: "Mind if I drive?"
Building 1024     | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft      |       and shrieking like a cheerleader."

Re: Still IRQ routing problems with VIA

[Axel Thimm]

[-- Attachment #1: Type: text/plain, Size: 2783 bytes --]

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.
-- 
Axel.Thimm@physik.fu-berlin.de

[-- Attachment #2: dmesg.2.4.3-puredebug.log.gz --]
[-- Type: application/x-gzip, Size: 3751 bytes --]

RE: Still IRQ routing problems with VIA

[Pierre Etchemaite]

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

RE: Still IRQ routing problems with VIA

[Manuel A. McLure]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

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.

Here's my dmesg output - I tried with both PNP: Yes and PNP: No and the
dmesg outputs were exactly the same modulo a Hz or two in the processor
speed detection.

I do have an IRQ for my VGA since the instructions for my card (a Voodoo 5
5500) specifically say an IRQ is needed.

--
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."


[-- Attachment #2: dmesg_pnp_yes.txt.gz --]
[-- Type: application/octet-stream, Size: 4031 bytes --]

Re: Still IRQ routing problems with VIA

[Jeff Garzik]

"Manuel A. McLure" wrote:
> 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.
> 
> Here's my dmesg output - I tried with both PNP: Yes and PNP: No and the
> dmesg outputs were exactly the same modulo a Hz or two in the processor
> speed detection.

Thanks.  I'm building a database of these.  There is definitely an issue
with Via and interrupt routing.  Hopefully I can collate this data soon
and figure out what's going on.  I need to find some Via hardware for
myself, too, since I only have an old Via-based laptop which works 100%
;-)


> I do have an IRQ for my VGA since the instructions for my card (a Voodoo 5
> 5500) specifically say an IRQ is needed.

I wonder though... In my mind this is a driver not hardware issue.  If
the XFree86 and/or Linux console driver do not use the IRQ, you need not
have BIOS assign one.  If you are feeling dangerous, try turning the VGA
IRQ assignment off in BIOS and see if things melt/explode/kick ass.

Regards,

	Jeff


-- 
Jeff Garzik       | Sam: "Mind if I drive?"
Building 1024     | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft      |       and shrieking like a cheerleader."

Re: Still IRQ routing problems with VIA

[Axel Thimm]

[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]

On Tue, Apr 10, 2001 at 05:11:42PM -0400, Jeff Garzik wrote:
> "Manuel A. McLure" wrote:
> > 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.
> > Here's my dmesg output - I tried with both PNP: Yes and PNP: No and the
> > dmesg outputs were exactly the same modulo a Hz or two in the processor
> > speed detection.

We are having the same observation here, PNP yse or no does not change dmesg
output of 2.4.x.

> Thanks.  I'm building a database of these.  There is definitely an issue
> with Via and interrupt routing.  Hopefully I can collate this data soon and
> figure out what's going on.  I need to find some Via hardware for myself,
> too, since I only have an old Via-based laptop which works 100% ;-)

O.K., here are three further dmesg outputs of the same 2.4.3 kernel
configuration (yes ""|make config) [Thanks to Jens and David!].

Two MSI K7T Pro2A boards (my first report was a MSI K7T Turbo board with
KT133A):
    dmesg.David.msi-k7t-pro2a.log.gz
    dmesg.Silke.msi-k7t-pro2a.log.gz
An Asus A7V Board:
    dmesg.a7v.log.gz

Recognizing any pattern?
-- 
Axel.Thimm@physik.fu-berlin.de

[-- Attachment #2: dmesg.David.msi-k7t-pro2a.log.gz --]
[-- Type: application/x-gzip, Size: 2979 bytes --]

[-- Attachment #3: dmesg.Silke.msi-k7t-pro2a.log.gz --]
[-- Type: application/x-gzip, Size: 3399 bytes --]

[-- Attachment #4: dmesg.a7v.log.gz --]
[-- Type: application/x-gzip, Size: 3305 bytes --]

RE: Still IRQ routing problems with VIA

[Manuel A. McLure]

> > I do have an IRQ for my VGA since the instructions for my 
> card (a Voodoo 5
> > 5500) specifically say an IRQ is needed.
> 
> I wonder though... In my mind this is a driver not hardware issue.  If
> the XFree86 and/or Linux console driver do not use the IRQ, 
> you need not
> have BIOS assign one.  If you are feeling dangerous, try 
> turning the VGA
> IRQ assignment off in BIOS and see if things melt/explode/kick ass.

I'd do that if this wasn't also my Windows 98 gaming machine - I'm supposing
that the Windows drivers do use the IRQ even if XFree86/Linux doesn't. I
dunno if Windows is smart enough to assign an IRQ even if the BIOS doesn't.
Anyway, things are working now (specially since the last tulip patches) and
I like it that way :-)

--
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."

Re: Still IRQ routing problems with VIA

[Jeff Garzik]

"Manuel A. McLure" wrote:
> I'd do that if this wasn't also my Windows 98 gaming machine - I'm supposing
> that the Windows drivers do use the IRQ even if XFree86/Linux doesn't. I
> dunno if Windows is smart enough to assign an IRQ even if the BIOS doesn't.
> Anyway, things are working now (specially since the last tulip patches) and
> I like it that way :-)

Well, as the old saying goes, "if it ain't broke, don't fix it."

Theoretically, with PNP OS enabled, the driver will assign VGA an IRQ if
it needs one, under both Windows and Linux.

	Jeff


-- 
Jeff Garzik       | Sam: "Mind if I drive?"
Building 1024     | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft      |       and shrieking like a cheerleader."