[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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)



Reply to: