Re: Re: AMD 64 Stability on Asus A8v Deluxe
On Thu, Sep 29, 2005 at 01:18:34AM -0400, Alan Manning wrote: Hi. I am having stability issues with the A8V as well. Most especially I can't manually set my ram to 400 instead of 333 even though I am running corsair twinx perf ram. Did you even find any sort of resolution for this? I'm running a gf6800gt and Athlon 3800 as well. I was thinking maybe my power supply wasn't stable or something.I always hate to just blame the board. Thanks for any info, Alan Hi, I'm not sure if this is related in anyway to your problem. I use MSI K8T (with VIA K8T800Pro chipset) and there seems to be very strict rules on how to arrange the memory modules in order to get 400MHz. There are four slots on board and they are referred as channel A (slots 12) and channel B (slots 34). If I use double side memory modules, they have to be inserted in slots 1 and 3 to get DDR400. If I install them into slots 1 and 2, I only get DDR333. Simo -- :r ~/.signature signature.asc Description: Digital signature
Re: Re: AMD 64 Stability on Asus A8v Deluxe
Le 01.10.2005 09:13:20, Simo Kauppi a écrit : On Thu, Sep 29, 2005 at 01:18:34AM -0400, Alan Manning wrote: Hi. I am having stability issues with the A8V as well. Most [ ... ] I'm not sure if this is related in anyway to your problem. I use MSI K8T (with VIA K8T800Pro chipset) and there seems to be very strict rules on how to arrange the memory modules in order to get 400MHz. There are four slots on board and they are referred as channel A (slots 12) and channel B (slots 34). If I use double side memory modules, they have to be inserted in slots 1 and 3 to get DDR400. If I install them into slots 1 and 2, I only get DDR333. On the Asus A8V there are 4 slots 2 blue and 2 black near the processor like that: Processor Blue(A1) Black(A2) Blue(B1) Black(B2) They are called A1 A2 B1 B2 in this order The blue slots have to be used first DIMM with more than 18 chips arent supported If you use only one DIMM, slot B1 should be used If you use 2 DIMM, in dual channel mode, B1 and A1 should be used, they have to be identical (better matched) each pair must have the same CAS They don't tell if you can use 3 DIMM ... In this case, if allowed, you probably run in single channel. For example, I use one matched pair twin 512 = 1024 in the blue slots Jean-Luc pgpQfKTjqfZIN.pgp Description: PGP signature
Re: Re: AMD 64 Stability on Asus A8v Deluxe
On Thu, Sep 29, 2005 at 01:18:34AM -0400, Alan Manning wrote: Hi. I am having stability issues with the A8V as well. Most especially I can't manually set my ram to 400 instead of 333 even though I am running corsair twinx perf ram. Did you even find any sort of resolution for this? I'm running a gf6800gt and Athlon 3800 as well. I was thinking maybe my power supply wasn't stable or something.I always hate to just blame the board. Hmm, I have an A8V Deluxe here with 2 x 512M kingston value ram DDR400, and it just runs perfectly with memory set to 400MHz. I think I just have it set to auto and it does that. Using an Athlon 64 3500+. I have one memory stick per memory channel. I run a 350W enermax power supply, so nice but nothing fancy. Using latest bios version? Is corsair memory considered supported by the board (I have never used corsair memory). Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: AMD 64 Stability on Asus A8v Deluxe
Le 29.09.2005 15:29:21, Lennart Sorensen a écrit : On Thu, Sep 29, 2005 at 01:18:34AM -0400, Alan Manning wrote: Hi. I am having stability issues with the A8V as well. Most especially I can't manually set my ram to 400 instead of 333 even though I am running corsair twinx perf ram. Did you even find any sort of resolution for this? I'm running a gf6800gt and Athlon 3800 as well. I was thinking maybe my power supply wasn't stable or something.I always hate to just blame the board. Hmm, I have an A8V Deluxe here with 2 x 512M kingston value ram DDR400, and it just runs perfectly with memory set to 400MHz. I think I just have it set to auto and it does that. Using an Athlon 64 3500+. I have one memory stick per memory channel. I run a 350W enermax power supply, so nice but nothing fancy. Using latest bios version? Is corsair memory considered supported by the board (I have never used corsair memory). I've a 3500+ with twin 2x512k Corsair 3200C2. I've experienced some problems: I had an Antenc Sonata (380W PSU) and the PSU was not stable. It has been replaced with a SonataII with more power and stable PSU. I run the RAM 2.5-3-3-6 1T, I've had some problems reported by memtest86+ on one of the SIMM. During the tests, the problems disappeared... Len Sorensen Jean-Luc pgpy0GPK6ojhw.pgp Description: PGP signature
Re: Re: AMD 64 Stability on Asus A8v Deluxe
On Thu, Sep 29, 2005 at 01:43:25PM +, Jean-Luc Coulon (f5ibh) wrote: I've a 3500+ with twin 2x512k Corsair 3200C2. I've experienced some problems: I had an Antenc Sonata (380W PSU) and the PSU was not stable. It has been replaced with a SonataII with more power and stable PSU. I run the RAM 2.5-3-3-6 1T, I've had some problems reported by memtest86+ on one of the SIMM. During the tests, the problems disappeared... I only have CL3 memory (didn't seem worth spending that much more on CL2.5 memory). So far the system has been absolutely stable running the bios memory settings at auto. Runs rather nice and fast too. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: AMD 64 Stability on Asus A8v Deluxe
Le 29.09.2005 17:52:30, Lennart Sorensen a écrit : On Thu, Sep 29, 2005 at 01:43:25PM +, Jean-Luc Coulon (f5ibh) wrote: I've a 3500+ with twin 2x512k Corsair 3200C2. I've experienced some problems: I had an Antenc Sonata (380W PSU) and the PSU was not stable. It has been replaced with a SonataII with more power and stable PSU. I run the RAM 2.5-3-3-6 1T, I've had some problems reported by memtest86+ on one of the SIMM. During the tests, the problems disappeared... I only have CL3 memory (didn't seem worth spending that much more on CL2.5 memory). So far the system has been absolutely stable running the bios memory settings at auto. Runs rather nice and fast too. If you have a look in the real settings when set to auto, you will see that all the timing parameters are very relaxed. A simple run of memtest will tell you the truth about these settings Len Sorensen Jean-Luc pgp9OEEEwSeCV.pgp Description: PGP signature
Re: Re: AMD 64 Stability on Asus A8v Deluxe
On Thu, Sep 29, 2005 at 04:04:11PM +, Jean-Luc Coulon (f5ibh) wrote: If you have a look in the real settings when set to auto, you will see that all the timing parameters are very relaxed. I don't mind relaxed as long as it is very stable. A simple run of memtest will tell you the truth about these settings Well so far the system is much much faster than the 2.8ghz p4 we also have so I don't care to try and make the ram even 5% faster if it costs stability in any way. :) Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: AMD 64 Stability on Asus A8v Deluxe
Hi. I am having stability issues with the A8V as well. Most especially I cant manually set my ram to 400 instead of 333 even though I am running corsair twinx perf ram. Did you even find any sort of resolution for this? Im running a gf6800gt and Athlon 3800 as well. I was thinking maybe my power supply wasnt stable or somethingI always hate to just blame the board. Thanks for any info, Alan
Re: AMD 64 Stability on Asus A8v Deluxe
Matthias Wenthe schrieb: Jean-Luc Coulon (f5ibh) wrote: 1) kernel compilation test with the following script: #!/bin/tcsh # ramtest # make ARCH=i386 bzImage foreach i (0 1 2 3 4 5 6 7 8 9) foreach j (0 1 2 3 4 5 6 7 8 9) foreach k (0 1 2 3 4 5 6 7 8 9) ( make clean;make ARCH=i386 bzImage log.$i$j$k ) log.err.$i$j$k end end end I must end up with 1000 identical Logfiles Which RAM parameters do you use? With the same board and Corsair RAM (given for 2-3-3-6 for P4 and 2.5-3-3-6 for athlon64), I was working in 32bit with 2 instead of 2.5 for the CAS, but I had to set it to 2.5 in 64 bit. Maybe you have to relax a bit your timings? I've corsair DDR in dual channel I've left the burst to its highest value I use 2.5-3-3-6-1T 2.5 is CAS 3 is tRCD 3 is tRP 6 is tRAS 1T command rate (Disabled for 1T, Enabled for 2T) I have tried 2x 1GByte Infineon CL2.5 DDR 400 without success, then I switched to 4 x takeMS PC3200 CL3 which used to run in single Athlon 2000+ Cube PCs for long without a problem. I took your advice and made the following settings: 3-4-4-8-1T 1T would not even boot so ich switched here to AUTO and had 3 for CAS 4 for tRCD 4 for tRP 8 for tRAS but, alas, the result is as devastating as ever, i/o tar test and kernel compile test runs fine with kernel 2.6.8 686, when I switch to 2.6.11 amd64 k8 it crashes the machine within 10 minutes. As mentioned earlier I am waiting for a delivery of 4 x 512 Kingston Value RAM from the Asus manual's compatibility list. If that failes too I have to assume that the board is defect. But can a board be defect in a way that the k8 64 bit kernel crashes and the 686 32 bit kernel works properly? Seems very strange to me. Finally I received 4x 512 MB Kingston VR (KVR400X64C3A/512) and so I changed the RAM a 2nd time. Remember at first I had 2x 1GByte Infineon and then 4x512 MB takeMS, both produced segfaults during kernel compilation and kernel panics during i/o challenge tests, esp. with 64 bit kernels both in pure amd-64 installations and in mixed mode, i.e. sarge with k8 kernel. In both cases the RAM tested OK in single memory module configuration in other motherboards with Memtest86. What can I say: I installed the new memory, set all BIOS memory switches to AUTO, ran my test for about 24 hours now and so far the system runs like a charm without any errors. I would not even go so far as to speculate that the first two memory sets were defect, I think they were just not 100% compatible with my motherboard. Interestingly enough the 64 bit environment seems to be more sensitive to memory timing problems then the 32 bit one. My suggestion for purchasing new hardware can now only be: If you made the decision for the board goto to the vendor's homepage, download the manual and look for a memory compatibility list that has been thoroughly tested by the vendor, e.g. in Asus boards this is called the qualified vendor list. Then goto your favourite online shop and search for this very type of memory. Do not go for any module with a similar type code. And do not trust the sales personal's statements (It should work). See in my case, I spent more then two weeks of testing with 3 kinds of memory modules which roughly belonged all to the same standard (DDR 400, PC 3200, CAL3, non ECC). Thanks again to Jean-Luc for the hint to switch from BIOS setting auto overclocking to manual settings. The auto overclocking stopped booting in one out of 10 cases with a message of the kind auto overclocking failed, press F1 to resume. In a data processing center far away from you where this machine is going to serve as a mail host this can be quite disturbing after a reboot command. The only thing that seemes a bit sad to me now is that there are still no amd64 security updates available, so I think I have to send away the machine with sarge and amd64-k8 kernel. Seeing the fact, that a well arranged mailserver installation can go for the next two years, it will probably have to be 32bit sarge (the data processing center is 550 km away and once running smoothly I guess I will not switch the OS so soon). But maybe the next server update will be with amd-64 linux. Thanks to all of you for good advice. Best regard Matthias Wenthe ___ Dr. Matthias Wenthe IMS GmbHKreuzbreite 15a D-31675 Bueckeburg Germany ___ [EMAIL PROTECTED] ___ Tel: ..49.5722.892417 Fax: ..49.5722.916623 ___
Re: AMD 64 Stability on Asus A8v Deluxe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 le 26.07.2005 10:02:07, Matthias Wenthe a écrit : Matthias Wenthe schrieb: Jean-Luc Coulon (f5ibh) wrote: [ ... ] to AUTO, ran my test for about 24 hours now and so far the system runs like a charm without any errors. I would not even go so far as to speculate that the first two memory sets were defect, I think they were just not 100% compatible with my motherboard. Interestingly enough the 64 bit environment seems to be more sensitive to memory timing problems then the 32 bit one. amd64 is a bit particular in term of memory management as the processor itself My suggestion for purchasing new hardware can now only be: If you made the decision for the board goto to the vendor's homepage, download the manual and look for a memory compatibility list that has been thoroughly tested by the vendor, e.g. in Asus boards this is called the qualified vendor list. Then goto your favourite online shop and search for this very type of memory. Do not go for any module with a similar type code. And do not trust the sales personal's statements (It should work). See in my case, I spent more then two weeks of testing with 3 kinds of memory modules which roughly belonged all to the same standard (DDR 400, PC 3200, CAL3, non ECC). Whe I bought the memory, I've had a look on the site of the memory manufacturer as well. They done tests also and gives you the best setting for a given memory and a given motherboard. In the cas of this specific Corsair DDR, the CAS is specified at 2.5 or AMD64 and 2 for P4... So there are some specific issues for the Athlon 64. Thanks again to Jean-Luc for the hint to switch from BIOS setting auto overclocking to manual settings. The auto overclocking stopped booting in one out of 10 cases with a message of the kind auto overclocking failed, press F1 to resume. In a data processing center far away from you where this machine is going to serve as a mail host this can be quite disturbing after a reboot command. The auto overclocking feature made me crazy. So it s best to share these kind of bad experience ;-) Even if you are an overclocker (what I'm not), it is best to control everything, the automatic overclocking control even the voltage, you can fry your chip this way. The only thing that seemes a bit sad to me now is that there are still no amd64 security updates available, so I think I have to send away the machine with sarge and amd64-k8 kernel. Seeing the fact, that a well arranged mailserver installation can go for the next two years, it will probably have to be 32bit sarge (the data processing center is 550 km away and once running smoothly I guess I will not switch the OS so soon). But maybe the next server update will be with amd-64 linux. Who knows what will be the future of these machines in 2 years :) Thanks to all of you for good advice. Best regard Matthias Wenthe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC5iLEXit3lz9m7V4RAmK/AJ0RoEDj3Yce3TPvBt/Y/anFQ3WYQACg28k/ rmUqIrDEsCWdCnN7gy/tOEA= =pqxD -END PGP SIGNATURE-
Re: AMD 64 Stability on Asus A8v Deluxe
On Thu, 21 Jul 2005, Erik Mouw wrote: On Wed, Jul 20, 2005 at 11:32:33PM -0700, Juan Ortega wrote: Why dont you simply use memtest86? Because memtest86 doesn't catch all memory errors, while a kernel compile stresses the system in ways memtest86 doesn't. Some memory errors only happen when there is IO going on at the same time, which is exactly what a kernel compile does. For more information, see the sig11 FAQ at http://www.bitwizard.nl/sig11/ . Well, to be fair to memtest86+, we have so far only found one repeatable crash situation that we could pinpoint to faulty RAM that memtest86+ didn't find, and in that case it could just be a case of not running it for long enough (I had a service technician on site on other duty anyway). This under a couple of dozen finds of faulty RAM. But if it is memory controller timings etc, they are much harder to find or trigger than pure bit errors. One good other test to run is bonnie -f, because then all available ram will be used up as disk cache, at the same time as you have IO load. /Mattias Wadenstein - with 1.5TB of ram, you learn to find errors.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMD 64 Stability on Asus A8v Deluxe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 25.07.2005 13:30:20, Mattias Wadenstein a écrit : On Thu, 21 Jul 2005, Erik Mouw wrote: On Wed, Jul 20, 2005 at 11:32:33PM -0700, Juan Ortega wrote: Why dont you simply use memtest86? Because memtest86 doesn't catch all memory errors, while a kernel compile stresses the system in ways memtest86 doesn't. Some memory errors only happen when there is IO going on at the same time, which is exactly what a kernel compile does. For more information, see the sig11 FAQ at http://www.bitwizard.nl/sig11/ . Well, to be fair to memtest86+, we have so far only found one repeatable crash situation that we could pinpoint to faulty RAM that memtest86+ didn't find, and in that case it could just be a case of not running it for long enough (I had a service technician on site on other duty anyway). To be sure of the reliability of the test a long run is mandatory. 10 to 15 hours. It is a bit (!) crazy to have so many memory cells without any real check of the consistancy of the data. And surprisingly, most of the time, it works... This under a couple of dozen finds of faulty RAM. But if it is memory controller timings etc, they are much harder to find or trigger than pure bit errors. And don't forget that the memory management is part of the Athlon processor. I seems that venice core have a better one. One good other test to run is bonnie -f, because then all available ram will be used up as disk cache, at the same time as you have IO load. /Mattias Wadenstein - with 1.5TB of ram, you learn to find errors.. Jean-Luc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD4DBQFC5OLYXit3lz9m7V4RAtyaAJjiabNI5Yt4PBJVSzhhwR0wL8UJAJ44b4al umdtcSp+2EWoPbyjuEYcFQ== =H2jD -END PGP SIGNATURE-
Re: AMD 64 Stability on Asus A8v Deluxe
On Wed, Jul 20, 2005 at 11:32:33PM -0700, Juan Ortega wrote: Why dont you simply use memtest86? Because memtest86 doesn't catch all memory errors, while a kernel compile stresses the system in ways memtest86 doesn't. Some memory errors only happen when there is IO going on at the same time, which is exactly what a kernel compile does. For more information, see the sig11 FAQ at http://www.bitwizard.nl/sig11/ . Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMD 64 Stability on Asus A8v Deluxe
On Fri, Jul 15, 2005 at 01:25:55PM +0200, Matthias Wenthe wrote: I recently set up a new machine as a mail server for our company (aprox. 1000 Users with 60 GByte Traffic/month). Hardware as follows Asus A8V Deluxe Mainboard, nVidia graphic card (NV5M64 [RIVA TNT2 Model 64/Model 64 Pro], 2 Infineon 1 GByte DDR-RAM, PC 3200 2x 300 GByte Seagate ATA HDs with kernel software raid 1 1x Promise FastTrak TX2000 with 1x Maxtor 4A250J0 250 GByte as Backup HD Well I have an A8V Deluxe here and it is running flawlessly. I run the 2.6.11 amd64 kernel with a 32bit sarge install, and 64bit in chroot. I haven't bothered compiling my own kernels in a while given the debian 2.6 kernels have always worked perfectly for me. I do know I would need to use the chroot with 64bit env to compile the kernel with amd64 enabled though. The system has been very stable though. Asus A8V Athlon64 3500 2*512M kingston PC3200 2*250GB WD SATA drives connected to the via controllers (never bothered to find a driver for the promise) PX716A dvd writer GF5200 video I did run pure64 on it initially while burning in and to play with it, and that worked perfectly too. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMD 64 Stability on Asus A8v Deluxe
On Thu, 21 Jul 2005, Erik Mouw wrote: On Wed, Jul 20, 2005 at 11:32:33PM -0700, Juan Ortega wrote: Why dont you simply use memtest86? Because memtest86 doesn't catch all memory errors, while a kernel compile stresses the system in ways memtest86 doesn't. Some memory errors only happen when there is IO going on at the same time, which is exactly what a kernel compile does. For more information, see the sig11 FAQ at http://www.bitwizard.nl/sig11/ . Thanks very much for the clarification Erik! That's exactly what I wanted to answer and btw. the sig11 FAQ ist of course the source for the ramtest shell script I use. Regards Matthias Wenthe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMD 64 Stability on Asus A8v Deluxe
Jean-Luc Coulon wrote: 1) kernel compilation test with the following script: #!/bin/tcsh # ramtest # make ARCH=i386 bzImage foreach i (0 1 2 3 4 5 6 7 8 9) foreach j (0 1 2 3 4 5 6 7 8 9) foreach k (0 1 2 3 4 5 6 7 8 9) ( make clean;make ARCH=i386 bzImage log.$i$j$k ) log.err.$i$j$k end end end I must end up with 1000 identical Logfiles Which RAM parameters do you use? With the same board and Corsair RAM (given for 2-3-3-6 for P4 and 2.5-3-3-6 for athlon64), I was working in 32bit with 2 instead of 2.5 for the CAS, but I had to set it to 2.5 in 64 bit. Maybe you have to relax a bit your timings? I followed your advice and checked the memory timings in BIOS, I found a puzzling variaty of parameters, almost all of the were set on AUTO Here is a summary of the main possible switches: parameter possible Values help Burst Length: 8/4 Beats 64-Bit Dq must use the 4 beats CAS 2/2.5/3 CLK TRC 7-13 CLK TRFC9-15 CLK TRCD2-6 CLK TWR 2-3 CLK TRWT1-6 CLK TRAS5-15 CLK TRP 2-6 CLK TWLC1-2 CLK ASYNC LAT 4-9 CLK I changed Burst Length to 4 Beats (what t.h. is 64-Bit dq?) and CAS to 3, left the rest on AUTO but still got the kernel panics with 64 Bit Kernels. I did another 72 hour test with the kernel compilation loop and kernel 2.6.8 686 and now I unfortunately found here 5 out of 1000 kernel compile logs buggy as well, one of them for example said: In file included from include/linux/types.h:13, from include/linux/capability.h:16, from include/linux/sched.h:7, from include/linux/mm.h:4, from kernel/acct.c:47: include/linux/posix_types.h:38: interner Compiler-Fehler: Speicherzugriffsfehler Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-3.4/README.Bugs. make[1]: *** [kernel/acct.o] Fehler 1 make: *** [kernel] Fehler 2 I get no kernel Oops or panics and nothing in dmesg or syslog. I wonder if it is safe to use such a system as a mail server. If sendmail is as sensitive as the gcc I have a problem. Jean-Luc, you said you have the same mainboard. What other hardware do you use? Maybe I can change the grafic card or give up the software raid to get a stable 64 bit system. I would like to encourage other members of this list with an Asus A8V motherboard to report about there configuration so that I finally can find a way to tell if I have a defect mainboard or an exotic hardware composition problem. Best Regars Matthias Wenthe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMD 64 Stability on Asus A8v Deluxe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 20.07.2005 21:32:17, Matthias Wenthe a écrit : Jean-Luc Coulon wrote: 1) kernel compilation test with the following script: #!/bin/tcsh # ramtest # make ARCH=i386 bzImage foreach i (0 1 2 3 4 5 6 7 8 9) foreach j (0 1 2 3 4 5 6 7 8 9) foreach k (0 1 2 3 4 5 6 7 8 9) ( make clean;make ARCH=i386 bzImage log.$i$j$k ) log.err.$i$j$k end end end I must end up with 1000 identical Logfiles Which RAM parameters do you use? With the same board and Corsair RAM (given for 2-3-3-6 for P4 and 2.5-3-3-6 for athlon64), I was working in 32bit with 2 instead of 2.5 for the CAS, but I had to set it to 2.5 in 64 bit. Maybe you have to relax a bit your timings? I followed your advice and checked the memory timings in BIOS, I found a puzzling variaty of parameters, almost all of the were set on AUTO Here is a summary of the main possible switches: parameter possible Values help Burst Length: 8/4 Beats 64-Bit Dq must use the 4 beats CAS 2/2.5/3 CLK TRC 7-13 CLK TRFC9-15 CLK TRCD2-6 CLK TWR 2-3 CLK TRWT1-6 CLK TRAS5-15 CLK TRP 2-6 CLK TWLC1-2 CLK ASYNC LAT 4-9 CLK I've corsair DDR in dual channel I've left the burst to its highest value I use 2.5-3-3-6-1T 2.5 is CAS 3 is tRCD 3 is tRP 6 is tRAS 1T command rate (Disabled for 1T, Enabled for 2T) I've left the other as is The processor is an athlon 3500+ It runs at nominal voltage/frequency. But I've not left on 'auto' the parameters because this card has a nasty auto-overclocking feature. I've set manually to the nominal values : I use a FSB of 200, multiplier 11 (If we can speak of FSB with this architecture). I've cool and quient enabled I changed Burst Length to 4 Beats (what t.h. is 64-Bit dq?) and CAS to 3, left the rest on AUTO but still got the kernel panics with 64 Bit Kernels. [ ... ] Jean-Luc, you said you have the same mainboard. What other hardware do you use? Maybe I can change the grafic card or give up the software raid to get a stable 64 bit system. I would like to encourage other members of this list with an Asus A8V motherboard to report about there configuration so that I finally can find a way to tell if I have a defect mainboard or an exotic hardware composition problem. I've : 2 SATA Maxtor disks on the VIA chipset, software RAID1 1 IDE DVD burner Pioneer 108 1 Asus Radeon A9250/TD (AGP) I don't use the Promise chipset I've used a Radeon 9500 also but not in 64 bit. I've given it to my daughters who *need* graphic power for the games... The BIOS is 1013 Remark : I have had problems with the graphic mode and some machine check, even in 32 bit with the previous BIOS. 1009 was just working, it was imposible to have a graphical session with 1011 and 1012, there is a fix about AGP in 1013. Best Regars Matthias Wenthe Regards Jean-Luc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC3rGuXit3lz9m7V4RApV0AJ9B6+Po9fHyCxaSZoyeQQrLasBflwCfWhP0 3KqdFGHwXW5EHeA5F1YDUsA= =CXqy -END PGP SIGNATURE-
Re: AMD 64 Stability on Asus A8v Deluxe
Alexander Voss wrote: 1) kernel compilation test with the following script: #!/bin/tcsh # ramtest # make ARCH=i386 bzImage foreach i (0 1 2 3 4 5 6 7 8 9) foreach j (0 1 2 3 4 5 6 7 8 9) foreach k (0 1 2 3 4 5 6 7 8 9) ( make clean;make ARCH=i386 bzImage log.$i$j$k ) log.err.$i$j$k end end end I must end up with 1000 identical Logfiles This means you have all the 32Bit Programms mirrored too? And then you try to compile a 64 bit Kernel. Thanks for your hints regarding the mixed 32/64 bit environment. In the mirrored installation I upgraded to 64bit kernel gcc 3.4 and amd64-libs but could not build the kernel with the usual make mrproper;make menuconfig; make, the error here was always cc1: error: code model `kernel' not supported in the 32 bit mode make[1]: *** [scripts/empty.o] Error 1 make: *** [scripts] Error 2 which was discussed in this list previously but to my knowledge without any straight forward solution. That's why I changed my test script to make ARCH=i386 bzImage, which builds 32bit kernels. Anyway my goal was not to build a perfect kernel for my system but to get a stable and reproducable compiler run. So I made a fresh installation of the amd64 port but got the same devistating premature compiler stops, segmentation faults (thank you for the correct translation :-) and kernel panics when I used my test 2) with the tar archive loops. I think /Jean-Luc Coulon's hint with the relaxed memory timings in 64bit mode (I think the setting here was always AUTO) is a good idea, I will try that later in the day. Also I am waiting for the delivery of some Kingston Value Ram memory modules which are listed in compatibilty list of the Asus manual. greetings Matthias Wenthe / -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMD 64 Stability on Asus A8v Deluxe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 15.07.2005 13:25:55, Matthias Wenthe a écrit : [ ... ] Test 1) produces randomly premature compiler stops in all 64 bit kernels and in kernel 2.4.27. In the error logs I often find Speicherzugriffsfehler (memory access failure (hopefully translated correctly)) Test 2) is stable with 32 bit Kernels, with 64 Bit kernels it crashes the machine (kernel panic) within 10 to 60 minutes. Usually the crash is so fast that I find nothing in the logs, but in one case I was able to trace the Kernel Oops (kernel version kernel-image-2.6.11-9-amd64-k8): [ ... ] I changed RAM (4x 512 MByte) and power supply (450 instead of 300 W) but this had no influence. I assume it cannot be the general stability of the 64 bit kernel and maybe I have a defect motherboard but in that case it feels strange, that kernel 2.6.8-2-686 runs my tests absolut stable whithout any errors (testing time 24 hours). I am glad that after a week of testing I finally found a stable configuration but you have to admit that it is kind of frustrating, that the system consequently refuses to run stable in 64 bit mode. Is this an isolated case with an unlucky hardware mixture or can somebody report similar failures? Any comments or suggestions would be gladly appreciated. Which RAM parameters do you use? With the same board and Corsair RAM (given for 2-3-3-6 for P4 and 2.5-3-3-6 for athlon64), I was working in 32bit with 2 instead of 2.5 for the CAS, but I had to set it to 2.5 in 64 bit. Maybe you have to relax a bit your timings? Matthias Wenthe Jean-Luc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC16ZmXit3lz9m7V4RAkeRAKDEM24ClozvFew4x0zPJ/K6dVZRLgCgi2zF YgsIm7cnEIxxh+WYJbkWVM4= =qIT2 -END PGP SIGNATURE-
Re: AMD 64 Stability on Asus A8v Deluxe
Matthias Wenthe wrote: I recently set up a new machine as a mail server for our company (aprox. 1000 Users with 60 GByte Traffic/month). Hardware as follows Asus A8V Deluxe Mainboard, nVidia graphic card (NV5M64 [RIVA TNT2 Model 64/Model 64 Pro], 2 Infineon 1 GByte DDR-RAM, PC 3200 2x 300 GByte Seagate ATA HDs with kernel software raid 1 1x Promise FastTrak TX2000 with 1x Maxtor 4A250J0 250 GByte as Backup HD I mirrored the software Installation from the existing machine (P4 2,4 GHz, Sarge with kernel-image-2.4.27-1-386 and kernel-image-2.6.8-2-686), and made new initrd images, grub and fstab adjustments for the new hardware. I also tried kernel-image-2.6.8-11-amd64-k8 and kernel-image-2.6.11-9-amd64-k8 kernel-image-2.6.11-9 from sid as well as a complete new installation of the unofficial AMD64 Port of sarge. I am a little disappointed because I get a stable system only with 32bit Sarge and kernel-image-2.6.8-2-686. Here is how I test: 1) kernel compilation test with the following script: #!/bin/tcsh # ramtest # make ARCH=i386 bzImage foreach i (0 1 2 3 4 5 6 7 8 9) foreach j (0 1 2 3 4 5 6 7 8 9) foreach k (0 1 2 3 4 5 6 7 8 9) ( make clean;make ARCH=i386 bzImage log.$i$j$k ) log.err.$i$j$k end end end I must end up with 1000 identical Logfiles 2) a shell script that produces tar archives in an endless loop #!/bin/sh # io test harddrive while true do echo plattentest gestartet, `date` plattentest.log i=0 while [ $i -le 30 ] do i=`expr $i + 1` tar cf test$i.tar testdir done echo plattentest fertig, `date` plattentest.log rm test*.tar done Test 1) produces randomly premature compiler stops in all 64 bit kernels and in kernel 2.4.27. In the error logs I often find Speicherzugriffsfehler (memory access failure (hopefully translated correctly)) This means you have all the 32Bit Programms mirrored too? And then you try to compile a 64 bit Kernel. As far as I know you have to decide: Either use a pure 32 bit / pure 64 bit systems where all executables are compiled for 32/64 bit. Or you use a 64 Bit System with a chrooted 32 bit system (Or 32 bit with chrooted 64 Bit). There is now possibilty to mix both 32 and 64 bit applications (and of course kernel!) in one system without chroot (again: as far as I know!) By the way: Speicherzugriffsfehler is Segmentation fault in english. Test 2) is stable with 32 bit Kernels, with 64 Bit kernels it crashes the machine (kernel panic) within 10 to 60 minutes. Usually the crash is so fast that I find nothing in the logs, but in one case I was able to trace the Kernel Oops (kernel version kernel-image-2.6.11-9-amd64-k8): [...] I changed RAM (4x 512 MByte) and power supply (450 instead of 300 W) but this had no influence. I assume it cannot be the general stability of the 64 bit kernel and maybe I have a defect motherboard but in that case it feels strange, that kernel 2.6.8-2-686 runs my tests absolut stable whithout any errors (testing time 24 hours). I am glad that after a week of testing I finally found a stable configuration but you have to admit that it is kind of frustrating, that the system consequently refuses to run stable in 64 bit mode. Is this an isolated case with an unlucky hardware mixture or can somebody report similar failures? Any comments or suggestions would be gladly appreciated. Matthias Wenthe My system is running 100% fine with pure 64Bit applications. Of course it's a notebood and I never performd long time tests... Greetings Alexander -- System: AMD64 3400 Notebook running Debian unstable (amd64) with Vanilla Kernel 2.6.13-rc1 (www.kernel.org - no patches) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
