> the memory copy in the fast_page_copy routine. The machine then
> proceeded
> not to stop at my panic, but I got my "normal" oopses. I then had an
Ok
> idea and removed all the prefetch instructions from the beginning of the
> routine and tried the resultin kernel. I now have no crashes.
> What could this mean?
I think it has to mean a hardware problem.
> Here is a nother patch just so you can keep me honest if I
> made another mistake:
There is a mistake but you wont trigger it. It is no longer 26 bytes 8)
That patch is only used when the prefetchw faults with an illegal instruction
and is done so you can boot an athlon kernel on a lesser cpu
The prefetch instructions hint to the CPU what memory we will access very soon.
The primary effect of that is that we hit full theoretical memory bandwidth
when copying pages. It doesnt really change execution behaviour in any other
way which then does rather point to cpu or other hardware problem. The very
early athlons had prefetch bugs but we would not trigger those and no reporters
have such an early CPU.
What still stands out is that exactly _zero_ people have reported the same
problem with non VIA chipset Athlons.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 07 2001 - 21:00:20 EST