Re: State of ibook G4 sleep support in 2.6.11?
On Fri, 2005-03-04 at 01:32 +0100, Sebastien NOEL wrote:
> On Fri, 04 Mar 2005 09:40:48 +1100 , Benjamin Herrenschmidt wrote:
>
> > > this crash look like /dev/random, one time i have xmon, another time not;
> > > one time the keyboard works in xmon, another time not :/
> >
> > Ok, looks like memory corruption then. What is your CPU model ?
>
> cat /proc/cpuinfo
> processor : 0
> cpu : 7455, altivec supported
> clock : 931MHz
> revision : 3.3 (pvr 8001 0303)
> bogomips : 936.65
> machine : PowerBook6,3
> motherboard : PowerBook6,3 MacRISC3 Power Macintosh
> detected as : 287 (iBook G4)
> pmac flags : 0000001b
> L2 cache : 256K unified
> memory : 640MB
> pmac-generation : NewWorld
>
> > It could be the RAM thing you told me about, or it could be the cache
> > flushing...
>
> I hope that it is not the RAM (apple hardare test run fine without any glitch)
Ok, look at arch/ppc/platforms/pmac_sleep.S, there is this bit of code:
/* Due to a bug with the HW flush on some CPU revs, we occasionally
* experience data corruption. I'm adding a displacement flush along
* with a dcbf loop over a few Mb to "help". The problem isn't totally
* fixed by this in theory, but at least, in practice, I couldn't reproduce
* it even with a big hammer...
*/
lis r4,0x0002
mtctr r4
li r4,0
1:
lwzx r0,r0,r4
addi r4,r4,32 /* Go to start of next cache line */
bdnz 1b
isync
/* Now, flush the first 4MB of memory */
lis r4,0x0002
mtctr r4
li r4,0
sync
1:
dcbf 0,r4
addi r4,r4,32 /* Go to start of next cache line */
bdnz 1b
Can you change the 2 instances of "lis r4,0x0002" to "lis r4,0x0020" ?
It will cause the code to flush 16 times more memory :) A bit gross, but it would
probably tell us if this is the problem.
Ben.
Reply to: