From: Babarovic Ivica <ivica@asist-traffic•com>
To: Sylvain Munaut <tnt@246tNt•com>
Cc: linuxppc-embedded@ozlabs•org
Subject: Re: FEC_IEVENT_RFIFO_ERROR
Date: Thu, 03 Mar 2005 16:52:01 +0100 [thread overview]
Message-ID: <422732A1.6060803@asist-traffic.com> (raw)
In-Reply-To: <4227286E.5090406@246tNt.com>
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.
next prev parent reply other threads:[~2005-03-03 15:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-03 13:14 FEC_IEVENT_RFIFO_ERROR Babarovic Ivica
2005-03-03 15:08 ` FEC_IEVENT_RFIFO_ERROR Sylvain Munaut
2005-03-03 15:52 ` Babarovic Ivica [this message]
2005-03-03 16:13 ` FEC_IEVENT_RFIFO_ERROR Babarovic Ivica
2005-03-03 16:59 ` FEC_IEVENT_RFIFO_ERROR Dale Farnsworth
2005-03-03 18:10 ` FEC_IEVENT_RFIFO_ERROR Babarovic Ivica
2005-03-03 19:11 ` FEC_IEVENT_RFIFO_ERROR Sylvain Munaut
-- strict thread matches above, loose matches on Subject: below --
2005-03-03 20:07 FEC_IEVENT_RFIFO_ERROR Babarovic Ivica
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=422732A1.6060803@asist-traffic.com \
--to=ivica@asist-traffic$(echo .)com \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
--cc=tnt@246tNt$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox