Re: Duron kernel crash (i686 works)

Wed, 12 Sep 2001 16:48:00 +0300

Hello Alan,
Wednesday, September 12, 2001, 3:48:20 PM, you wrote:
>> So why it is oopses then?
AC> On correct hardware it doesnt seem to oops.

>> Also, we don't want this data to arrive late or whatever.
>> fast_copy_page must copy page (make it so that memcpy()==0).
>> If it does not, it is too much "optimized".
AC> See the "sfence" instruction

I meant instrumented fast_copy_page() cannot fail due to
late movntq commit to memory since memcmp() is behind sfence
and kernel_fpu_end():
>> ...
>> kernel_fpu_end();
>> + /* Check for "Athlon bug" - remove when resolved */
>> + from-=4096;
>> + to-=4096;
>> + if(memcmp(from,to,4096)!=0) {
>> + printk(KERN_ERR "Athlon bug! from=%08X to=%08X\n", from, to);
>> + memcpy(to,from,4096);
>> + }
>> }

If we still see an oops with this instrumentation,
then fast_copy_page() must be clobbering
RAM elsewhere, right?

>> A better way to do it is to bencmark several routines at
>> startup time and pick the best one. It is done now
>> for RAID xor'ing routine.
AC> Not in this case. It is Athlon specific code. It was fine
AC> tuned when it was written

Yes, but sometimes we have routines which perform
differently on different CPUs. See inslude/asm-i386/string.h
and string-486.h: on Pentium rep movsd is faster, on 386 unrolled
loop is faster... so optimal routine can be picked only at runtime.
CPU-specific routines can compete in such runtime benchmark
too when proper processor is detected - see how KNI-specific
RAID xor routine does that.

Best regards, VDA

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to More majordomo info at Please read the FAQ at