Hi
> I run 2.6.10-rc2 kernel (http://www.246tNt.com/mpc52xx/)
> for MPC5200 chip on a custom board that is almost lite5200 compatible.
> I noticed a couple of times I have a strange error at bootup.
> It was FEC_IEVENT_RFIFO_ERROR. Most of the times this
> went trough without problems but since today system just hangs.
> Sometimes with several printouts of this error.
> ---boot sequence ------
> FEC_IEVENT_RFIFO_ERROR
> FEC_IEVENT_RFIFO_ERROR
> FEC_IEVENT_RFIFO_ERROR
> ....
Theses are definitly not "normal" but you said "since today it just hangs",
did something change in the environment of the card ?
> I traced a problem a bit and found that this happenes at
> mpc52xx_fec_probe() function in fec.c at this point:
> -----------------------------------------------------------------------------------------
>
>
> /* Get the IRQ we need one by one */
> /* Control */
> dev->irq = ocp->def->irq;
> --> if (request_irq(dev->irq, &fec_interrupt, SA_INTERRUPT,
> "mpc52xx_fec_ctrl", dev)) {
> printk(KERN_ERR "mpc52xx_fec: ctrl interrupt request
> failed\n");
> ret = -EBUSY;
> dev->irq = -1; /* Don't try to free it */
> goto probe_error;
> }
> ------------------------------------------------------------------------------------------
>
>
It ovbiously can't happen before since the message it printed in that
interrupt
handler. But it should not happen there either (not so early) !
This error globally says : "Somthing got wrong with the receive buffer". But
at this point, frame reception is not yet enabled, how could it go wrong
? Unless
your bootloader don't take care of shutting down the fec, then frames
may be
stuck in the fifo between the bootloader and the fec init ...
> This is what I found in MPC5200 Users Manual:
> Receive FIFO Error--indicates error occurred within the forest green
> version
> RX FIFO. When RFIFO_ERROR bit is set, ECNTRL.ETHER_EN is cleared,
> halting FEC frame processing. When this occurs, software must ensure both
> the FIFO Controller and BestComm are soft-reset.
>
> Any ideas on what could be causing this?
I can't explain why this happen so early at init (as I said before) but
other things that could
cause such an event :
- We don't have enough buffer descriptors : The bescomm task just fill
them all and runs out
of them before the interrupt is handled.
- The bestcomm engine don't flush the RX fifo quicly enough. Currently
the only tasks
- Bestcomm stopped processing for whatever reason ...
- Something else that I don't see at the moment. I'll try to "stress
test" network a little bit,
see if I can reproduce the issue.
In the mean time, pull the latest change, I just pushed some fixes
related to frame reception,
I don't think it's related to your issue but ...
Sylvain
