[RFC] Workaround for G4 CPU data corruption bug

[RFC] Workaround for G4 CPU data corruption bug

[Gerhard Pircher]

Hi,

I need to fix the CPU bug described here:
http://ozlabs.org/pipermail/linuxppc-dev/2004-August/017440.html

The bug is worked around in Linux (since a long time) by enabling coherency (M bit) for all memory mappings. Unfortunately my AmigaOne crashes badly with this workaround (the system simply stops after setting up the PCI host controller). I'm afraid I don't know about any snoop control settings within the northbridge.

Thus the only workaround I can think of would be to disable the L2 cache prefetch logic. But would this workaround be accepted in the Linux source tree (only for one architecture) or does anybody know another workaround?

Thanks in advance!

regards,

Gerhard

-- 
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

Re: [RFC] Workaround for G4 CPU data corruption bug

[Benjamin Herrenschmidt]

On Thu, 2006-11-16 at 09:48 +0100, Gerhard Pircher wrote:
> Hi,
> 
> I need to fix the CPU bug described here:
> http://ozlabs.org/pipermail/linuxppc-dev/2004-August/017440.html
> 
> The bug is worked around in Linux (since a long time) by enabling coherency (M bit) for all memory mappings. Unfortunately my AmigaOne crashes badly with this workaround (the system simply stops after setting up the PCI host controller). I'm afraid I don't know about any snoop control settings within the northbridge.
> 
> Thus the only workaround I can think of would be to disable the L2 cache prefetch logic. But would this workaround be accepted in the Linux source tree (only for one architecture) or does anybody know another workaround?

Not sure what the best approach is at this point. The platform probing
occurs after the CPU fixups on 32 bits, though I want to change that to
be more like 64 bits in the future, it's not yet done.

Ben.