On Thu, Nov 20, 2003 at 10:32:47PM -0800, Brian Kuschak wrote: > > > > > What kernel version? What board? Eval or your custom > > one? > > If the custom one, did you try your test on eval? > > > > It's based on 2.4.19 linuxppc_2_4 plus IBM's > 440gx_nova_fp patch.
I got impression that IBM patch wasn't of a good quality (the one against mvl 2.4.17). linuxppc-2.4 tree has some changes for EMAC4, not sure they were in IBM's patch. > Custom hardware. During > previous testing on eval board there was a loss of > connectivity, which in hindsight could have been this > problem. I'm working on reproducing it on the eval > board. > > > How long does it usually take to get into lock up > > state? > > > > I've just ran your "find" cmd for 10 minutes on our > > 440GX board > > without any problems. > > > > With aforementioned command, <5000 to 300,000 packets, > if MSWM bit is disabled or enabled, respectively. > Only happens if nfs is mounted tcp, udp mode doesn't > seem to trigger it, or at least not as quickly. Hmm, I was testing NFS over UDP for 40 min. Not sure I can easily test NFS over TCP. What about netperf? > > What clock mode are you using (533/152, 500/166 or > > smth else)? > > Do you have L2C enabled? If yes, please check > > L2C0_SR for parity > > errors (we have some problems with several our 440GX > > boards). > > > > 666/166. You may want to try lower speeds. May help to isolate problem :) > CONFIG_440GX_L2_INSTRUCTION=y > CONFIG_440GXL2_CACHE=y > > I'll check on the parity errors, although I'm not sure > how that could lockup the EMAC. Well, you can get corrupted code with impredictable results. We are still investigating these L2C parity errors. I saw several times something similar to your situation when EMAC was stuck on faulty board, although I didn't look at it hard. Eugene. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
