Hi! (Thanks !) I guess I need some more education - since I am getting my problem right at the boot - is I-Cache enabled (by default ?) for 8xx on 2.6 at the booting ? - I do not see anything in .config which controls it (or I am missing it there ?) How (where and at what point during the boot)-) I could disable I-Cache ?
Thanks, Alex -----Original Message----- From: paul.bilke [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 28, 2004 12:13 PM To: Wolfgang Denk Cc: Povolotsky, Alexander; linuxppc-embedded at ozlabs.org Subject: Re: simple bootloader 2.6.10-rc3 8xx Actually wd is right, one quick check to see if this is the problem is to disable the I-Cache. The problem only shows up the the I cache enabled. I ran my 870 with them disabled for months (I know its painful) until I got the powers that be to approve wd to spend the time we did not have to fix it. Some of the best money I ever spent. Paul Wolfgang Denk wrote: >Dear Alex, > >in message <313680C9A886D511A06000204840E1CF0A64741E at whq-msgusr-02.pit.comms.marconi.co m> you wrote: > > >> >> >> >>>Moving things around in the kernel sometimes >>>makes this go away but really its just hidden. >>>In my case it would explode in zlib_inflate also. Putting some output >>>in the routine would move it ... >>> >>> >>Yes that is exactly what I have observed (but I did'nt have the correct >>explanation for it) >> >> > >I think Paul may be right with his suspicion; it sounds like a >manifestation of the CPU15 problem (but it could also be incorrectly >initialized SDRAMs which fail during heavy load with burst mode >accesses, or one more instability of the 2.6 kernel on 8xx systems). > >Note that all our work relating to this problem was done on the 2.4 >kernel base, and I make no claims that it might actually help for >your 2.6 problems. > > > >>Could this code be used for 2.6 ? >> >> > >The patch does not apply cleanly as is to the 2.6 tree, but it should >be simple enough to port. > > > >>Could someone point me to it, please ? >> >> > >It's in the linuxppc_2_4_devel tree on our CVS server. > >Please find attached the patch to the 2.4 kernel tree which >implements the workaround, and a test application to reliably >reproduce the CPU15 errata. It usually takes 1-10 minutes for the >application to crash, if the workaround is disabled: > > bash-2.05b# date; ./cpu15 ; date > Thu Aug 2 02:02:42 MEST 2001 > Illegal instruction > Thu Aug 2 02:02:54 MEST 2001 > bash-2.05b# date; ./cpu15 ; date > Thu Aug 2 02:02:58 MEST 2001 > Illegal instruction > Thu Aug 2 02:03:48 MEST 2001 > bash-2.05b# date; ./cpu15 ; date > Thu Aug 2 02:03:54 MEST 2001 > Illegal instruction > Thu Aug 2 02:03:57 MEST 2001 > bash-2.05b# date; ./cpu15 ; date > Thu Aug 2 02:04:07 MEST 2001 > Illegal instruction > Thu Aug 2 02:04:16 MEST 2001 > bash-2.05b# > >We noticed that some background activitly, like logging in/out to the >target via 'telnet', while the application is running over the serial >console, additionally speeds up the crash. > >You can use this command to enable the workaround at run-time (it is >disabled by default): > > bash# sysctl -w kernel.8xx_cpu15=1 > >Please note that for the h/w problem to show up, the instruction >cache has to be enabled. > >Hope this helps. > >Best regards, > >Wolfgang Denk > > > >------------------------------------------------------------------------ > >_______________________________________________ >Linuxppc-embedded mailing list >Linuxppc-embedded at ozlabs.org >https://ozlabs.org/mailman/listinfo/linuxppc-embedded >
