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

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

Post by Manuel A. McLur » Thu, 12 Apr 2001 02:00:15



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:


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


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?

--

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

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by Axel Thim » Thu, 12 Apr 2001 02:40:05



> 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:

Quote:> 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:

Quote:> 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 :(
--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by Jeff Garzi » Thu, 12 Apr 2001 02:50:05



> 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."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by Manuel A. McLur » Thu, 12 Apr 2001 03:00:11


Axel Thimm said...


> > 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 :(
> --


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:

Quote:>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.

Quote:>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.

--

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

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by Jeff Garzi » Thu, 12 Apr 2001 03:20:06



> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by Jeff Garzi » Thu, 12 Apr 2001 06:20:06



> 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%
;-)

Quote:> 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."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by Manuel A. McLur » Thu, 12 Apr 2001 06:30:11


Quote:> > 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 * 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 :-)

--

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

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

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

Post by Jeff Garzi » Thu, 12 Apr 2001 06:50:05



> I'd do that if this wasn't also my Windows 98 * 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."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

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

Post by Pierre Etchemait » Fri, 13 Apr 2001 00:30:05


Le 10-Apr-2001, Manuel A. McLure crivait :

Quote:> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/