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.
> --
> [email protected]
>
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 <[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, 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 :(
--
[email protected]
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."