Status of ALi MAGiK 1 support in 2.4.?
What is the status of the support for this chipset, found for example in an ASUS A7A266? Judging from http://www.acerlabs.com/eng/support/faqlnx.htm one gets the impression that ALi is respectfully treating the Linux community. Although VIA is the most popular chipset vendor, its reaction on the recently Southbridge 686 bugs (and even more recently the Northbridge bug with Athlon C) and the pirq routing problem in Linux rather disqualify it. So it seems that only AMD and ALi are left with Socket A chipsets (SiS 735 is yet to come). And the ALi MAGiK 1 has a good feature/cost ratio and is being reported as very stable (although perhaps not very fast). So having been burned in the recent past with VIAs KT133A/686B and Linux, I hope that I can get an ALi MAGiK 1 board and rest in peace ... Thanks, Axel. -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Status of ALi MAGiK 1 support in 2.4.?
What is the status of the support for this chipset, found for example in an ASUS A7A266? Judging from http://www.acerlabs.com/eng/support/faqlnx.htm one gets the impression that ALi is respectfully treating the Linux community. Although VIA is the most popular chipset vendor, its reaction on the recently Southbridge 686 bugs (and even more recently the Northbridge bug with Athlon C) and the pirq routing problem in Linux rather disqualify it. So it seems that only AMD and ALi are left with Socket A chipsets (SiS 735 is yet to come). And the ALi MAGiK 1 has a good feature/cost ratio and is being reported as very stable (although perhaps not very fast). So having been burned in the recent past with VIAs KT133A/686B and Linux, I hope that I can get an ALi MAGiK 1 board and rest in peace ... Thanks, Axel. -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA politics (was: VIA's Southbridge bug: Latest (pseudo-)patch)
On Sat, May 19, 2001 at 05:11:30PM +0100, Alan Cox wrote:
> > This are the latest suggestions for handling the VIA Southbridge bug as
> > derived from the hardware site www.au-ja.de (Many thanks to doelf).
>
> I'd rather people left this except for the obvious fixed that were done for
> non VIA northbridge combinations until 2.5. 2.4 is not an appropriate place
> to play with possibly disk corrupting PCI hacks without documentation.
>
> What is pathetic is that VIA have yet to place anything in the public domain
> giving correct workarounds. People are picking at BIOSes praying to spot all
> the changes (which may not be in the PCI registers even) because a vendor
> hasn't got the decency to admit they screwed up and then to issue proper
> fixes
these are my feelings, too. But I try to be an optimist - this is the reason
for the extended Cc: list, maybe it might trigger some change of those
politics. Note that Yiping Chen <[EMAIL PROTECTED]> had contacted this
list a few weeks ago to ask how to contribute drivers to Linux, indicating
perhaps a first step towards VIA going public domain.
Placing more documentation in the public domain would also help Linux
construct the right pirq routing tables, which is also a showstopper for
certain KT133A setups.
> If it had been a manufacturer in most respectable areas of business they'd
> be recalling and reissuing components, and paying for the end resllers to
> notify each customer
Let's hope VIA will indeed change politics. Either the bug is not fixable and
VIA should recall, or the bug/fix should be cleanly documented. Currently VIA
is hoping to survive this fiasco by not drawing too much attention ("it was
the SB"), but this may become a boomerang (I for my part will try to have the
motherboard replaced after having been haunted for the last 6 weeks).
At the very end there are us, the user, who would not want to wait for 2.5
(speak 2.6 for the common user ...). Of course Linux is not to blame, but it
is indeed a big user community hit by this.
Regards, Axel.
--
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
VIA's Southbridge bug: Latest (pseudo-)patch
This are the latest suggestions for handling the VIA Southbridge bug as
derived from the hardware site www.au-ja.de (Many thanks to doelf).
Could a linux kernel specialist review and form this pseudo-patch to a real
kernel patch? Given the "old" patch found in 2.4.4 I could have written the
part of setting the PCI registers, but I am totally in the dark as to how to
identify EPOX Mobos and derive their BIOS ID.
Here comes the pseudo-patch:
if( KT133A || KT133 || KX133 ) {
if( Mainboard=="Epox 8KTA-3(+)" && BIOS>="8kt31417" )
return 0; /* EPOX already fixed it their way. */
#ifdef NEW_PATCH
Offset 76: Set bit5=0 and bit4=1 ("every PCI master grand")
#else /* this is already part of 2.4.4 */
Offset 70: Set bit1=0 ("PCI Delay Transaction = 0")
Offset 70: Set bit2=0 ("PCI Master Read Caching = 0")
Offset 75: Set bit0-4 ("0 <= PCI Latency <= 32")
#endif
}
History (condensed version, more found in [1]):
- When doelf and his colleagues found the Southbridge bug, they already worked
on a solution, which was adopted by most BIOS updates (but not EPOX) and
also found its way in 2.4.3-ac7. This patch helped in the majority of the
buggy boards, but still left some cases unresolved.
- VIA released their own patch ten days ago which tries to solve the Bug
(viapfd100.exe and the latest 4in1 driver). Not only is this patch only for
Windows and undocumented, but it also only applies if the running box has a
Soundblaster card.
- Someone analysed the patch and found the changed PCI settings so that the
patch could be implemented also for systems without a Soundblaster
card (see [1]). This is the NEW_PATCH outlined above. This seems to be
working (all related hardware sites which had discovered the bug are content
now), so it would be nice to have it in the kernel and test it from within
linux.
[1] latest english information on the VIA Southbridge bug:
http://www.au-ja.de/review-kt133a-1-en.html
--
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
VIA's Southbridge bug: Latest (pseudo-)patch
This are the latest suggestions for handling the VIA Southbridge bug as
derived from the hardware site www.au-ja.de (Many thanks to doelf).
Could a linux kernel specialist review and form this pseudo-patch to a real
kernel patch? Given the old patch found in 2.4.4 I could have written the
part of setting the PCI registers, but I am totally in the dark as to how to
identify EPOX Mobos and derive their BIOS ID.
Here comes the pseudo-patch:
if( KT133A || KT133 || KX133 ) {
if( Mainboard==Epox 8KTA-3(+) BIOS=8kt31417 )
return 0; /* EPOX already fixed it their way. */
#ifdef NEW_PATCH
Offset 76: Set bit5=0 and bit4=1 (every PCI master grand)
#else /* this is already part of 2.4.4 */
Offset 70: Set bit1=0 (PCI Delay Transaction = 0)
Offset 70: Set bit2=0 (PCI Master Read Caching = 0)
Offset 75: Set bit0-4 (0 = PCI Latency = 32)
#endif
}
History (condensed version, more found in [1]):
- When doelf and his colleagues found the Southbridge bug, they already worked
on a solution, which was adopted by most BIOS updates (but not EPOX) and
also found its way in 2.4.3-ac7. This patch helped in the majority of the
buggy boards, but still left some cases unresolved.
- VIA released their own patch ten days ago which tries to solve the Bug
(viapfd100.exe and the latest 4in1 driver). Not only is this patch only for
Windows and undocumented, but it also only applies if the running box has a
Soundblaster card.
- Someone analysed the patch and found the changed PCI settings so that the
patch could be implemented also for systems without a Soundblaster
card (see [1]). This is the NEW_PATCH outlined above. This seems to be
working (all related hardware sites which had discovered the bug are content
now), so it would be nice to have it in the kernel and test it from within
linux.
[1] latest english information on the VIA Southbridge bug:
http://www.au-ja.de/review-kt133a-1-en.html
--
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
VIA politics (was: VIA's Southbridge bug: Latest (pseudo-)patch)
On Sat, May 19, 2001 at 05:11:30PM +0100, Alan Cox wrote: This are the latest suggestions for handling the VIA Southbridge bug as derived from the hardware site www.au-ja.de (Many thanks to doelf). I'd rather people left this except for the obvious fixed that were done for non VIA northbridge combinations until 2.5. 2.4 is not an appropriate place to play with possibly disk corrupting PCI hacks without documentation. What is pathetic is that VIA have yet to place anything in the public domain giving correct workarounds. People are picking at BIOSes praying to spot all the changes (which may not be in the PCI registers even) because a vendor hasn't got the decency to admit they screwed up and then to issue proper fixes these are my feelings, too. But I try to be an optimist - this is the reason for the extended Cc: list, maybe it might trigger some change of those politics. Note that Yiping Chen [EMAIL PROTECTED] had contacted this list a few weeks ago to ask how to contribute drivers to Linux, indicating perhaps a first step towards VIA going public domain. Placing more documentation in the public domain would also help Linux construct the right pirq routing tables, which is also a showstopper for certain KT133A setups. If it had been a manufacturer in most respectable areas of business they'd be recalling and reissuing components, and paying for the end resllers to notify each customer Let's hope VIA will indeed change politics. Either the bug is not fixable and VIA should recall, or the bug/fix should be cleanly documented. Currently VIA is hoping to survive this fiasco by not drawing too much attention (it was the SB), but this may become a boomerang (I for my part will try to have the motherboard replaced after having been haunted for the last 6 weeks). At the very end there are us, the user, who would not want to wait for 2.5 (speak 2.6 for the common user ...). Of course Linux is not to blame, but it is indeed a big user community hit by this. Regards, Axel. -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA's Southbridge bug (was: PATCH 2.4.5.1: Fix Via interrupt routing issues)
On Mon, May 14, 2001 at 02:07:53PM -0300, John R Lenton wrote: > On Sun, May 13, 2001 at 01:28:06PM -0400, Jeff Garzik wrote: > > For those of you with Via interrupting routing issues (or > > interrupt-not-being-delivered issues, etc), please try out this patch > > [...] > Just to add a little noise: My box (msi 694d pro AI motherboard, > revI, i.e. vt82c686a) been a *lot* stabler since I removed the > Live! and dropped back to the onboard soundcard. > [...] > If I could put in words the difference between the Live! and the > via, I would. Alas, I can't, so you're stuck with this inane > rant: > > please please please fix it. This has nothing to do with the routing issue, but is a bigger problem by itself :( The VIA chipset is buggy, and your Soundblaster Live! increases the likelyhood of triggering that bug. This is a rather well documented problem, read an english article about it on http://www.au-ja.de/review-kt133a-1-en.html and a german article on the discussion of this on the lkml on http://www.au-ja.de/review-kt133a-linux.html (if you don't read German this is not a problem, as all links found there refer to english pages). You seem to have bad luck, as the 686a should not be a buggy as the 686b. Bottom line: Try to get a BIOS upgrade and hope that VIA will opensource and contribute their Windows patch to linux... Regards, Axel. -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA's Southbridge bug (was: PATCH 2.4.5.1: Fix Via interrupt routing issues)
On Mon, May 14, 2001 at 02:07:53PM -0300, John R Lenton wrote: On Sun, May 13, 2001 at 01:28:06PM -0400, Jeff Garzik wrote: For those of you with Via interrupting routing issues (or interrupt-not-being-delivered issues, etc), please try out this patch [...] Just to add a little noise: My box (msi 694d pro AI motherboard, revI, i.e. vt82c686a) been a *lot* stabler since I removed the Live! and dropped back to the onboard soundcard. [...] If I could put in words the difference between the Live! and the via, I would. Alas, I can't, so you're stuck with this inane rant: please please please fix it. This has nothing to do with the routing issue, but is a bigger problem by itself :( The VIA chipset is buggy, and your Soundblaster Live! increases the likelyhood of triggering that bug. This is a rather well documented problem, read an english article about it on http://www.au-ja.de/review-kt133a-1-en.html and a german article on the discussion of this on the lkml on http://www.au-ja.de/review-kt133a-linux.html (if you don't read German this is not a problem, as all links found there refer to english pages). You seem to have bad luck, as the 686a should not be a buggy as the 686b. Bottom line: Try to get a BIOS upgrade and hope that VIA will opensource and contribute their Windows patch to linux... Regards, Axel. -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.5.1: Fix Via interrupt routing issues
On Mon, May 14, 2001 at 09:05:56PM +0200, Axel Thimm wrote: > Anyway, I am sending the dmesg with "#define DEBUG 1" in pci-i386.h. It is a > 2.4.4-ac5 defconfig kernel, but 2.4.4 has the same errors. System is an > MS-6330 v3.0 (MSI K7T Turbo), KT133A, Duron 700. I you have any idea, how I > could fix the pirq table I'd be glad to test further. Perhaps I should have also sent it ... Here it comes. -- [EMAIL PROTECTED] dmesg-2.4.4-ac5.log.bz2
Re: PATCH 2.4.5.1: Fix Via interrupt routing issues
[Cc: list trimmed] On Mon, May 14, 2001 at 12:16:55PM -0400, Jeff Garzik wrote: > Axel Thimm wrote: > > On Sun, May 13, 2001 at 01:28:06PM -0400, Jeff Garzik wrote: > > > For those of you with Via interrupting routing issues (or > > > interrupt-not-being-delivered issues, etc), please try out this patch > > > and let me know if it fixes things. It originates from a tip from > > > Adrian Cox... thanks Adrian! > > > > Unfortunately the patch does not trigger here. nr_ioapics is zero on my UP > > KT133A board. Was this patch for MP only? > > Not for MP only, but mostly such: UP systems with IO-APIC, or MP > systems. What about the following dmesg logs: > Local APIC disabled by BIOS -- reenabling. > Found and enabled local APIC! > [...] > Using local APIC timer interrupts. > calibrating APIC timer ... Don't they imply an APIC? Anyway, I am sending the dmesg with "#define DEBUG 1" in pci-i386.h. It is a 2.4.4-ac5 defconfig kernel, but 2.4.4 has the same errors. System is an MS-6330 v3.0 (MSI K7T Turbo), KT133A, Duron 700. I you have any idea, how I could fix the pirq table I'd be glad to test further. Regards, Axel. -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.5.1: Fix Via interrupt routing issues
On Sun, May 13, 2001 at 01:28:06PM -0400, Jeff Garzik wrote: > For those of you with Via interrupting routing issues (or > interrupt-not-being-delivered issues, etc), please try out this patch > and let me know if it fixes things. It originates from a tip from > Adrian Cox... thanks Adrian! Unfortunately the patch does not trigger here. nr_ioapics is zero on my UP KT133A board. Was this patch for MP only? -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.5.1: Fix Via interrupt routing issues
On Sun, May 13, 2001 at 01:28:06PM -0400, Jeff Garzik wrote: For those of you with Via interrupting routing issues (or interrupt-not-being-delivered issues, etc), please try out this patch and let me know if it fixes things. It originates from a tip from Adrian Cox... thanks Adrian! Unfortunately the patch does not trigger here. nr_ioapics is zero on my UP KT133A board. Was this patch for MP only? -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.5.1: Fix Via interrupt routing issues
[Cc: list trimmed] On Mon, May 14, 2001 at 12:16:55PM -0400, Jeff Garzik wrote: Axel Thimm wrote: On Sun, May 13, 2001 at 01:28:06PM -0400, Jeff Garzik wrote: For those of you with Via interrupting routing issues (or interrupt-not-being-delivered issues, etc), please try out this patch and let me know if it fixes things. It originates from a tip from Adrian Cox... thanks Adrian! Unfortunately the patch does not trigger here. nr_ioapics is zero on my UP KT133A board. Was this patch for MP only? Not for MP only, but mostly such: UP systems with IO-APIC, or MP systems. What about the following dmesg logs: Local APIC disabled by BIOS -- reenabling. Found and enabled local APIC! [...] Using local APIC timer interrupts. calibrating APIC timer ... Don't they imply an APIC? Anyway, I am sending the dmesg with #define DEBUG 1 in pci-i386.h. It is a 2.4.4-ac5 defconfig kernel, but 2.4.4 has the same errors. System is an MS-6330 v3.0 (MSI K7T Turbo), KT133A, Duron 700. I you have any idea, how I could fix the pirq table I'd be glad to test further. Regards, Axel. -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.5.1: Fix Via interrupt routing issues
On Mon, May 14, 2001 at 09:05:56PM +0200, Axel Thimm wrote: Anyway, I am sending the dmesg with #define DEBUG 1 in pci-i386.h. It is a 2.4.4-ac5 defconfig kernel, but 2.4.4 has the same errors. System is an MS-6330 v3.0 (MSI K7T Turbo), KT133A, Duron 700. I you have any idea, how I could fix the pirq table I'd be glad to test further. Perhaps I should have also sent it ... Here it comes. -- [EMAIL PROTECTED] dmesg-2.4.4-ac5.log.bz2
Re: FastTrack100+2.4.4 panic
On Sat, May 12, 2001 at 11:35:32PM -0700, Eric Olson wrote: > I am having trouble with the 2.4.4 kernel using MSI 694D Pro AR dual > PIII processor motherboard with onboard Promise ATA100. > > I have four nearly identically configured motherboards, two of which > have the Promise ATA100 and two which do not. There are no disks > hooked to the Promise controller and I am not using it. However, the > motherboards with the Promise controller panic soon after the Promise > detection lines > > PDC20265: IDE controller on PCI bus 00 dev 60 > PDC20265: chipset revision 2 > PDC20265: not 100% native mode: will probe irqs later The same happens on an MSI 6330 v3.0 (Turbo). I also tried 2.4.4-ac5 which does not show this behaviour. The ac series have some patches related to FastTrack/PDC20265, try it out. BTW, do your MSI boards have a VIA chipset? If yes, do you get any IRQ conflicts in your dmesg output? Regards, Axel. -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FastTrack100+2.4.4 panic
On Sat, May 12, 2001 at 11:35:32PM -0700, Eric Olson wrote: I am having trouble with the 2.4.4 kernel using MSI 694D Pro AR dual PIII processor motherboard with onboard Promise ATA100. I have four nearly identically configured motherboards, two of which have the Promise ATA100 and two which do not. There are no disks hooked to the Promise controller and I am not using it. However, the motherboards with the Promise controller panic soon after the Promise detection lines PDC20265: IDE controller on PCI bus 00 dev 60 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later The same happens on an MSI 6330 v3.0 (Turbo). I also tried 2.4.4-ac5 which does not show this behaviour. The ac series have some patches related to FastTrack/PDC20265, try it out. BTW, do your MSI boards have a VIA chipset? If yes, do you get any IRQ conflicts in your dmesg output? Regards, Axel. -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Still IRQ routing problems with VIA
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? -- [EMAIL PROTECTED] dmesg.David.msi-k7t-pro2a.log.gz dmesg.Silke.msi-k7t-pro2a.log.gz dmesg.a7v.log.gz
Re: Still IRQ routing problems with VIA
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? -- [EMAIL PROTECTED] dmesg.David.msi-k7t-pro2a.log.gz dmesg.Silke.msi-k7t-pro2a.log.gz dmesg.a7v.log.gz
Re: Still IRQ routing problems with VIA
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 OS has in the BIOS a P setting
or vice versa?
A) ... (?)
Thanks, Axel.
--
[EMAIL PROTECTED]
dmesg.2.4.3-puredebug.log.gz
Re: Still IRQ routing problems with VIA
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]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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 PCI crazyness...)
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- SERR- + 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]
dmesg.2.4.3.log.gz
dump_pirq.2.2.17.log.gz
lspci.2.2.17.log.gz
lspci.2.4.3-pure.log.gz
Still IRQ routing problems with VIA (was: VIA KT133 chipset PCI crazyness...)
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]
dmesg.2.4.3.log.gz
dump_pirq.2.2.17.log.gz
lspci.2.2.17.log.gz
lspci.2.4.3-pure.log.gz
Re: Still IRQ routing problems with VIA
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]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Still IRQ routing problems with VIA
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 PP OS has in the BIOS a PP setting
or vice versa?
A) ... (?)
Thanks, Axel.
--
[EMAIL PROTECTED]
dmesg.2.4.3-puredebug.log.gz
