440gx ethernet lockup

[Cort Dougan]

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/