FEC_IEVENT_RFIFO_ERROR

[Babarovic Ivica]

Sylvain Munaut wrote:

> 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 changed the card yesterday and I got fresh bootloader on. I don't compile
bootloader, I receive it with the board. Maybe I should change this 
practice.
Anyway as I said I got the new board yesterday with some hardware fixes 
and I
managed to get it up after I set up bootloader environment. It worked 
until this mornig.
I was working on my ( noob :D ) custom drivers and executed another
cycle of make/copy image/reboot  and noticed that for some reason
fec.c and fec_phy.c got also recompiled. After that, things stoped working.
I really don't know why those two got into the make routine but that was
the end of fun. :D
I'm stuck at this error now and lot's of new stuff to learn. :D I don't 
mind that
though although I got completely of track with what I was doing before.

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

I think I understand what you're saying.
Hmmm. I really don't know what bootloader takes care of.
What should I do to check this? Should I try with another
version of bootloader? BTW I got the board with U-Boot 1.1.1.

>
>> 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 ...
>
Ok. I will try with this now.