Hi KAS, Many thanks for your detailed suggestion I have checked out the reference you suggested and was convinced you had found the problem - however ..... Changed the memory clock in the BIOS from 200 MHz to 100MHz and did two conplete installs it fell over in exactly the same place as before both times!!!! FC2 i386 and FC2T3 still run OK !!!! I will run the memory checker overnight to double check !!!! Did a text install, it again fell over during post install when trying to open /dev/null which is corrupt. The only corrupt directory entry at the / level is /selinux can this be significant ? Still lots of errors in the anaconda log about accessing over the end of /dev/ram0 It feels like a memory leak or maybe a 64/32 bit variable problem as the errors say things like <6> attempt to access beyond end of device <6> ram0 rw=0 want 1294209566 limit 18432 <3> buffer I/O error on ram0, logical block 647104782 Regards John A On Mon, 14 Jun 2004, K. Spearel wrote: > On Mon, 2004-06-14 at 05:16, Dr J Austin wrote: > > On Wed, 2004-06-03 at 16:25, P.Agenbag wrote > > >Hi List, > > > > >I thought I had the problem solved, but alas... > > > > I would be grateful if you would check out > > bugzilla bug number 123745 > > > > It would seem to be a very similar problem that > > as far as I know has not been solved !! > > > > John A > > > > John, > > I see from your comments on this bug that you only ran memtest86 for 2 > hours. My experience is that you need to run much longer than 2 hours > to get memetest86 to reveal many memory error types on an Athlon64 as, > at least on my A64 system, the errors are due to memory timing...ie the > memory is perfectly good when run within its specifications but the > Athlon64 just doesn't like to run at high latencies. I think AMD > tacitly admits this by specing the Opterons to only run with registered > memory...to absorb potential memory timing errors and clock skew for > maximum reliability. > > In my particular case with an Asus K8V, with the best memory timings I > could come up with for a pair of 512 Mb Samsung DIMMs, I could go for > about 8 to 10 hours running only Test 6 until I got an error. Of > course, I could get a kernel compile to segfault just about every time > if I didn't change system settings to alleviate the problem. So I can > say with some certainty that running the full set of tests for 2 hours > will not necessarily tell you much. > > The simple fact of the matter seems to be that Athlon64s do not play > well with high latency memory. Unless your memory is spec'd to do > 2:2:2, you are apt to have problems. I refer you to the following for > more details: > > http://www.mushkin.com/epages/Mushkin.storefront/40cdb16b01a362f62740c0a801020684/UserTemplate/27 > > Note that this article has evolved over time but the bad news > remains...Athlon64s, with their on-chip memory controller, require fast > memory. Even if you have memory capable of running at 2:2:2, you may > have to slow the timings down due to less than optimal trace routing on > the motherboard, power distribution problems, etc. If your problems > persist, I suggest you slow the Front Side Bus down to 167 Mhz in BIOS > and see if the problems go away...if so, then you have a decision to > make...lower performance or buying faster memory. > > > HTH, > KAS > > > -- > fedora-list mailing list > fedora-list@xxxxxxxxxx > To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list > Dr John Austin, Principal Lecturer, Department of Electronic and Computer Engineering, University of Portsmouth, Anglesea Road, Portsmouth, Hants P01 3DJ Tel: 02392 842541 Fax: 02392 842792 email ja@xxxxxxxxxxxxx
