Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability
I don't know if it's the motherboard, but I've got a KT7A-RAID, and I haven't been able to run any 2.4.x that I've tried. I was worried, because this board also has new RAM, but 2.2.x doesn't have any problems at all. I've tried: 2.4.2 2.4.3 2.4.3-ac9 2.4.3-ac11 Someone else mentioned stability problems with nVida and AGP, which I'm also using. It's true that I've only experienced lockups under X. Things I haven't tried, but should (and will, once finals are over): 2.4.x, unoptimised 2.4.x, optimised, disable AGP I'm running Debian unstable (but it's not unstable with 2.2.x :) -- --Ray - Sotto la panca la capra crepa sopra la panca la capra campa - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
> Mandrake 8's kernel comes with i586 CPU support, it is alredy known it > works. Remember that the instability occurs only when Athlon optimizations > are used. You are right. But I like to point out that on my Athlon kernel 2.4.3 is working fine. The first kernel I face problems is 2.4.3-ac7. I also know that the problem occurs of kernel 2.4.4. That might help to find the problem. - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
> No matter if I use the mandrake 8 gcc 2.96 or a self compiled gcc 2.95.3. Mandrake 8's kernel comes with i586 CPU support, it is alredy known it works. Remember that the instability occurs only when Athlon optimizations are used. - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
>Maybe, but the IWILL board is the only one we've heard about problems with. I have also stability problems with an ASUS A7V133. I already have the 1004-d2 bios which should fix the VIA IDE problems. But my hard drives are connected to the promise controller of the board. Only 2 CD-drives are on teh VIA-Chip. I am quite sure that my problem was introduced with 2.4.3-ac7, because, the board is rock solid up to kernel 2.4.3-ac6 or with the Madrake 8 kernel. But If I try to put some load on 2.4.3-ac7 or above I get lock ups. Even the magic sysrq does not work. No matter if compiled for athlon Pentium II or 586. No matter if I use the mandrake 8 gcc 2.96 or a self compiled gcc 2.95.3. The problem also occurs on kernel 2.4.4. Bytheway there is a thread called "ABit KT7A-RAIN random lock ups " It might be related to one of the Athlon/VIA problems. greetings Christian - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Maybe, but the IWILL board is the only one we've heard about problems with. I have also stability problems with an ASUS A7V133. I already have the 1004-d2 bios which should fix the VIA IDE problems. But my hard drives are connected to the promise controller of the board. Only 2 CD-drives are on teh VIA-Chip. I am quite sure that my problem was introduced with 2.4.3-ac7, because, the board is rock solid up to kernel 2.4.3-ac6 or with the Madrake 8 kernel. But If I try to put some load on 2.4.3-ac7 or above I get lock ups. Even the magic sysrq does not work. No matter if compiled for athlon Pentium II or 586. No matter if I use the mandrake 8 gcc 2.96 or a self compiled gcc 2.95.3. The problem also occurs on kernel 2.4.4. Bytheway there is a thread called ABit KT7A-RAIN random lock ups It might be related to one of the Athlon/VIA problems. greetings Christian - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
No matter if I use the mandrake 8 gcc 2.96 or a self compiled gcc 2.95.3. Mandrake 8's kernel comes with i586 CPU support, it is alredy known it works. Remember that the instability occurs only when Athlon optimizations are used. - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Mandrake 8's kernel comes with i586 CPU support, it is alredy known it works. Remember that the instability occurs only when Athlon optimizations are used. You are right. But I like to point out that on my Athlon kernel 2.4.3 is working fine. The first kernel I face problems is 2.4.3-ac7. I also know that the problem occurs of kernel 2.4.4. That might help to find the problem. - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
I don't know if it's the motherboard, but I've got a KT7A-RAID, and I haven't been able to run any 2.4.x that I've tried. I was worried, because this board also has new RAM, but 2.2.x doesn't have any problems at all. I've tried: 2.4.2 2.4.3 2.4.3-ac9 2.4.3-ac11 Someone else mentioned stability problems with nVida and AGP, which I'm also using. It's true that I've only experienced lockups under X. Things I haven't tried, but should (and will, once finals are over): 2.4.x, unoptimised 2.4.x, optimised, disable AGP I'm running Debian unstable (but it's not unstable with 2.2.x :) -- --Ray - Sotto la panca la capra crepa sopra la panca la capra campa - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
>> I'm using an Abit KT7 board (KT133) and my new 1GHz T'bird (running 50-60°C >> in a warm room) is giving me no trouble. This is with the board and RAM >> pushed as fast as it will go without actually overclocking anything... and >> yes, I do have Athlon/K7 optimisations turned on in my kernel (2.4.3). >> > > I wonder if the KT133A (which is what the IWILL KK266 is based on) >differences >a could be a source of the problem. My FSB is at plain old 100 MHz >since I >have regular PC100 SDRAM. Overclocked, or not, I get the same results. >I, >too, had an ABIT KA7[-RAID] and it was rock solid. So much for "if it's >not broke, don't fix it" -- I should have listened to my gf, but that's >the life of an upgrader ;)... In general the IWILL got great reviews at >a >number of reliable hardware review sites, and hey, it doesn't lock up in >windows ;) (ok don't flame me for that ;)). Maybe, but the IWILL board is the only one we've heard about problems with. The Abit KT7A (which also has the KT133A chipset and is otherwise identical to the KT7) would appear to run smoothly, although I don't actually *have* one of those. Probably the Windows drivers turn off some feature of the IWILL board which is known to be flaky. I suggest setting *everything* in the BIOS to the "most conservative" settings and seeing if the problem persists. If so, then it can't be a hardware-speed-limitation problem, and there's clearly something we have to turn off "manually". Also, try running memtest86 and see if that is capable of triggering the problem. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Jonathan Morton wrote: > > I'm using an Abit KT7 board (KT133) and my new 1GHz T'bird (running 50-60°C > in a warm room) is giving me no trouble. This is with the board and RAM > pushed as fast as it will go without actually overclocking anything... and > yes, I do have Athlon/K7 optimisations turned on in my kernel (2.4.3). > I wonder if the KT133A (which is what the IWILL KK266 is based on) differences a could be a source of the problem. My FSB is at plain old 100 MHz since I have regular PC100 SDRAM. Overclocked, or not, I get the same results. I, too, had an ABIT KA7[-RAID] and it was rock solid. So much for "if it's not broke, don't fix it" -- I should have listened to my gf, but that's the life of an upgrader ;)... In general the IWILL got great reviews at a number of reliable hardware review sites, and hey, it doesn't lock up in windows ;) (ok don't flame me for that ;)). --Seth - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Thanks moses -- this is the instability that I have as well. I tried compiling on 1/2 of the k7 optimized mmx routines. So far, running with JUST the fast_clear_page using k7 streaming (and not fast_copy_page), the system is still stable. I'll try adding fast_copy _page, but I think that's where our problems lie (of course I could be full of crap, too). --S Moses McKnight wrote: > > Mark Hahn wrote: > > >> Actually, I think there are 2 problems that have been discussed -- the > >>disk corruption and a general instability resulting in oops'es at > >>various points shortly after boot up. > >> > > > > I don't see this. specifically, there were scattered reports > > of a via-ide problem a few months ago; this is the issue that's > > gotten some press, and for which Alan has a fix. and there are reports > > of via-smp problems at boot (which go away with noapic). I see no reports > > of the kind of general instability you're talking about. and all the > > via-users I've heard of have no such stability problems - > > me included (kt133/duron). > > > > the only general issue is that kx133 systems seem to be difficult > > to configure for stability. ugly things like tweaking Vio. > > there's no implication that has anything to do with Linux, though. > > When I reported my problem a couple weeks back another fellow > said he and several others on the list had the same problem, > and as far as I can tell it is *only* with the IWILL boards. > When I compiled with k7 optimizations I'd get all kinds of oopses > and panics and never fully boot. They were different every time. > When any of the lesser optimizations are used I have no problems. > My memory is one 256MB Corsair PC150 dimm, CPU is a Thunderbird 850, > and mobo is an IWILL KK266 (KT133A). The CPU runs between 35°C > and 40°C. > > >> My memory system jas been set up very conservitavely and has been > >>rock solid in my other board (ka7), so I doubt it's that, but I > >>sure am happy to try a few more cominations of bios settings. Anything > >>I should look for in particular? > >> > > > > how many dimms do you have? interleave settings? Vio jumper? > > already checked on cooling issues? and that you're not overclocking... > > - > 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/ - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Thanks moses -- this is the instability that I have as well. I tried compiling on 1/2 of the k7 optimized mmx routines. So far, running with JUST the fast_clear_page using k7 streaming (and not fast_copy_page), the system is still stable. I'll try adding fast_copy _page, but I think that's where our problems lie (of course I could be full of crap, too). --S Moses McKnight wrote: Mark Hahn wrote: Actually, I think there are 2 problems that have been discussed -- the disk corruption and a general instability resulting in oops'es at various points shortly after boot up. I don't see this. specifically, there were scattered reports of a via-ide problem a few months ago; this is the issue that's gotten some press, and for which Alan has a fix. and there are reports of via-smp problems at boot (which go away with noapic). I see no reports of the kind of general instability you're talking about. and all the via-users I've heard of have no such stability problems - me included (kt133/duron). the only general issue is that kx133 systems seem to be difficult to configure for stability. ugly things like tweaking Vio. there's no implication that has anything to do with Linux, though. When I reported my problem a couple weeks back another fellow said he and several others on the list had the same problem, and as far as I can tell it is *only* with the IWILL boards. When I compiled with k7 optimizations I'd get all kinds of oopses and panics and never fully boot. They were different every time. When any of the lesser optimizations are used I have no problems. My memory is one 256MB Corsair PC150 dimm, CPU is a Thunderbird 850, and mobo is an IWILL KK266 (KT133A). The CPU runs between 35°C and 40°C. My memory system jas been set up very conservitavely and has been rock solid in my other board (ka7), so I doubt it's that, but I sure am happy to try a few more cominations of bios settings. Anything I should look for in particular? how many dimms do you have? interleave settings? Vio jumper? already checked on cooling issues? and that you're not overclocking... - 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/ - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Jonathan Morton wrote: I'm using an Abit KT7 board (KT133) and my new 1GHz T'bird (running 50-60°C in a warm room) is giving me no trouble. This is with the board and RAM pushed as fast as it will go without actually overclocking anything... and yes, I do have Athlon/K7 optimisations turned on in my kernel (2.4.3). I wonder if the KT133A (which is what the IWILL KK266 is based on) differences a could be a source of the problem. My FSB is at plain old 100 MHz since I have regular PC100 SDRAM. Overclocked, or not, I get the same results. I, too, had an ABIT KA7[-RAID] and it was rock solid. So much for if it's not broke, don't fix it -- I should have listened to my gf, but that's the life of an upgrader ;)... In general the IWILL got great reviews at a number of reliable hardware review sites, and hey, it doesn't lock up in windows ;) (ok don't flame me for that ;)). --Seth - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
I'm using an Abit KT7 board (KT133) and my new 1GHz T'bird (running 50-60°C in a warm room) is giving me no trouble. This is with the board and RAM pushed as fast as it will go without actually overclocking anything... and yes, I do have Athlon/K7 optimisations turned on in my kernel (2.4.3). I wonder if the KT133A (which is what the IWILL KK266 is based on) differences a could be a source of the problem. My FSB is at plain old 100 MHz since I have regular PC100 SDRAM. Overclocked, or not, I get the same results. I, too, had an ABIT KA7[-RAID] and it was rock solid. So much for if it's not broke, don't fix it -- I should have listened to my gf, but that's the life of an upgrader ;)... In general the IWILL got great reviews at a number of reliable hardware review sites, and hey, it doesn't lock up in windows ;) (ok don't flame me for that ;)). Maybe, but the IWILL board is the only one we've heard about problems with. The Abit KT7A (which also has the KT133A chipset and is otherwise identical to the KT7) would appear to run smoothly, although I don't actually *have* one of those. Probably the Windows drivers turn off some feature of the IWILL board which is known to be flaky. I suggest setting *everything* in the BIOS to the most conservative settings and seeing if the problem persists. If so, then it can't be a hardware-speed-limitation problem, and there's clearly something we have to turn off manually. Also, try running memtest86 and see if that is capable of triggering the problem. -- from: Jonathan Chromatix Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
On Tue, 1 May 2001, Seth Goldberg wrote: > > > The other thing i was gunna try is to dump my chipset registers using > > > WPCREDIT and WPCRSET and compare them with other people on this list > > why resort to silly windows tools, when lspci under Linux does it for you? > Because lspci does not display all 256 bytes of pci configuration > information. Say what? Try lspci -vvxxx -Dan - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
>> the only general issue is that kx133 systems seem to be difficult >> to configure for stability. ugly things like tweaking Vio. >> there's no implication that has anything to do with Linux, though. > > >When I reported my problem a couple weeks back another fellow >said he and several others on the list had the same problem, >and as far as I can tell it is *only* with the IWILL boards. >When I compiled with k7 optimizations I'd get all kinds of oopses >and panics and never fully boot. They were different every time. >When any of the lesser optimizations are used I have no problems. >My memory is one 256MB Corsair PC150 dimm, CPU is a Thunderbird 850, >and mobo is an IWILL KK266 (KT133A). The CPU runs between 35°C >and 40°C. I'm using an Abit KT7 board (KT133) and my new 1GHz T'bird (running 50-60°C in a warm room) is giving me no trouble. This is with the board and RAM pushed as fast as it will go without actually overclocking anything... and yes, I do have Athlon/K7 optimisations turned on in my kernel (2.4.3). Out of interest, what FSB are you using for your machine? I understand the difference between the KT133 and the KT133A is that the latter supports a 266MHz FSB for the Athlon rather than 200MHz. Since your CPU is running cool, I doubt you've managed to accidentally o/c it, but nevertheless this is a possibility... The 266MHz FSB does require considerably higher standards in board construction though, so it could be that IWILL have managed to do a shoddy job on that end. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Mark Hahn wrote: >> Actually, I think there are 2 problems that have been discussed -- the >>disk corruption and a general instability resulting in oops'es at >>various points shortly after boot up. >> > > I don't see this. specifically, there were scattered reports > of a via-ide problem a few months ago; this is the issue that's > gotten some press, and for which Alan has a fix. and there are reports > of via-smp problems at boot (which go away with noapic). I see no reports > of the kind of general instability you're talking about. and all the > via-users I've heard of have no such stability problems - > me included (kt133/duron). > > the only general issue is that kx133 systems seem to be difficult > to configure for stability. ugly things like tweaking Vio. > there's no implication that has anything to do with Linux, though. When I reported my problem a couple weeks back another fellow said he and several others on the list had the same problem, and as far as I can tell it is *only* with the IWILL boards. When I compiled with k7 optimizations I'd get all kinds of oopses and panics and never fully boot. They were different every time. When any of the lesser optimizations are used I have no problems. My memory is one 256MB Corsair PC150 dimm, CPU is a Thunderbird 850, and mobo is an IWILL KK266 (KT133A). The CPU runs between 35°C and 40°C. >> My memory system jas been set up very conservitavely and has been >>rock solid in my other board (ka7), so I doubt it's that, but I >>sure am happy to try a few more cominations of bios settings. Anything >>I should look for in particular? >> > > how many dimms do you have? interleave settings? Vio jumper? > already checked on cooling issues? and that you're not overclocking... - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
> > why resort to silly windows tools, when lspci under Linux does it for you? > > Because lspci does not display all 256 bytes of pci configuration > information. RTFM ;) - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
why resort to silly windows tools, when lspci under Linux does it for you? Because lspci does not display all 256 bytes of pci configuration information. RTFM ;) - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Mark Hahn wrote: Actually, I think there are 2 problems that have been discussed -- the disk corruption and a general instability resulting in oops'es at various points shortly after boot up. I don't see this. specifically, there were scattered reports of a via-ide problem a few months ago; this is the issue that's gotten some press, and for which Alan has a fix. and there are reports of via-smp problems at boot (which go away with noapic). I see no reports of the kind of general instability you're talking about. and all the via-users I've heard of have no such stability problems - me included (kt133/duron). the only general issue is that kx133 systems seem to be difficult to configure for stability. ugly things like tweaking Vio. there's no implication that has anything to do with Linux, though. When I reported my problem a couple weeks back another fellow said he and several others on the list had the same problem, and as far as I can tell it is *only* with the IWILL boards. When I compiled with k7 optimizations I'd get all kinds of oopses and panics and never fully boot. They were different every time. When any of the lesser optimizations are used I have no problems. My memory is one 256MB Corsair PC150 dimm, CPU is a Thunderbird 850, and mobo is an IWILL KK266 (KT133A). The CPU runs between 35°C and 40°C. My memory system jas been set up very conservitavely and has been rock solid in my other board (ka7), so I doubt it's that, but I sure am happy to try a few more cominations of bios settings. Anything I should look for in particular? how many dimms do you have? interleave settings? Vio jumper? already checked on cooling issues? and that you're not overclocking... - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
the only general issue is that kx133 systems seem to be difficult to configure for stability. ugly things like tweaking Vio. there's no implication that has anything to do with Linux, though. When I reported my problem a couple weeks back another fellow said he and several others on the list had the same problem, and as far as I can tell it is *only* with the IWILL boards. When I compiled with k7 optimizations I'd get all kinds of oopses and panics and never fully boot. They were different every time. When any of the lesser optimizations are used I have no problems. My memory is one 256MB Corsair PC150 dimm, CPU is a Thunderbird 850, and mobo is an IWILL KK266 (KT133A). The CPU runs between 35°C and 40°C. I'm using an Abit KT7 board (KT133) and my new 1GHz T'bird (running 50-60°C in a warm room) is giving me no trouble. This is with the board and RAM pushed as fast as it will go without actually overclocking anything... and yes, I do have Athlon/K7 optimisations turned on in my kernel (2.4.3). Out of interest, what FSB are you using for your machine? I understand the difference between the KT133 and the KT133A is that the latter supports a 266MHz FSB for the Athlon rather than 200MHz. Since your CPU is running cool, I doubt you've managed to accidentally o/c it, but nevertheless this is a possibility... The 266MHz FSB does require considerably higher standards in board construction though, so it could be that IWILL have managed to do a shoddy job on that end. -- from: Jonathan Chromatix Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
On Tue, 1 May 2001, Seth Goldberg wrote: The other thing i was gunna try is to dump my chipset registers using WPCREDIT and WPCRSET and compare them with other people on this list why resort to silly windows tools, when lspci under Linux does it for you? Because lspci does not display all 256 bytes of pci configuration information. Say what? Try lspci -vvxxx -Dan - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
> > this has nothing to do with the very specific disk corruption > > being discussed (which has to do with the ide controller, according > > to the most recent rumors.). > > Actually, I think there are 2 problems that have been discussed -- the > disk corruption and a general instability resulting in oops'es at > various points shortly after boot up. I don't see this. specifically, there were scattered reports of a via-ide problem a few months ago; this is the issue that's gotten some press, and for which Alan has a fix. and there are reports of via-smp problems at boot (which go away with noapic). I see no reports of the kind of general instability you're talking about. and all the via-users I've heard of have no such stability problems - me included (kt133/duron). the only general issue is that kx133 systems seem to be difficult to configure for stability. ugly things like tweaking Vio. there's no implication that has anything to do with Linux, though. > > My memory system jas been set up very conservitavely and has been > rock solid in my other board (ka7), so I doubt it's that, but I > sure am happy to try a few more cominations of bios settings. Anything > I should look for in particular? how many dimms do you have? interleave settings? Vio jumper? already checked on cooling issues? and that you're not overclocking... > > why resort to silly windows tools, when lspci under Linux does it for you? > > Because lspci does not display all 256 bytes of pci configuration > information. sure it does: (from my kt133 hostbridge) [root@crema /root]# lspci -s 00:00.0 -xxx 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) 00: 06 11 05 03 06 00 10 22 02 00 00 06 00 00 00 00 10: 08 00 00 e0 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 00 00 00 00 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: 27 a4 0b b4 46 02 08 08 08 00 00 00 04 08 08 08 60: 0c 00 00 00 d5 d6 d5 00 50 5d 86 0d 08 01 00 00 70: c9 88 cc 0c 0e a0 d2 00 01 b4 01 02 00 00 00 00 80: 0f 40 00 00 f0 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 00 00 00 a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2b 02 04 00 b0: 7f 63 2a 65 31 33 c0 0c 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 0e 22 00 00 00 00 00 00 00 [root@crema /root]# od -Ax -txC /proc/bus/pci/00/00.0 00 06 11 05 03 06 00 10 22 02 00 00 06 00 00 00 00 10 08 00 00 e0 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 00 00 00 00 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 27 a4 0b b4 46 02 08 08 08 00 00 00 04 08 08 08 60 0c 00 00 00 d5 d6 d5 00 50 5d 86 0d 08 01 00 00 70 c9 88 cc 0c 0e a0 d2 00 01 b4 01 02 00 00 00 00 80 0f 40 00 00 f0 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 00 00 00 a0 02 c0 20 00 07 02 00 1f 00 00 00 00 2b 02 04 00 b0 7f 63 2a 65 31 33 c0 0c 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 * f0 00 00 00 00 00 00 00 0e 22 00 00 00 00 00 00 00 000100 - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
In mailing-lists.linux-kernel, Seth wrote: > Because lspci does not display all 256 bytes of pci configuration >information. Umm, "lspci -xxx"? At least, on lspci version 2.1.8 from RedHat 7.1. Wayne - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Mark Hahn wrote: > > > And that's exactly what I did :)... I found that ONLY the combination > > of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in > > results in this wackiness. I should alos repeat that I *DO* see that > > I doubt that USE_3DNOW is causing the problem, but rather when you > USE_3DNOW, the kernel streams through your northbridge at roughly > twice the bandwidth. if your dram settings are flakey, this could > eaily trigger a problem. > > this has nothing to do with the very specific disk corruption > being discussed (which has to do with the ide controller, according > to the most recent rumors.). Actually, I think there are 2 problems that have been discussed -- the disk corruption and a general instability resulting in oops'es at various points shortly after boot up. My memory system jas been set up very conservitavely and has been rock solid in my other board (ka7), so I doubt it's that, but I sure am happy to try a few more cominations of bios settings. Anything I should look for in particular? Thanks, Seth > > > The other thing i was gunna try is to dump my chipset registers using > > WPCREDIT and WPCRSET and compare them with other people on this list > > why resort to silly windows tools, when lspci under Linux does it for you? > > regards, mark hahn. > Because lspci does not display all 256 bytes of pci configuration information. --S - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
> And that's exactly what I did :)... I found that ONLY the combination > of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in > results in this wackiness. I should alos repeat that I *DO* see that I doubt that USE_3DNOW is causing the problem, but rather when you USE_3DNOW, the kernel streams through your northbridge at roughly twice the bandwidth. if your dram settings are flakey, this could eaily trigger a problem. this has nothing to do with the very specific disk corruption being discussed (which has to do with the ide controller, according to the most recent rumors.). > The other thing i was gunna try is to dump my chipset registers using > WPCREDIT and WPCRSET and compare them with other people on this list why resort to silly windows tools, when lspci under Linux does it for you? regards, mark hahn. - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Hi :) And that's exactly what I did :)... I found that ONLY the combination of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in mmx.c) results in this wackiness. I should alos repeat that I *DO* see that wierdness you described with 3DNOW (in my case, it was that kde locks up when i try to do something). This is damn weird... Who thought channging motherboards would result in this? The other thing i was gunna try is to dump my chipset registers using WPCREDIT and WPCRSET and compare them with other people on this list who have been having the problem. Maybe our BIOS'es are not initting/are initting something they should/should not be :). It this point, I haven't ruled anything out... --Seth Lawrence Gold wrote: > > Hi, Seth, > > Just wanted to let you know that I got similar results to yours with my > Epox 8KTA3 motherboard + Thunderbird. (If you've already seen the thread > on the kernel mailing list, then please ignore this. ;) > > If I leave the 3DNOW stuff enabled in arch/i386/config.in, but disable the > K7-specific MMX optimizations, then the system doesn't panic on startup or > oops continually, but I do get odd behavior, such as awk breaking. > > If I disable just the 3DNOW stuff, then everything works really smoothly. > I was planning on disabling one-by-one the parts of the code which use > 3DNOW optimizations to see if there's a particular one that brings about > instability. > > I'll be sure to cc you on anything I find... - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Dan Hollis wrote: > > On Tue, 1 May 2001, Seth Goldberg wrote: > > I Should clarify that this is the KX133A chipset. > > No such thing. Surely you mean KT133A. No X. > Surely :)... That's what sleep deprivation does to you ;). --S - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
On Tue, 1 May 2001, Seth Goldberg wrote: > I Should clarify that this is the KX133A chipset. No such thing. Surely you mean KT133A. No X. -Dan - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Will Newton wrote: I Should clarify that this is the KX133A chipset. In any event, there are a bunch of people having this problem (check out the list archives). I just upgraded to this IWILL board from an Abit KA7-RAID (which worked with no problem), so I'm just trying tofgure it out :) -Seth > > > is exhibiting weird behavior under K7 optimizations. The jist of my > > research is that compiling a kernel for ANY CPU with the Athlon MMX > > optimization > > *AND* 3DNOW results in massive amounts of oops'es and total system > > instability. The following is what I've tried: > > With: > > Athlon 700 > Asus K7V (KX133 based) > > I have been running Athlon based kernels for months, no problems (well, > none like you mention). > > gcc 2.96-81 BTW > > - > 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/ - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
> is exhibiting weird behavior under K7 optimizations. The jist of my > research is that compiling a kernel for ANY CPU with the Athlon MMX > optimization > *AND* 3DNOW results in massive amounts of oops'es and total system > instability. The following is what I've tried: With: Athlon 700 Asus K7V (KX133 based) I have been running Athlon based kernels for months, no problems (well, none like you mention). gcc 2.96-81 BTW - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
> when I add USE_3DNOW to the K6 section and reboot, KDE hangs when > I click on any button in my launch bar (vanilla KDE 2.0). It > does NOT hang the system, though. Restarting Xwindows does not > help, The K6 USE_3DNOW has two problems 1. It doesnt work on a CPU with fxsave (my bug and its fixed in -ac) 2. Its not a performance win. #2 doesn't matter for testing > [3] When I add 3DNOW to any option in [2] w/ the Athlon MMX opt, > the instability is evident after root is mounted and startup > scripts begin executing. Sometimes the system can make it through > other times it cannot. And I still have no problem reporters with non VIA chipsets Alan - 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/
DISCOVERED! Cause of Athlon/VIA KX133 Instability
Ok, so the subject is an attention-getter :). Peep this, homies: Hi, I've been doing some research, trying to figure out why the VIA/Athlon is exhibiting weird behavior under K7 optimizations. The jist of my research is that compiling a kernel for ANY CPU with the Athlon MMX optimization *AND* 3DNOW results in massive amounts of oops'es and total system instability. The following is what I've tried: [1] Selected Athlon as CPU in .config, then commenting out (#if 0) the mmx code optimized for the athlon (as was stated is the only main k7 opt). The resulting kernel is stable. enabling/disabling other options have no effect on stability. [2] Experimented with choosing K6-(III) optimized kernel, but modifying the arch/i386/config.in to sequentially add to the K6 section all the options in the K7 section (i.e. GOOD_APIC, USE_3DNOW, L1_CACHE_SHIFT difference, and PGE). So far, the only anomolay I've found is that when I add USE_3DNOW to the K6 section and reboot, KDE hangs when I click on any button in my launch bar (vanilla KDE 2.0). It does NOT hang the system, though. Restarting Xwindows does not help, but changing the WM to TWM allows me to run netscape (which was one of the buttons that hund X in KDE in the launch bar). Weird, right? Enabling paging extensions (CONFIG_X86_PGE) appears to have no effect on stability. [3] When I add 3DNOW to any option in [2] w/ the Athlon MMX opt, the instability is evident after root is mounted and startup scripts begin executing. Sometimes the system can make it through other times it cannot. Athlon 900 (990) Thunderbird IWILL KK-266 M/B 256MB PC100 RAM Promise Ultra66 IDE SB Live GeForce 256 (AGP) My info (dmesg): Linux version 2.4.4 (root@c1162825-a) (gcc version 2.95.3 20010315 (release)) #6 SMP Sun Apr 29 04:31:06 PDT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0fff (usable) BIOS-e820: 0fff - 0fff3000 (ACPI NVS) BIOS-e820: 0fff3000 - 1000 (ACPI data) BIOS-e820: - 0001 (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009fc00 for 4096 bytes. On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. mapped APIC to e000 (01444000) Kernel command line: BOOT_IMAGE=LInux ro root=302 Initializing CPU#0 Detected 993.350 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1979.18 BogoMIPS Memory: 255644k/262080k available (846k kernel code, 6048k reserved, 334k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU0: AMD Athlon(tm) Processor stepping 02 per-CPU timeslice cutoff: 731.63 usecs. SMP motherboard not detected. Using dummy APIC emulation. Setting commenced=1, go go go PCI: PCI BIOS revision 2.10 entry at 0xfb240, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:07.0 Applying VIA PCI latency patch. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 169848kB/56616kB, 512 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed
DISCOVERED! Cause of Athlon/VIA KX133 Instability
Ok, so the subject is an attention-getter :). Peep this, homies: Hi, I've been doing some research, trying to figure out why the VIA/Athlon is exhibiting weird behavior under K7 optimizations. The jist of my research is that compiling a kernel for ANY CPU with the Athlon MMX optimization *AND* 3DNOW results in massive amounts of oops'es and total system instability. The following is what I've tried: [1] Selected Athlon as CPU in .config, then commenting out (#if 0) the mmx code optimized for the athlon (as was stated is the only main k7 opt). The resulting kernel is stable. enabling/disabling other options have no effect on stability. [2] Experimented with choosing K6-(III) optimized kernel, but modifying the arch/i386/config.in to sequentially add to the K6 section all the options in the K7 section (i.e. GOOD_APIC, USE_3DNOW, L1_CACHE_SHIFT difference, and PGE). So far, the only anomolay I've found is that when I add USE_3DNOW to the K6 section and reboot, KDE hangs when I click on any button in my launch bar (vanilla KDE 2.0). It does NOT hang the system, though. Restarting Xwindows does not help, but changing the WM to TWM allows me to run netscape (which was one of the buttons that hund X in KDE in the launch bar). Weird, right? Enabling paging extensions (CONFIG_X86_PGE) appears to have no effect on stability. [3] When I add 3DNOW to any option in [2] w/ the Athlon MMX opt, the instability is evident after root is mounted and startup scripts begin executing. Sometimes the system can make it through other times it cannot. Athlon 900 (990) Thunderbird IWILL KK-266 M/B 256MB PC100 RAM Promise Ultra66 IDE SB Live GeForce 256 (AGP) My info (dmesg): Linux version 2.4.4 (root@c1162825-a) (gcc version 2.95.3 20010315 (release)) #6 SMP Sun Apr 29 04:31:06 PDT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0fff (usable) BIOS-e820: 0fff - 0fff3000 (ACPI NVS) BIOS-e820: 0fff3000 - 1000 (ACPI data) BIOS-e820: - 0001 (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009fc00 for 4096 bytes. On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. mapped APIC to e000 (01444000) Kernel command line: BOOT_IMAGE=LInux ro root=302 Initializing CPU#0 Detected 993.350 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1979.18 BogoMIPS Memory: 255644k/262080k available (846k kernel code, 6048k reserved, 334k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU0: AMD Athlon(tm) Processor stepping 02 per-CPU timeslice cutoff: 731.63 usecs. SMP motherboard not detected. Using dummy APIC emulation. Setting commenced=1, go go go PCI: PCI BIOS revision 2.10 entry at 0xfb240, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:07.0 Applying VIA PCI latency patch. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 169848kB/56616kB, 512 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed
Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability
when I add USE_3DNOW to the K6 section and reboot, KDE hangs when I click on any button in my launch bar (vanilla KDE 2.0). It does NOT hang the system, though. Restarting Xwindows does not help, The K6 USE_3DNOW has two problems 1. It doesnt work on a CPU with fxsave (my bug and its fixed in -ac) 2. Its not a performance win. #2 doesn't matter for testing [3] When I add 3DNOW to any option in [2] w/ the Athlon MMX opt, the instability is evident after root is mounted and startup scripts begin executing. Sometimes the system can make it through other times it cannot. And I still have no problem reporters with non VIA chipsets Alan - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Will Newton wrote: I Should clarify that this is the KX133A chipset. In any event, there are a bunch of people having this problem (check out the list archives). I just upgraded to this IWILL board from an Abit KA7-RAID (which worked with no problem), so I'm just trying tofgure it out :) -Seth is exhibiting weird behavior under K7 optimizations. The jist of my research is that compiling a kernel for ANY CPU with the Athlon MMX optimization *AND* 3DNOW results in massive amounts of oops'es and total system instability. The following is what I've tried: With: Athlon 700 Asus K7V (KX133 based) I have been running Athlon based kernels for months, no problems (well, none like you mention). gcc 2.96-81 BTW - 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/ - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
On Tue, 1 May 2001, Seth Goldberg wrote: I Should clarify that this is the KX133A chipset. No such thing. Surely you mean KT133A. No X. -Dan - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Dan Hollis wrote: On Tue, 1 May 2001, Seth Goldberg wrote: I Should clarify that this is the KX133A chipset. No such thing. Surely you mean KT133A. No X. Surely :)... That's what sleep deprivation does to you ;). --S - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Hi :) And that's exactly what I did :)... I found that ONLY the combination of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in mmx.c) results in this wackiness. I should alos repeat that I *DO* see that wierdness you described with 3DNOW (in my case, it was that kde locks up when i try to do something). This is damn weird... Who thought channging motherboards would result in this? The other thing i was gunna try is to dump my chipset registers using WPCREDIT and WPCRSET and compare them with other people on this list who have been having the problem. Maybe our BIOS'es are not initting/are initting something they should/should not be :). It this point, I haven't ruled anything out... --Seth Lawrence Gold wrote: Hi, Seth, Just wanted to let you know that I got similar results to yours with my Epox 8KTA3 motherboard + Thunderbird. (If you've already seen the thread on the kernel mailing list, then please ignore this. ;) If I leave the 3DNOW stuff enabled in arch/i386/config.in, but disable the K7-specific MMX optimizations, then the system doesn't panic on startup or oops continually, but I do get odd behavior, such as awk breaking. If I disable just the 3DNOW stuff, then everything works really smoothly. I was planning on disabling one-by-one the parts of the code which use 3DNOW optimizations to see if there's a particular one that brings about instability. I'll be sure to cc you on anything I find... - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
And that's exactly what I did :)... I found that ONLY the combination of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in results in this wackiness. I should alos repeat that I *DO* see that I doubt that USE_3DNOW is causing the problem, but rather when you USE_3DNOW, the kernel streams through your northbridge at roughly twice the bandwidth. if your dram settings are flakey, this could eaily trigger a problem. this has nothing to do with the very specific disk corruption being discussed (which has to do with the ide controller, according to the most recent rumors.). The other thing i was gunna try is to dump my chipset registers using WPCREDIT and WPCRSET and compare them with other people on this list why resort to silly windows tools, when lspci under Linux does it for you? regards, mark hahn. - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Mark Hahn wrote: And that's exactly what I did :)... I found that ONLY the combination of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in results in this wackiness. I should alos repeat that I *DO* see that I doubt that USE_3DNOW is causing the problem, but rather when you USE_3DNOW, the kernel streams through your northbridge at roughly twice the bandwidth. if your dram settings are flakey, this could eaily trigger a problem. this has nothing to do with the very specific disk corruption being discussed (which has to do with the ide controller, according to the most recent rumors.). Actually, I think there are 2 problems that have been discussed -- the disk corruption and a general instability resulting in oops'es at various points shortly after boot up. My memory system jas been set up very conservitavely and has been rock solid in my other board (ka7), so I doubt it's that, but I sure am happy to try a few more cominations of bios settings. Anything I should look for in particular? Thanks, Seth The other thing i was gunna try is to dump my chipset registers using WPCREDIT and WPCRSET and compare them with other people on this list why resort to silly windows tools, when lspci under Linux does it for you? regards, mark hahn. Because lspci does not display all 256 bytes of pci configuration information. --S - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
In mailing-lists.linux-kernel, Seth wrote: Because lspci does not display all 256 bytes of pci configuration information. Umm, lspci -xxx? At least, on lspci version 2.1.8 from RedHat 7.1. Wayne - 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
this has nothing to do with the very specific disk corruption being discussed (which has to do with the ide controller, according to the most recent rumors.). Actually, I think there are 2 problems that have been discussed -- the disk corruption and a general instability resulting in oops'es at various points shortly after boot up. I don't see this. specifically, there were scattered reports of a via-ide problem a few months ago; this is the issue that's gotten some press, and for which Alan has a fix. and there are reports of via-smp problems at boot (which go away with noapic). I see no reports of the kind of general instability you're talking about. and all the via-users I've heard of have no such stability problems - me included (kt133/duron). the only general issue is that kx133 systems seem to be difficult to configure for stability. ugly things like tweaking Vio. there's no implication that has anything to do with Linux, though. My memory system jas been set up very conservitavely and has been rock solid in my other board (ka7), so I doubt it's that, but I sure am happy to try a few more cominations of bios settings. Anything I should look for in particular? how many dimms do you have? interleave settings? Vio jumper? already checked on cooling issues? and that you're not overclocking... why resort to silly windows tools, when lspci under Linux does it for you? Because lspci does not display all 256 bytes of pci configuration information. sure it does: (from my kt133 hostbridge) [root@crema /root]# lspci -s 00:00.0 -xxx 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) 00: 06 11 05 03 06 00 10 22 02 00 00 06 00 00 00 00 10: 08 00 00 e0 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 00 00 00 00 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: 27 a4 0b b4 46 02 08 08 08 00 00 00 04 08 08 08 60: 0c 00 00 00 d5 d6 d5 00 50 5d 86 0d 08 01 00 00 70: c9 88 cc 0c 0e a0 d2 00 01 b4 01 02 00 00 00 00 80: 0f 40 00 00 f0 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 00 00 00 a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2b 02 04 00 b0: 7f 63 2a 65 31 33 c0 0c 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 0e 22 00 00 00 00 00 00 00 [root@crema /root]# od -Ax -txC /proc/bus/pci/00/00.0 00 06 11 05 03 06 00 10 22 02 00 00 06 00 00 00 00 10 08 00 00 e0 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 00 00 00 00 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 27 a4 0b b4 46 02 08 08 08 00 00 00 04 08 08 08 60 0c 00 00 00 d5 d6 d5 00 50 5d 86 0d 08 01 00 00 70 c9 88 cc 0c 0e a0 d2 00 01 b4 01 02 00 00 00 00 80 0f 40 00 00 f0 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 00 00 00 a0 02 c0 20 00 07 02 00 1f 00 00 00 00 2b 02 04 00 b0 7f 63 2a 65 31 33 c0 0c 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 * f0 00 00 00 00 00 00 00 0e 22 00 00 00 00 00 00 00 000100 - 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/
