ppcsup seems to be pretty busy lately. I've pushed them on some important issues and they take action but it seems that there are a lot of very important issues right now.
} I found the problem. Our SEEPROM was misconfigured to } set the MAL clock to PLB/4. This resulted in a MAL } clock of 41MHz, apparently too slow... After changing } the MAL clock to PLB/1, the system ran for days } without any problems. Unfortunately I couldn't find } any IBM docs which specify requirements for the MAL } clock, and IBM still hasn't responded. } } BTW, is anyone else having trouble with ppcsupp } lately? } } Brian } } } > > > 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. } > } > } } -- Cort Dougan Director of Engineering, FSMLabs Office: (505) 838-9109 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
