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
TRFC                    9-15 CLK
TRCD                    2-6  CLK
TWR                     2-3  CLK
TRWT                    1-6  CLK
TRAS                    5-15 CLK
TRP                     2-6  CLK
TWLC                    1-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]

Reply via email to