440gx ethernet lockup

[Brian Kuschak]

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.
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/