* VIA KT133A / athlon / MMX @ 2001-07-28 1:42 PEIFFER Pierre 2001-07-30 21:33 ` Stefan Becker 0 siblings, 1 reply; 30+ messages in thread From: PEIFFER Pierre @ 2001-07-28 1:42 UTC (permalink / raw) To: linux-kernel Hi ! I'm a recent user of the duo VIA KT133A chipset/Athlon CPU and after compiling a customized kernel and booting on it, I fall on kernel panic at boot time, just little time after starting the init process. After some search and test, it appears that it was the K7 mmx routines which cause the crash Using the "default" routines by replacing #ifdef CONFIG_MK7 by #ifdef 0 solves the problem. I just wanted to mention that, here, this crash is systematic with k7-mmx routines. I also just wanted to know the current status of this problem since I have not found clear answer on the different threads about this topic. As I understand, this problem does not exist on every athlon but only on some which work with the VIA KT133 chipset ? Right ? Anyway, feel free to ask me more information if needed and please, CC'ed me personally the answers/comments because I'm not subscribed to the LKML. Config.: ABIT KT7A (without RAID) Athlon 1.2 GHz 256 Meg RAM FSB at 133 MHz (Other card description is not imortant I think) Running Mandrake 8.0 (*) (at home) with kernel 2.4.7 (or 2.4.6) compiled with gcc 3.0 (same pb with gcc 2.96 (non-official, I know)) (*) In fact, this distribution has a special startup and switch immediatly (at startup) in a graphic mode for showing the start of the runlevel. And I think/suppose that this definitly causes the crash. Thanks, Pierre ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-28 1:42 VIA KT133A / athlon / MMX PEIFFER Pierre @ 2001-07-30 21:33 ` Stefan Becker 0 siblings, 0 replies; 30+ messages in thread From: Stefan Becker @ 2001-07-30 21:33 UTC (permalink / raw) To: linux-kernel Hi, FWIW, I have an ASUS A7V133 with a T-Bird 900, running 2.4.7ac3+ext3 with K7 optimization enabled. It's rock solid. 2.4.6ac5 and previous ran a long time without problems too. 'lspci -vxxx' shows: 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) Subsystem: Asustek Computer, Inc.: Unknown device 8042 Flags: bus master, medium devsel, latency 0 Memory at e4000000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 00 00 00 10: 08 00 00 e4 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 42 80 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 17 a4 6b b4 06 28 20 20 88 80 08 08 10 18 20 20 60: 3f ff 55 a0 52 52 52 00 40 7c 86 0f 08 1f 00 00 70: de c0 cc 0c 0e a1 d2 00 01 b4 11 02 00 00 00 09 80: 0f 40 00 00 c0 00 00 00 03 00 e0 1f 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 6e 02 14 00 b0: 7f 69 02 c5 32 33 28 00 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 84 22 00 00 00 00 00 91 06 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [N ormal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: e0000000-e16fffff Prefetchable memory behind bridge: e2f00000-e3ffffff Capabilities: [80] Power Management version 2 00: 06 11 05 83 07 00 30 22 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 e0 d0 00 00 20: 00 e0 60 e1 f0 e2 f0 e3 00 00 00 00 00 00 00 00 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 08 00 40: cb cd 18 14 27 72 05 83 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 01 00 22 02 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) Subsystem: Asustek Computer, Inc.: Unknown device 8042 Flags: bus master, stepping, medium devsel, latency 0 Capabilities: [c0] Power Management version 2 00: 06 11 86 06 87 00 10 02 40 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 42 80 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 40: 08 41 00 00 00 80 62 ee 05 01 44 00 00 00 00 f3 50: 0e 06 00 00 00 b0 4a 30 00 04 ff 08 80 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 25 08 40 82 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 09 00 00 00 60 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 41 00 00 00 00 00 00 00 00 00 00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) [snipped] 00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI]) [snipped] 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) Subsystem: Asustek Computer, Inc.: Unknown device 8042 Flags: medium devsel, IRQ 9 Capabilities: [68] Power Management version 2 00: 06 11 57 30 00 00 90 02 40 00 00 06 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 42 80 30: 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 00 40: 20 80 49 00 12 10 00 00 01 e4 00 00 48 10 00 00 50: 00 ff ff 04 90 04 00 00 00 ff ff 00 43 10 42 80 60: 00 00 00 00 00 00 00 00 01 00 02 00 00 00 00 00 70: 01 e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 01 e8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 01 00 00 00 40 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:04.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 50) [snipped] 00:0b.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02) [snipped] 00:0b.1 Multimedia controller: Brooktree Corporation Bt878 (rev 02) [snipped] 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) [snipped] 00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02) [snipped] 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 03) (prog-if 00 [VGA]) [snipped] Stefan -- Jul 10 00:43:47 unknown kernel: Out of Memory: Killed process 24829 (eatmem). ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <no.id>]
* Re: VIA KT133A / athlon / MMX [not found] <no.id> @ 2001-07-27 20:19 ` Alan Cox 2001-07-27 20:37 ` Chris Wedgwood 0 siblings, 1 reply; 30+ messages in thread From: Alan Cox @ 2001-07-27 20:19 UTC (permalink / raw) To: PEIFFER Pierre; +Cc: linux-kernel > have not found clear answer on the different threads about this topic. > As I understand, this problem does not exist on every athlon but only on > some which work with the VIA KT133 chipset ? Right ? Its heavily tied to certain motherboards. Some people found a better PSU fixed it, others that altering memory settings helped. And in many cases, taking it back and buying a different vendors board worked. > Anyway, feel free to ask me more information if needed and please, > CC'ed me personally the answers/comments because I'm not subscribed to > the LKML. http://www.linuxhardware.org/article.pl?sid=01/06/06/1821202&mode=thread gives a good feel for the current state of play ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-27 20:19 ` Alan Cox @ 2001-07-27 20:37 ` Chris Wedgwood 2001-07-27 20:40 ` Alan Cox 2001-07-28 17:29 ` PEIFFER Pierre 0 siblings, 2 replies; 30+ messages in thread From: Chris Wedgwood @ 2001-07-27 20:37 UTC (permalink / raw) To: Alan Cox; +Cc: PEIFFER Pierre, linux-kernel On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote: Its heavily tied to certain motherboards. Some people found a better PSU fixed it, others that altering memory settings helped. And in many cases, taking it back and buying a different vendors board worked. Does anyone know *why* stuff breaks? surely VIA do as they have a fix for (some, all?) cases of breakage? My guess is its some kind of timing or near-miss on a signal edge, and the bios changes relax things so you don't miss whatever it was you missed before. --cw ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-27 20:37 ` Chris Wedgwood @ 2001-07-27 20:40 ` Alan Cox [not found] ` <3B61E5BC.5780E1E@randomlogic.com> ` (3 more replies) 2001-07-28 17:29 ` PEIFFER Pierre 1 sibling, 4 replies; 30+ messages in thread From: Alan Cox @ 2001-07-27 20:40 UTC (permalink / raw) To: Chris Wedgwood; +Cc: Alan Cox, PEIFFER Pierre, linux-kernel > On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote: > Its heavily tied to certain motherboards. Some people found a > better PSU fixed it, others that altering memory settings > helped. And in many cases, taking it back and buying a different > vendors board worked. > > Does anyone know *why* stuff breaks? surely VIA do as they have a fix > for (some, all?) cases of breakage? At the moment the big problem is I don't have enough reliable info to see patterns that I can give to VIA for study. VIAs fixes for board problems are for the fifo problem normally seen with the 686B and SB Live but sometimes in other cases. (and it seems also we have a few via + promise weirdnesses on all sorts of boards not yet explained) ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <3B61E5BC.5780E1E@randomlogic.com>]
* Re: VIA KT133A / athlon / MMX [not found] ` <3B61E5BC.5780E1E@randomlogic.com> @ 2001-07-27 22:12 ` Paul G. Allen 0 siblings, 0 replies; 30+ messages in thread From: Paul G. Allen @ 2001-07-27 22:12 UTC (permalink / raw) To: linux-kernel I meant to send this to the list, but sent it straight to Alan instead. PGA "Paul G. Allen" wrote: > > Alan Cox wrote: > > > > [SNIP] > > > > (and it seems also we have a few via + promise weirdnesses on all sorts of > > boards not yet explained) > > I happen to have one of these boards. I was rather upset with it because it would lock Linux several times a day, especially while playing games. This is part > of what drove me to purchase the K7 Thunder I now have and put the Asus A7V133 on the shelf. > > Is there anything I can do that might help track down the problem(s)? I still have the board. In fact, it is a complete system less the SB Live! and GeForce 3 > that I relocated to my K7 Thunder, and it's running a Duron 750. (I also have a second system with a SB Live! and Athlon 1.2, but I'd have to beg my wife for > its use. ;) > > PGA > -- Paul G. Allen UNIX Admin II/Programmer Akamai Technologies, Inc. www.akamai.com Work: (858)909-3630 Cell: (858)395-5043 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-27 20:40 ` Alan Cox [not found] ` <3B61E5BC.5780E1E@randomlogic.com> @ 2001-07-28 0:04 ` Kurt Garloff 2001-07-28 0:23 ` David Lang 2001-07-29 4:03 ` Gav 3 siblings, 0 replies; 30+ messages in thread From: Kurt Garloff @ 2001-07-28 0:04 UTC (permalink / raw) To: Alan Cox; +Cc: Chris Wedgwood, PEIFFER Pierre, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2832 bytes --] Hi Alan, as I stumbled across the K7 KT133 MMX problem, let me report my failure. MSI K7 Turbo Ver. 3 (BIOS 2.8). K7 1.2GHz. 256MB SDRam, tested fine by memtes86 2.7. The thing would Oops or just hand at random places at the boot process if compiled with K7 optimization. On Fri, Jul 27, 2001 at 09:40:09PM +0100, Alan Cox wrote: > > On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote: > > Its heavily tied to certain motherboards. Some people found a > > better PSU fixed it, PSU = Power supply? 300W should be fine IMHO. > > others that altering memory settings helped. Did not. Board allows you to set CL 3 which won't help (and I guess the SPDs read out 3 anyway) and to turn off some PCI features which does not help either. It does also allow you to increase mainboard speed and multiplier but not decrease! > > And in many cases, taking it back and buying a different > > vendors board worked. The best option most probably. > > Does anyone know *why* stuff breaks? surely VIA do as they have a fix > > for (some, all?) cases of breakage? > > At the moment the big problem is I don't have enough reliable info to > see patterns that I can give to VIA for study. Well, I did some testing, like reordering the MMX instructions, only using 4 instead of 8 registers, ... to no avail. It all came down to replacing movntq with movq and the thing magically works. Looks like the writes just get lost otherwise. (Maybe the sfence is just not effective? But that would be a CPU bug, not a mainboard one.) > VIAs fixes for board problems > are for the fifo problem normally seen with the 686B and SB Live but > sometimes in other cases. It also has the 686b southbridge bug, but I believe the workaound works. > (and it seems also we have a few via + promise weirdnesses on all sorts of > boards not yet explained) No Promise involved here, fortunately. garloff@gum09:~ $ /sbin/lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 50) [...] Regards, -- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, DE SCSI, Security [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-27 20:40 ` Alan Cox [not found] ` <3B61E5BC.5780E1E@randomlogic.com> 2001-07-28 0:04 ` Kurt Garloff @ 2001-07-28 0:23 ` David Lang 2001-07-28 11:11 ` Kurt Garloff 2001-07-28 12:47 ` Alan Cox 2001-07-29 4:03 ` Gav 3 siblings, 2 replies; 30+ messages in thread From: David Lang @ 2001-07-28 0:23 UTC (permalink / raw) To: Alan Cox; +Cc: cw, ppeiffer, linux-kernel I have a 1u box at my des that has two MSI boards in it with 1.2G athlons. at the moment they are both running 2.4.5 (athlon optimized), one box has no problems at all while the other dies (no video, no keyboard, etc) within an hour of being booted. systems have no sound enabled, 512MB ram, 20G ata100 drives. D-Link quad fast ethernet cards. if you have any patch you would like me to test on these boxes let me know (I am arranging to ship this one and three others like it that each have one working and one failing system in them back to the factory to get the MLB swapped out on the one that is failing. David Lang On Fri, 27 Jul 2001, Alan Cox wrote: > Date: Fri, 27 Jul 2001 21:40:09 +0100 (BST) > From: Alan Cox <alan@lxorguk.ukuu.org.uk> > To: cw@f00f.org > Cc: alan@lxorguk.ukuu.org.uk, ppeiffer@free.fr, linux-kernel@vger.kernel.org > Subject: Re: VIA KT133A / athlon / MMX > > > On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote: > > Its heavily tied to certain motherboards. Some people found a > > better PSU fixed it, others that altering memory settings > > helped. And in many cases, taking it back and buying a different > > vendors board worked. > > > > Does anyone know *why* stuff breaks? surely VIA do as they have a fix > > for (some, all?) cases of breakage? > > At the moment the big problem is I don't have enough reliable info to > see patterns that I can give to VIA for study. VIAs fixes for board problems > are for the fifo problem normally seen with the 686B and SB Live but > sometimes in other cases. > > (and it seems also we have a few via + promise weirdnesses on all sorts of > boards not yet explained) > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-28 0:23 ` David Lang @ 2001-07-28 11:11 ` Kurt Garloff 2001-07-28 11:49 ` Victor Julien 2001-07-29 0:37 ` J. Dow 2001-07-28 12:47 ` Alan Cox 1 sibling, 2 replies; 30+ messages in thread From: Kurt Garloff @ 2001-07-28 11:11 UTC (permalink / raw) To: David Lang Cc: Alan Cox, cw, ppeiffer, linux-kernel, Arjan van de Ven, Chris Brady [-- Attachment #1.1: Type: text/plain, Size: 1327 bytes --] Hi, On Fri, Jul 27, 2001 at 05:23:07PM -0700, David Lang wrote: > I have a 1u box at my des that has two MSI boards in it with 1.2G athlons. > at the moment they are both running 2.4.5 (athlon optimized), one box has > no problems at all while the other dies (no video, no keyboard, etc) > within an hour of being booted. Somebody told he had the same MoBo already replaced a couple of times ... > if you have any patch you would like me to test on these boxes let me know Well, no kernel patches. But some program which does the K7 optmizied copies and zeroing in userspace. (Attached) Strange enough it succeeds on the machine that fails to boot a K7 optimized kernel. So I'm puzzled now. Seems we can trigger problems in kernelspace that we can't have in userspace? Some problem with non-serialization if an interrupt occurs or something esoteric like this? > (I am arranging to ship this one and three others like it that each have > one working and one failing system in them back to the factory to get the > MLB swapped out on the one that is failing. Good luck! -- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, DE SCSI, Security [-- Attachment #1.2: test_movntq.c --] [-- Type: text/plain, Size: 4336 bytes --] /* test_movntq.c * Program that tests the K7 optimized routines for copying * and zeroing pages (which fail on some MoBos in the kernel). * gcc -O2 -Wall -g -fomit-frame-pointer -o test_movntq test_movntq.c * and run on AMD K7! * (c) Kurt Garloff <garloff@suse.de>, 2001-07-28, GNU GPL */ #include <stdio.h> #include <unistd.h> #include <malloc.h> #include <stdlib.h> #define PAGE_SIZE 4096 #define NR_TESTS 4096 void * fpu_ctx; double c; void trigger_fpu () { double a = 4.3; double b = rand()/ (float)RAND_MAX; c = a/b; } void movntq_copy_page0 (void* to, void* from) { //void *d0, *d1; //printf ("%p <- %p\n", to, from); asm volatile ( "\n\t prefetch (%0)" "\n\t prefetch 64(%0)" "\n\t prefetch 128(%0)" "\n\t prefetch 192(%0)" "\n\t fxsave (%3)" "\n\t prefetch 256(%0)" "\n\t movl %2, %%ecx" "\n\t fnclex" "\n\t1: prefetch 320(%0)" "\n\t movq (%0),%%mm0" "\n\t movntq %%mm0,(%1)" "\n\t movq 8(%0),%%mm1" "\n\t movntq %%mm1,8(%1)" "\n\t movq 16(%0),%%mm2" "\n\t movntq %%mm2,16(%1)" "\n\t movq 24(%0),%%mm3" "\n\t movntq %%mm3,24(%1)" "\n\t movq 32(%0),%%mm4" "\n\t movntq %%mm4,32(%1)" "\n\t movq 40(%0),%%mm5" "\n\t movntq %%mm5,40(%1)" "\n\t movq 48(%0),%%mm6" "\n\t movntq %%mm6,48(%1)" "\n\t movq 56(%0),%%mm7" "\n\t movntq %%mm7,56(%1)" /*"\n\t sfence"*/ "\n\t addl $64,%0" "\n\t addl $64,%1" "\n\t loop 1b" "\n\t movl $5, %%ecx" "\n\t2: movq (%0),%%mm0" "\n\t movntq %%mm0,(%1)" "\n\t movq 8(%0),%%mm1" "\n\t movntq %%mm1,8(%1)" "\n\t movq 16(%0),%%mm2" "\n\t movntq %%mm2,16(%1)" "\n\t movq 24(%0),%%mm3" "\n\t movntq %%mm3,24(%1)" "\n\t movq 32(%0),%%mm4" "\n\t movntq %%mm4,32(%1)" "\n\t movq 40(%0),%%mm5" "\n\t movntq %%mm5,40(%1)" "\n\t movq 48(%0),%%mm6" "\n\t movntq %%mm6,48(%1)" "\n\t movq 56(%0),%%mm7" "\n\t movntq %%mm7,56(%1)" "\n\t addl $64,%0" "\n\t addl $64,%1" "\n\t loop 2b" "\n\t sfence" "\n\t fxrstor (%3) \n" : : "r" (from), "r" (to), "i" (PAGE_SIZE/64 - 5), "r" (fpu_ctx) : "memory", "ecx" ); }; void movntq_zero_page0 (void* to) { //void *d0; //printf ("%p <- 0\n", to); asm volatile ( "\n\t fxsave (%2)" "\n\t movl %1, %%ecx" "\n\t fnclex" "\n\t pxor %%mm0, %%mm0" "\n\t1: " "\n\t movntq %%mm0,(%0)" "\n\t movntq %%mm0,8(%0)" "\n\t movntq %%mm0,16(%0)" "\n\t movntq %%mm0,24(%0)" "\n\t movntq %%mm0,32(%0)" "\n\t movntq %%mm0,40(%0)" "\n\t movntq %%mm0,48(%0)" "\n\t movntq %%mm0,56(%0)" /*"\n\t sfence"*/ "\n\t addl $64,%0" "\n\t loop 1b" "\n\t sfence" "\n\t fxrstor (%2) \n" : : "r" (to), "i" (PAGE_SIZE/64), "r" (fpu_ctx) : "memory", "ecx"); } void alloc_fpu_ctx () { fpu_ctx = (void*) memalign (256, 1024); } void fill_rand_page (void* mem) { int* ptr = (int*) mem; do { *ptr = rand(); } while (( (char*)(++ptr) - (char*)mem) < PAGE_SIZE); } void* memzero (void* mem, size_t ln) { int* ptr = (int*)mem; int i = ln / sizeof(int); while (i--) if (*ptr++ != 0) return (void*)ptr; return 0; } int main () { void *b1, *b2, *b3; void* err; int i; srand (5); alloc_fpu_ctx (); trigger_fpu (); b3 = b1 = (void*) memalign (PAGE_SIZE, (NR_TESTS+1)*PAGE_SIZE); fill_rand_page (b1); for (i = 0; i < NR_TESTS; i++) { b2 = (void*) ((char*)b3 + PAGE_SIZE); movntq_copy_page0 (b2, b3); if (memcmp (b3, b2, PAGE_SIZE)) { printf ("Error (%i)!\n", i); exit (1); } movntq_zero_page0 (b3); if ((err = memzero (b3, PAGE_SIZE))) { printf ("Error! (%i) %p\n", i, err); exit (2); } b3 = b2; } free (b1); free (fpu_ctx); return 0; } [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-28 11:11 ` Kurt Garloff @ 2001-07-28 11:49 ` Victor Julien 2001-07-29 0:37 ` J. Dow 1 sibling, 0 replies; 30+ messages in thread From: Victor Julien @ 2001-07-28 11:49 UTC (permalink / raw) To: linux-kernel Do these problems also affect Durons? I have a MSI K7T Turbo-R with Via KT133A and I have nog problems at all. I even run my Duron 600 at 866(!) (6,5 * 133) for several months now. Now I wonder if I could get problems when i upgrade to a tbird at 1,4 ghz. I have a 300 PSU. Victor ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-28 11:11 ` Kurt Garloff 2001-07-28 11:49 ` Victor Julien @ 2001-07-29 0:37 ` J. Dow 1 sibling, 0 replies; 30+ messages in thread From: J. Dow @ 2001-07-29 0:37 UTC (permalink / raw) To: Kurt Garloff, David Lang Cc: Alan Cox, cw, ppeiffer, linux-kernel, Arjan van de Ven, Chris Brady From: "Kurt Garloff" <garloff@suse.de> On Fri, Jul 27, 2001 at 05:23:07PM -0700, David Lang wrote: > I have a 1u box at my des that has two MSI boards in it with 1.2G athlons. > at the moment they are both running 2.4.5 (athlon optimized), one box has > no problems at all while the other dies (no video, no keyboard, etc) > within an hour of being booted. Somebody told he had the same MoBo already replaced a couple of times ... Kurt, et al, I have been following this VIA vs Linux thing for some time now. (My "big machine" is an Athlon based system. So it interests me.) Comments have been made about the size of power supply needed to keep these systems happy with 400 watts coming up in discussions frequently. But if you pause to think on it a few minutes you begin to wonder about this concept. The RAM runs at about 3.3 volts. The CPU core runs at about 1.7v (in my case.) So both of these are running off of power supplies on the motherboards that take the 5 volts down to something reasonable. If the problem is inadequate power supply AND it is more of a problem with some motherboards than others I look for the volts. Where are the losses which could cause this. One source is the connector from the power supply to the motherboard. (This was a chronic problem with A2000s, for example.) I don't see newer style connectors that have less contact resistance on any systems. That is probably a factor. Since the problem is greater with some boards than others I suspect that the auxilliary power sipplies on the motherboards are better for some boards than for others. Somebody with hardware access to a sufficient variety of mother- boards should survey this. Do they all use exactly the same power supply parts? Another issue is the speed of these systems. And the Athlon problem seems to peak when driving the various buses at their peaks. RF crosstalk is an issue that a lot of digital designers claim to understand when they design (and model) their circuits. Now, I built my first circuit analysis program back in about 1975. Results of that work fly on GPS satellites today. Since it was MY program I used for design I was acutely aware of its deficiencies as well as the modeling deficiencies. At some point in the analysis you cut a corner or two in order to make the calculations tractable. You do not manage to get all the "strays" into the models. What I ams saying is that board layout is another area where problems may exist. These are not thigs software settings in the VIA chips can cure. On another mailinglist catering to developers for very exotic video cards some problems with the latest INTEL based motherboards are appearing. (DigiSuite:E and its kith and kin drive the PCI bus very hard.) I suspect we have a situation not properly anticipated in modeling the backplanes on all these boards. And until the designers can wrap their minds around the entire problem the software solution may simply be, in the words of an old philospher, "Slow down! You move too fast." At the same time someone with suitable test equipment needs to look for voltage glitches out of the motherboard regulators and we need to develop software tools for "forcing" the suspected crosstalk and ideally characterising it with regards to data passing on the bus at the time of the bad data transfer. The software based fixes seem to be shooting at black cats in a coal mine without a flashlight or IR goggles. {^_^} Joanne Dow, jdow@earthlink.net ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-28 0:23 ` David Lang 2001-07-28 11:11 ` Kurt Garloff @ 2001-07-28 12:47 ` Alan Cox 2001-07-31 19:53 ` David Lang 1 sibling, 1 reply; 30+ messages in thread From: Alan Cox @ 2001-07-28 12:47 UTC (permalink / raw) To: David Lang; +Cc: Alan Cox, cw, ppeiffer, linux-kernel > I have a 1u box at my des that has two MSI boards in it with 1.2G athlons. > at the moment they are both running 2.4.5 (athlon optimized), one box has > no problems at all while the other dies (no video, no keyboard, etc) > within an hour of being booted. Same bios, same bios settings ? lspci -vxx on both show the same settings ? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-28 12:47 ` Alan Cox @ 2001-07-31 19:53 ` David Lang 0 siblings, 0 replies; 30+ messages in thread From: David Lang @ 2001-07-31 19:53 UTC (permalink / raw) To: Alan Cox; +Cc: cw, ppeiffer, linux-kernel [-- Attachment #1: Type: TEXT/PLAIN, Size: 1006 bytes --] I have not had a chance to examine all the BIOS settings but attached are the lspci -vxx for 10 different systems with identical hardware configs. the ones that end in .good have given me no problems, the three ending in .bad die after a while. the framewall-b system dies with all LEDs on the network card lit, all others die with no LEDs on. David Lang On Sat, 28 Jul 2001, Alan Cox wrote: > Date: Sat, 28 Jul 2001 13:47:40 +0100 (BST) > From: Alan Cox <alan@lxorguk.ukuu.org.uk> > To: dlang@diginsite.com > Cc: alan@lxorguk.ukuu.org.uk, cw@f00f.org, ppeiffer@free.fr, > linux-kernel@vger.kernel.org > Subject: Re: VIA KT133A / athlon / MMX > > > I have a 1u box at my des that has two MSI boards in it with 1.2G athlons. > > at the moment they are both running 2.4.5 (athlon optimized), one box has > > no problems at all while the other dies (no video, no keyboard, etc) > > within an hour of being booted. > > Same bios, same bios settings ? > > lspci -vxx on both show the same settings ? > [-- Attachment #2: Type: APPLICATION/octet-stream, Size: 71680 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-27 20:40 ` Alan Cox ` (2 preceding siblings ...) 2001-07-28 0:23 ` David Lang @ 2001-07-29 4:03 ` Gav 2001-07-29 16:10 ` Mike Frisch 2001-07-30 7:15 ` Steffen Persvold 3 siblings, 2 replies; 30+ messages in thread From: Gav @ 2001-07-29 4:03 UTC (permalink / raw) To: linux-kernel On Friday 27 July 2001 20:40, Alan Cox wrote: > > On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote: > > Its heavily tied to certain motherboards. Some people found a > > better PSU fixed it, others that altering memory settings > > helped. And in many cases, taking it back and buying a different > > vendors board worked. > > > > Does anyone know *why* stuff breaks? surely VIA do as they have a fix > > for (some, all?) cases of breakage? > > At the moment the big problem is I don't have enough reliable info to > see patterns that I can give to VIA for study. VIAs fixes for board > problems are for the fifo problem normally seen with the 686B and SB Live > but sometimes in other cases. > > (and it seems also we have a few via + promise weirdnesses on all sorts of > boards not yet explained) Just FYI, I've been running 2.4.7-pre6 for a few weeks on a Abit-KT7-a (hpt370) that uses the KT133/VIA chipset, with a 1.33Ghz Athlon and the kernel compiled for an Athlon. The machine is now rock solid. I've given it the usual tests, k7burn for 5 hours, cp'ing 30G+ across drives a few times etc, and all is good. The broken sound (crackle/pop) with my SB128PCI (same problem as SBLive) still didn't go away though, but enabling PCI DRAM PREFETCH on the VT8363 Bus-PCI Bridge does cure it. This took me a while to find as I can't set this in my bios, but powertweak came to the rescue. While DRAM Prefetch is supposed to be an option to increase performance, my sound is totally unusable without this set. I've heard numerous people explain the same problem and it would be interesting to find out if this cures their sound troubles too. If this is the case, is this something that belongs in quirks, or is it too hardware specific? and would enabling this by default hurt anything anyway? Or is this just masking the underlaying problem ? -- Regards, Gavin Baker ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-29 4:03 ` Gav @ 2001-07-29 16:10 ` Mike Frisch 2001-07-30 7:15 ` Steffen Persvold 1 sibling, 0 replies; 30+ messages in thread From: Mike Frisch @ 2001-07-29 16:10 UTC (permalink / raw) To: linux-kernel On Sun, Jul 29, 2001 at 04:03:29AM +0000, Gav wrote: > The machine is now rock solid. I've given it the usual tests, k7burn for 5 > hours, cp'ing 30G+ across drives a few times etc, and all is good. Sorry to jump in here, but where can I get "k7burn"? I've searched on google.com for it and cannot find any reference. I am running 2.4.7-ac2 (with Athlon optimizations) with an AMD T-Bird 1.2GHz on an ASUS A7A266 and it appears quite stable. I would like to see how it fares with this burn-in program you speak of. Thanks, Mike. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-29 4:03 ` Gav 2001-07-29 16:10 ` Mike Frisch @ 2001-07-30 7:15 ` Steffen Persvold 2001-07-30 10:17 ` Maciej Zenczykowski 2001-07-30 13:59 ` Gav 1 sibling, 2 replies; 30+ messages in thread From: Steffen Persvold @ 2001-07-30 7:15 UTC (permalink / raw) To: Gav; +Cc: linux-kernel Gav wrote: > Just FYI, I've been running 2.4.7-pre6 for a few weeks on a Abit-KT7-a > (hpt370) that uses the KT133/VIA chipset, with a 1.33Ghz Athlon and the > kernel compiled for an Athlon. > > The machine is now rock solid. I've given it the usual tests, k7burn for 5 > hours, cp'ing 30G+ across drives a few times etc, and all is good. > > The broken sound (crackle/pop) with my SB128PCI (same problem as SBLive) > still didn't go away though, but enabling PCI DRAM PREFETCH on the VT8363 > Bus-PCI Bridge does cure it. This took me a while to find as I can't set this > in my bios, but powertweak came to the rescue. > > While DRAM Prefetch is supposed to be an option to increase performance, my > sound is totally unusable without this set. I've heard numerous people > explain the same problem and it would be interesting to find out if this > cures their sound troubles too. If this is the case, is this something that > belongs in quirks, or is it too hardware specific? and would enabling this by > default hurt anything anyway? Or is this just masking the underlaying problem > ? Hmm, I think "DRAM Prefetch" is the one you _don't_ want to turn on, because (and correct me if i'm wrong) it's causing all the problems with the IDE controller (data trashing). Regards, -- Steffen Persvold Systems Engineer Email : mailto:sp@scali.no Scali AS (http://www.scali.com) Tlf : (+47) 22 62 89 50 Olaf Helsets vei 6 Fax : (+47) 22 62 89 51 N-0621 Oslo, Norway ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-30 7:15 ` Steffen Persvold @ 2001-07-30 10:17 ` Maciej Zenczykowski 2001-07-30 14:35 ` Luigi Genoni 2001-07-30 13:59 ` Gav 1 sibling, 1 reply; 30+ messages in thread From: Maciej Zenczykowski @ 2001-07-30 10:17 UTC (permalink / raw) To: Steffen Persvold; +Cc: Gav, linux-kernel > Hmm, I think "DRAM Prefetch" is the one you _don't_ want to turn on, because (and correct > me if i'm wrong) it's causing all the problems with the IDE controller (data trashing). I think it was IDE Prefetch that should be off (I had this problem on a AMD 486DX4-133 with Award Bios, turning it on trashed the boot record in minutes (and many other sectors on the disk too). Anyone here care to give a link to that program to enable DRAM Prefetch? My sister has a Duron 750w with VIA motherboard and music and sound pop on any graphics changes, maybe this is it? Regards, Maciej Zenczykowski ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-30 10:17 ` Maciej Zenczykowski @ 2001-07-30 14:35 ` Luigi Genoni 0 siblings, 0 replies; 30+ messages in thread From: Luigi Genoni @ 2001-07-30 14:35 UTC (permalink / raw) To: Maciej Zenczykowski; +Cc: Steffen Persvold, Gav, linux-kernel I have this bios setting enabled, and no problems at all on two of my athlons with VIA KT133A, kernel 2.4.7. >From this full discussion comes out a big confusion. For what I saw, many VIA KT133A do work well, many other give problems to their sysadmins. but the chipset is almost the same, and the processors are quite the same (they are all athlon, I read no bug reports about duron). this is enought for me to get confused. My production systems do use scsi disks, and i can understand they donot have troubles (adaptec 2940, 2980 29160....). But also the ones with IDE disks are working quite well (some using ata33, others ata100). I NEVER used DDRAM, just normal SDRAM 133 Mhz. So I was thinking to FSB. All my systems with ide disks have 200MhzFSB, (while my latest production systems do have 266 MhzFSB). Maybe a 266 MhzFSB is just too mutch stress for some via chipset. But i see no clear logic when problems do appear, or any big difference with systems that are rock solid. lets' try to make a point to see a logic for those instabilities... which kind of hardware bug is this, if the same chipset can work or not depending if you are lucky? or a full stock of chipset is buggy and with a certain HW configuration you will see the bug or what? Luigi On Mon, 30 Jul 2001, Maciej Zenczykowski wrote: > > Hmm, I think "DRAM Prefetch" is the one you _don't_ want to turn on, because (and correct > > me if i'm wrong) it's causing all the problems with the IDE controller (data trashing). > > I think it was IDE Prefetch that should be off (I had this problem on a > AMD 486DX4-133 with Award Bios, turning it on trashed the boot record in > minutes (and many other sectors on the disk too). > > Anyone here care to give a link to that program to enable DRAM Prefetch? > My sister has a Duron 750w with VIA motherboard and music and sound pop on > any graphics changes, maybe this is it? > > Regards, > > Maciej Zenczykowski > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-30 7:15 ` Steffen Persvold 2001-07-30 10:17 ` Maciej Zenczykowski @ 2001-07-30 13:59 ` Gav 1 sibling, 0 replies; 30+ messages in thread From: Gav @ 2001-07-30 13:59 UTC (permalink / raw) To: linux-kernel On Monday 30 July 2001 07:15, Steffen Persvold wrote: > > While DRAM Prefetch is supposed to be an option to increase performance, > > my sound is totally unusable without this set. I've heard numerous people > > explain the same problem and it would be interesting to find out if this > > cures their sound troubles too. If this is the case, is this something > > that belongs in quirks, or is it too hardware specific? and would > > enabling this by default hurt anything anyway? Or is this just masking > > the underlaying problem ? > > Hmm, I think "DRAM Prefetch" is the one you _don't_ want to turn on, > because (and correct me if i'm wrong) it's causing all the problems with > the IDE controller (data trashing). Obviously I can only comment on my own hardware but the machine has been used constantly since Thu Jul 12, its now Jul 30 and I havent had a single IDE related problem. As a hobby, i use the machine for DigitalVideo, and regularly grab 20-30GB from my capture card, then process it, which means the IDE bus gets a lot of use and seems to be an ideal situation for the data trashing problems to rear their ugly heads (no pun intended) but, as i said, I haven't seen any here. DRAM Prefetch makes my sound usuable, as the VIA fixups for the SB cards do not work here, and for (at least) two other people who i have had email correspondancy with. -- Regards, Gavin Baker ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-27 20:37 ` Chris Wedgwood 2001-07-27 20:40 ` Alan Cox @ 2001-07-28 17:29 ` PEIFFER Pierre 2001-07-28 12:21 ` Kurt Garloff 1 sibling, 1 reply; 30+ messages in thread From: PEIFFER Pierre @ 2001-07-28 17:29 UTC (permalink / raw) To: linux-kernel Chris Wedgwood a écrit : > > On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote: > > Its heavily tied to certain motherboards. Some people found a > better PSU fixed it, others that altering memory settings > helped. And in many cases, taking it back and buying a different > vendors board worked. > > My guess is its some kind of timing or near-miss on a signal edge, and > the bios changes relax things so you don't miss whatever it was you > missed before. > Ok, after reading that, I've tried to see if my BIOS setting changes were implicated or not. And I've found a winner: Disabling option "Enhance Chip Performance" makes kernel K7-mmx routines work fine. Enabling it causes the kernel crash at boot time... (And I haved it enable) FYI, according to the user's manual, enabling this option "set the north bridge chipset timing parameters more aggressively providing higher system performance" (Default value is 'disable'). I can't say more about what it does exactly. I don't know if this will help you to locate the problem, but at least, Abit's users will be warned... Thanks for your help ! Pierre ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-28 17:29 ` PEIFFER Pierre @ 2001-07-28 12:21 ` Kurt Garloff 2001-07-28 22:00 ` PEIFFER Pierre 0 siblings, 1 reply; 30+ messages in thread From: Kurt Garloff @ 2001-07-28 12:21 UTC (permalink / raw) To: PEIFFER Pierre; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 713 bytes --] On Sat, Jul 28, 2001 at 01:29:04PM -0400, PEIFFER Pierre wrote: > FYI, according to the user's manual, enabling this option "set the north > bridge chipset timing parameters more aggressively providing higher > system performance" (Default value is 'disable'). I can't say more about > what it does exactly. A lspci -vxxx of your northbridge with adn without the BIOS option will reveal more. Regards, -- Kurt Garloff <kurt@garloff.de> [Eindhoven, NL] Physics: Plasma simulations <K.Garloff@Phys.TUE.NL> [TU Eindhoven, NL] Linux: SCSI, Security <garloff@suse.de> [SuSE Nuernberg, DE] (See mail header or public key servers for PGP2 and GPG public keys.) [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-28 12:21 ` Kurt Garloff @ 2001-07-28 22:00 ` PEIFFER Pierre 2001-07-29 20:28 ` Kurt Garloff 0 siblings, 1 reply; 30+ messages in thread From: PEIFFER Pierre @ 2001-07-28 22:00 UTC (permalink / raw) To: Kurt Garloff; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 437 bytes --] Kurt Garloff a écrit : > > A lspci -vxxx of your northbridge with adn without the BIOS option will > reveal more. In attached files are the result. I've only kept the (what I suppose to be) northbridge info. This doesn't tell me anything... Note: both has been done after booting on Mandrake-kernel 2.4.3 which come with Mandrake distribution (i.e. with lot of patches and options...) I don't know the impact on the result... Pierre [-- Attachment #2: lspci_opt_disable.txt --] [-- Type: text/plain, Size: 1142 bytes --] 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03) Subsystem: ABIT Computer Corp.: Unknown device a401 Flags: bus master, medium devsel, latency 0 Memory at d8000000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 00 00 00 10: 08 00 00 d8 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 7b 14 01 a4 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 17 a3 eb b4 02 00 10 10 c0 00 08 10 10 10 10 10 60: 03 aa 02 20 e6 d6 d6 c6 51 28 43 0d 08 3f 00 00 70: d4 88 cc 0c 0e 81 62 00 01 b4 19 02 00 00 00 00 80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 32 00 00 a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2b 12 14 00 b0: 49 da 00 60 31 ff 80 05 67 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 00 00 [-- Attachment #3: lspci_opt_enable.txt --] [-- Type: text/plain, Size: 1142 bytes --] 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03) Subsystem: ABIT Computer Corp.: Unknown device a401 Flags: bus master, medium devsel, latency 8 Memory at d8000000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 08 00 00 10: 08 00 00 d8 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 7b 14 01 a4 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 17 a3 eb b4 43 89 10 10 c0 00 08 10 10 10 10 10 60: 03 aa 02 20 e6 d6 d6 c6 45 28 43 0f 08 3f 00 00 70: d4 88 cc 0c 0e 81 62 00 01 b4 19 02 00 00 00 00 80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 32 00 00 a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2f 12 14 00 b0: 49 da 88 60 31 ff 80 05 67 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 91 06 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-28 22:00 ` PEIFFER Pierre @ 2001-07-29 20:28 ` Kurt Garloff 2001-07-30 6:04 ` Daniela Engert 0 siblings, 1 reply; 30+ messages in thread From: Kurt Garloff @ 2001-07-29 20:28 UTC (permalink / raw) To: PEIFFER Pierre; +Cc: linux-kernel, Bart Hartgers [-- Attachment #1: Type: text/plain, Size: 3265 bytes --] Hi Pierre, thanks for your info! On Sat, Jul 28, 2001 at 06:00:11PM -0400, PEIFFER Pierre wrote: > Kurt Garloff a écrit : > In attached files are the result. I've only kept the (what I suppose to > be) northbridge info. > This doesn't tell me anything... Me neither. I was hoping that only a bit differs. Unfortunately that's not the case, so I need to have a look in the datasheet. But those are not publically available :-( Anybody having them? > Note: both has been done after booting on Mandrake-kernel 2.4.3 which > come with Mandrake distribution (i.e. with lot of patches and > options...) I don't know the impact on the result... With a newer lspci you would have seen that 1106:0305 is VT8363/8365 [KT133/KM133]. I removed everything except for the differences. Underlined. Anybody able to decode? Otherwise trying out all of them can get boring. (Well, I'd start with 0x68, followed by 0x6b and 0xac ...) Working: > 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03) > Subsystem: ABIT Computer Corp.: Unknown device a401 > Flags: bus master, medium devsel, latency 0 ^ This looks wrong to me. > Memory at d8000000 (32-bit, prefetchable) [size=64M] > Capabilities: [a0] AGP version 2.0 > Capabilities: [c0] Power Management version 2 > 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 00 00 00 ^ Latency. > 50: 17 a3 eb b4 02 00 10 10 c0 00 08 10 10 10 10 10 ^^ ^^ > 60: 03 aa 02 20 e6 d6 d6 c6 51 28 43 0d 08 3f 00 00 ^^ ^^ > a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2b 12 14 00 ^^ > b0: 49 da 00 60 31 ff 80 05 67 00 00 00 00 00 00 00 ^^ > f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 00 00 ^^ ^^ Buggy: (Own, buggy settings in parens) > 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03) > Subsystem: ABIT Computer Corp.: Unknown device a401 > Flags: bus master, medium devsel, latency 8 ^ That's more reasonable. > Memory at d8000000 (32-bit, prefetchable) [size=64M] > Capabilities: [a0] AGP version 2.0 > Capabilities: [c0] Power Management version 2 > 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 08 00 00 ^ Latency > 50: 17 a3 eb b4 43 89 10 10 c0 00 08 10 10 10 10 10 ^^ ^^ (47 8d here) > 60: 03 aa 02 20 e6 d6 d6 c6 45 28 43 0f 08 3f 00 00 ^^ ^^ (41 .. 21 here) > a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2f 12 14 00 ^^ (6b here) > b0: 49 da 88 60 31 ff 80 05 67 00 00 00 00 00 00 00 ^^ (22 here) > f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 91 06 ^^ ^^ (00 00 here) Regards, -- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, DE SCSI, Security [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-29 20:28 ` Kurt Garloff @ 2001-07-30 6:04 ` Daniela Engert 2001-07-30 13:44 ` Kurt Garloff 0 siblings, 1 reply; 30+ messages in thread From: Daniela Engert @ 2001-07-30 6:04 UTC (permalink / raw) To: linux-kernel Hi Kurt! On Sun, 29 Jul 2001 22:28:30 +0200, Kurt Garloff wrote: >Me neither. I was hoping that only a bit differs. Unfortunately that's not >the case, so I need to have a look in the datasheet. >But those are not publically available :-( >Anybody having them? Try to get a clue yourself from the WPCREDIT KT133 plugin (see below, stripped down to the differing registers). Some differences look suspicious to me... >Working: >> 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 00 00 00 > ^ Latency. >> 50: 17 a3 eb b4 02 00 10 10 c0 00 08 10 10 10 10 10 > ^^ ^^ >> 60: 03 aa 02 20 e6 d6 d6 c6 51 28 43 0d 08 3f 00 00 > ^^ ^^ >> a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2b 12 14 00 > ^^ >> b0: 49 da 00 60 31 ff 80 05 67 00 00 00 00 00 00 00 > ^^ >> f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 00 00 ^^ ^^ >Buggy: (Own, buggy settings in parens) >> 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 08 00 00 > ^ Latency >> 50: 17 a3 eb b4 43 89 10 10 c0 00 08 10 10 10 10 10 > ^^ ^^ (47 8d here) >> 60: 03 aa 02 20 e6 d6 d6 c6 45 28 43 0f 08 3f 00 00 > ^^ ^^ (41 .. 21 here) >> a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2f 12 14 00 > ^^ (6b here) >> b0: 49 da 88 60 31 ff 80 05 67 00 00 00 00 00 00 00 > ^^ (22 here) >> f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 91 06 > ^^ ^^ (00 00 here) PCR(PCI Configration Registers) Editor / WPCREDIT for WIN32 Copyright (c) 2000 H.Oda! [COMMENT]=for HWup ng. members (Kx) edited by Guruad tnx to author H.Oda! [MODEL]=VT8363 (KT133) [VID]=1106:VIA [DID]=0305:Host to PCI Bridge [54:7]=SDRAM Self-Refresh 0=disable 1=enable [54:6]=Probe Next Tag State T1 0=disable 1=enable [54:5]=High Priority DRAM Req. 0=disable 1=enable [54:4]=Continuous DRAM Request 0=disable 1=enable [54:3]=DRAM Speculative Read 0=disable 1=enable [54:2]=PCI Master Pipeline Req. 0=disable 1=enable [54:1]=PCI-to-CPU / CPU-to-PCI 0=disable 1=enable [54:0]=Fast Write-to-Read 0=disable 1=enable [55:0]=S2K Compensation CPU Halt0=disable 1=enable [68:7]=SDRAM Open Page Control 0=precharge 1=remain act [68:6]=Bank Page Control 0=same bank 1=different [68:5]=(Reserved) [68:4]=DRAM Data Latch Delay 0=Latch 1=Delay latch [68:3]=EDO Test Mode 0=disable 1=enable [68:2]=Burst Refresh(4 times) 0=disable 1=enable [68:1]=System Frequency Divider 00= 66 MHz 01=100 MHz [68:0]=10=133 MHz 11=Reserved [6B:7]=Arbitration Parking Pol. 00=bus owner 01=CPU side [6B:6]=10=AGP side 11=Reserved [6B:5]=Fast Read to Write t-a 0=disable 1=enable [6B:4]=(Reserved) [6B:3]=MD Bus Second Level 0=Normal slew 1=More [6B:2]=CAS Bus Second Level 0=Normal slew 1=More [6B:1]=Virtual Channel-DRAM 0=disable 1=enable [6B:0]=Multi-Page Open 0=disable 1=enable [AC:7]=(Reserved) [AC:6]=AGP Read Synchronization 0=disable 1=enable [AC:5]=AGP Read Snoop DRAM P-W-B0=disable 1=enable [AC:4]=GREQ# Priority 0=disable 1=enable [AC:3]=2X Rate Supported 0=not 1=supported [AC:2]=LPR In-Order Access 0=not 1=executed [AC:1]=AGP Arbitration Parking 0=disable 1=enable [AC:0]=AGP-PCI Master/CPU-PCI TC0=2T or 3T 1=1T [B2:7]=GD/GBE/GDS, SBA/SBS Ctrl [B2:6]=(Reserved) [B2:5]=(Reserved) [B2:4]=GD[31-16] Staggered Delay0=none 1=1ns [B2:3]=(Reserved) [B2:2]=(Reserved) [B2:1]=AGP Voltage 0=1.5V 1=3.3V [B2:0]=GDS Output Delay 0=none 1=0.4ns [FE]=Back-Door Device ID [FF]=Back-Door Device ID '54'=BIU Control 00 RW '55'=Debug (Do Not Program) '68'=DRAM Control 00 RW '6B'=DRAM Arbitration Control 01 RW 'AC'=AGP Control 00 RW 'B2'=AGP Pad Drive / Delay Control 00 RW 'FE..FF' Back-Door Device ID 0000 RW Ciao, Dani ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Daniela Engert, systems engineer at MEDAV GmbH Gräfenberger Str. 34, 91080 Uttenreuth, Germany Phone ++49-9131-583-348, Fax ++49-9131-583-11 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-30 6:04 ` Daniela Engert @ 2001-07-30 13:44 ` Kurt Garloff 2001-07-30 14:15 ` Michael 2001-07-30 16:47 ` Daniela Engert 0 siblings, 2 replies; 30+ messages in thread From: Kurt Garloff @ 2001-07-30 13:44 UTC (permalink / raw) To: Daniela Engert; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1430 bytes --] Hi Daniela, On Mon, Jul 30, 2001 at 08:04:54AM +0200, Daniela Engert wrote: > On Sun, 29 Jul 2001 22:28:30 +0200, Kurt Garloff wrote: > > >Me neither. I was hoping that only a bit differs. Unfortunately that's not > >the case, so I need to have a look in the datasheet. > >But those are not publically available :-( > >Anybody having them? > > Try to get a clue yourself from the WPCREDIT KT133 plugin (see below, > stripped down to the differing registers). Some differences look > suspicious to me... Hey thanks! > [54:6]=Probe Next Tag State T1 0=disable 1=enable Main suspect. (Should be 0) > [54:0]=Fast Write-to-Read 0=disable 1=enable Third candidate. (Should be 0) > [68:4]=DRAM Data Latch Delay 0=Latch 1=Delay latch Second candidate (Should be 1) > [68:2]=Burst Refresh(4 times) 0=disable 1=enable Fourth candidate (Should be 0?) > [6B:5]=Fast Read to Write t-a 0=disable 1=enable Should this one match 54:0 (third candidate)? > [6B:1]=Virtual Channel-DRAM 0=disable 1=enable Strange, why does this one differ between the configs. OK, I'll come up with a kernel patches (driver/pci/quirks ...) for people to test. Regards, -- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, DE SCSI, Security [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-30 13:44 ` Kurt Garloff @ 2001-07-30 14:15 ` Michael 2001-07-30 15:46 ` Kurt Garloff 2001-07-30 16:47 ` Daniela Engert 1 sibling, 1 reply; 30+ messages in thread From: Michael @ 2001-07-30 14:15 UTC (permalink / raw) To: linux-kernel; +Cc: Kurt Garloff, Daniela Engert > > On Sun, 29 Jul 2001 22:28:30 +0200, Kurt Garloff wrote: > > [54:6]=Probe Next Tag State T1 0=disable 1=enable > > Main suspect. (Should be 0) That's set in my stable kt133a system. > > [54:0]=Fast Write-to-Read 0=disable 1=enable > > Third candidate. (Should be 0) as is this one. > > [68:2]=Burst Refresh(4 times) 0=disable 1=enable > > Fourth candidate (Should be 0?) I set this one yesterday to see if it would trigger the problem, it didn't :o/ Same with a few differences between my system and 0x6b, which didn't either. Out of curiosity, where are you getting the 'should be 0/1' details from? -- Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-30 14:15 ` Michael @ 2001-07-30 15:46 ` Kurt Garloff 2001-07-30 18:43 ` Kurt Garloff 0 siblings, 1 reply; 30+ messages in thread From: Kurt Garloff @ 2001-07-30 15:46 UTC (permalink / raw) To: Michael; +Cc: Linux kernel list, Daniela Engert [-- Attachment #1: Type: text/plain, Size: 1407 bytes --] Hi Michael, thanks for your comments! On Mon, Jul 30, 2001 at 03:15:38PM +0100, Michael wrote: > > > On Sun, 29 Jul 2001 22:28:30 +0200, Kurt Garloff wrote: > > > [54:6]=Probe Next Tag State T1 0=disable 1=enable > > > > Main suspect. (Should be 0) > > That's set in my stable kt133a system. But did you experience problems at all with your kernel when compiled for K7? Note that most (if not all) systems seem to work stable with K6 or PPro optimized kernels. > > > [54:0]=Fast Write-to-Read 0=disable 1=enable > > > > Third candidate. (Should be 0) > > as is this one. > > > > [68:2]=Burst Refresh(4 times) 0=disable 1=enable > > > > Fourth candidate (Should be 0?) > > I set this one yesterday to see if it would trigger the problem, it > didn't :o/ Same with a few differences between my system and 0x6b, which > didn't either. > > Out of curiosity, where are you getting the 'should be 0/1' details from? Comparing the lspci -vxxx output of working and non-working systems. You did no comment on the second candidate: > [68:4]=DRAM Data Latch Delay 0=Latch 1=Delay latch Second candidate (Should be 1) Regards, -- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, DE SCSI, Security [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-30 15:46 ` Kurt Garloff @ 2001-07-30 18:43 ` Kurt Garloff 2001-07-30 20:44 ` Gerbrand van der Zouw 0 siblings, 1 reply; 30+ messages in thread From: Kurt Garloff @ 2001-07-30 18:43 UTC (permalink / raw) To: Michael, Linux kernel list, Daniela Engert; +Cc: Alan Cox [-- Attachment #1.1: Type: text/plain, Size: 689 bytes --] Hi, OK, patches for different bits are attached. The patch does modify up to 4 bits, which is more than I would like to do in the end. But you can easily disable some parts of it, if the full patch proves to solve your trouble. Please test! It seemed to solved the trouble here on first sight (booting went further then normal) but in the end did not turn out to solve the trouble here. (Here means: MSI K7T Turbo (Ver.3) with AMD K7 1.2GHz.) Regards, -- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, DE SCSI, Security [-- Attachment #1.2: 247-viakt133.diff --] [-- Type: text/plain, Size: 2250 bytes --] --- linux-2.4.7.compile/drivers/pci/quirks.c.orig Tue Jul 24 16:50:41 2001 +++ linux-2.4.7.compile/drivers/pci/quirks.c Mon Jul 30 20:21:56 2001 @@ -160,6 +160,49 @@ } /* + * KT133a will fsck up under some circumstances if Burst Refresh (4 times) + * is enabled or if data latch delay is disabled + * and we use the fast streaming K7 optimized zero_page + * and copy_page routines from arch/i386/lib/mmx.c + * -- garloff@suse.de, 2001-07-30 + */ +static void __init quirk_via_noburstrefresh(struct pci_dev *dev) +{ + u8 dram_ctrl; + pci_read_config_byte(dev, 0x68, &dram_ctrl); + if (dram_ctrl & 0x04 || !(dram_ctrl & 0x10)) { + if (dram_ctrl & 0x04) + printk(KERN_INFO "VIA KT133a: Disabling burst refresh.\n"); + dram_ctrl &= ~0x04; + if (!(dram_ctrl & 0x10)) + printk(KERN_INFO "VIA KT133a: Enabling data latch delay.\n"); + dram_ctrl |= 0x10; + pci_write_config_byte(dev, 0x68, dram_ctrl); + } +} + +/* + * KT133a will fsck up under some circumstances if Probe Next Tag State + * T1 is set to 1 and we use the fast streaming K7 optimized zero_page + * and copy_page routines from arch/i386/lib/mmx.c + * -- garloff@suse.de, 2001-07-30 + */ +static void __init quirk_via_noprobenexttag(struct pci_dev *dev) +{ + u8 biu_ctrl; + pci_read_config_byte(dev, 0x54, &biu_ctrl); + if (biu_ctrl & 0x40 || biu_ctrl & 0x01) { + if (biu_ctrl & 0x40) + printk(KERN_INFO "VIA KT133a: Disabling probe next tag state T1.\n"); + if (biu_ctrl & 0x01) + printk(KERN_INFO "VIA KT133a: Disabling fast write-to-read.\n"); + biu_ctrl &= ~0x41; + pci_write_config_byte(dev, 0x54, biu_ctrl); + } +} + + +/* * Natoma has some interesting boundary conditions with Zoran stuff * at least */ @@ -452,6 +495,9 @@ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irqpic }, { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irqpic }, { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_6, quirk_via_irqpic }, + + { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8363_0, quirk_via_noburstrefresh }, + { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8363_0, quirk_via_noprobenexttag }, { 0 } }; [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-30 18:43 ` Kurt Garloff @ 2001-07-30 20:44 ` Gerbrand van der Zouw 0 siblings, 0 replies; 30+ messages in thread From: Gerbrand van der Zouw @ 2001-07-30 20:44 UTC (permalink / raw) To: Kurt Garloff; +Cc: linux-kernel Hi, Kurt Garloff wrote: > It seemed to solved the trouble here on first sight (booting went further > then normal) but in the end did not turn out to solve the trouble here. > (Here means: MSI K7T Turbo (Ver.3) with AMD K7 1.2GHz.) from your lspci output I seem to have exactly the same system as you have. I tried your patch (247-viakt133.diff) and came up with the same result here: it seemed to come further than last time with only 2.4.6ac5, but then it crashed anyway. If you know of any BIOS parameters that might help for this mobo, please let me know. I could not identify a parameter that does the same as the "DRAM Prefetch" for Abit mobos. Regards, Gerbrand van der Zouw ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: VIA KT133A / athlon / MMX 2001-07-30 13:44 ` Kurt Garloff 2001-07-30 14:15 ` Michael @ 2001-07-30 16:47 ` Daniela Engert 1 sibling, 0 replies; 30+ messages in thread From: Daniela Engert @ 2001-07-30 16:47 UTC (permalink / raw) To: Kurt Garloff; +Cc: linux-kernel Hi Kurt! On Mon, 30 Jul 2001 15:44:58 +0200, Kurt Garloff wrote: Just for reference: these are the values taken from my main machine (Epox EP8KTA2, VIA KT133) with the latest BIOS: >> [54:6]=Probe Next Tag State T1 0=disable 1=enable >Main suspect. (Should be 0) Set to 1 here. >> [54:0]=Fast Write-to-Read 0=disable 1=enable >Third candidate. (Should be 0) Set to 1 here. >> [68:4]=DRAM Data Latch Delay 0=Latch 1=Delay latch >Second candidate (Should be 1) Set to 1 here. >> [68:2]=Burst Refresh(4 times) 0=disable 1=enable >Fourth candidate (Should be 0?) Set to 0 here. >> [6B:5]=Fast Read to Write t-a 0=disable 1=enable >Should this one match 54:0 (third candidate)? Set to 0 here. >> [6B:1]=Virtual Channel-DRAM 0=disable 1=enable >Strange, why does this one differ between the configs. Set to 0 here. Unfortunately, this machine doesn't run Linux... Ciao, Dani ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2001-07-31 21:09 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-28 1:42 VIA KT133A / athlon / MMX PEIFFER Pierre
2001-07-30 21:33 ` Stefan Becker
[not found] <no.id>
2001-07-27 20:19 ` Alan Cox
2001-07-27 20:37 ` Chris Wedgwood
2001-07-27 20:40 ` Alan Cox
[not found] ` <3B61E5BC.5780E1E@randomlogic.com>
2001-07-27 22:12 ` Paul G. Allen
2001-07-28 0:04 ` Kurt Garloff
2001-07-28 0:23 ` David Lang
2001-07-28 11:11 ` Kurt Garloff
2001-07-28 11:49 ` Victor Julien
2001-07-29 0:37 ` J. Dow
2001-07-28 12:47 ` Alan Cox
2001-07-31 19:53 ` David Lang
2001-07-29 4:03 ` Gav
2001-07-29 16:10 ` Mike Frisch
2001-07-30 7:15 ` Steffen Persvold
2001-07-30 10:17 ` Maciej Zenczykowski
2001-07-30 14:35 ` Luigi Genoni
2001-07-30 13:59 ` Gav
2001-07-28 17:29 ` PEIFFER Pierre
2001-07-28 12:21 ` Kurt Garloff
2001-07-28 22:00 ` PEIFFER Pierre
2001-07-29 20:28 ` Kurt Garloff
2001-07-30 6:04 ` Daniela Engert
2001-07-30 13:44 ` Kurt Garloff
2001-07-30 14:15 ` Michael
2001-07-30 15:46 ` Kurt Garloff
2001-07-30 18:43 ` Kurt Garloff
2001-07-30 20:44 ` Gerbrand van der Zouw
2001-07-30 16:47 ` Daniela Engert
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).