Subject: Re: FEC_IEVENT_RFIFO_ERROR

From: Babarovic Ivica <[email-masked]>
Date: Thu, 03 Mar 2005 21:07:58 +0100

Hi Sylvain, Dale and others!

Well, I went for a 5 minute walk to get some fresh air and gather my 
thoughts.
To put it shortly I'm mad as hell. I can't believe what a noob mistake 
I've made.
In one of my drivers I had a for loop that loops trough some IO range  
to discover
if hardware is there and instead  of  this for-expression  (i=0; i<31; 
i+=2), I wrote
this one (i=0; i<31; i=+2) . The difference is in =+ and += . Variable i 
never got
incremented past 2 and of course there was chaos because loop was 
running to infinity. :)
Function I was calling in 'infinite' runaway loop did some input and 
output with a custom
bus and read something from a GPIO register. Here it is:
--------------------------------------------------------------
static inline int ebus_echo(char * io)
{
       struct mpc52xx_gpio *gpio;
       volatile unsigned char dummy;

       gpio = (struct mpc52xx_gpio *)MPC52xx_GPIO;

       out_8(RESET_ECHO, 0);
       dummy=in_8(io);
       if (in_8(&gpio->sint_ival) & 0x02)
               return 1;
       return 0;
}
-----------------------------------------------------------------

This driver was initializing itself just before the NIC. I wonder how 
ethernet init
even started and got to the RFIFO part since there was an infinite loop 
running before it?
What a productive day I just had. A stupid typo cost me 12 hours of work 
and I have
nothing to show for. I apologize and I only hope something good comes 
out of this.

/me ducks

Best regards
I.

Sylvain Munaut wrote:

Hi

>
> I tried the patch you've sent and It's still the same.
> FEC_IEVENT_RFIFO_ERROR is still here.
> Can you/anyone think of something that I could do to make
> analyzing this problem easier?
>
Resetting the FEC early is a good thing so that patch should be there 
anyway, so we don't setup irq handlers for a hardware in unknow state.

However looking at fec code, there is another problem with it : The FEC 
is enabled in probe, once for all but the DMA tasks that should empty
the buffers are only enabled when the interface is up, so during it's 
down time, any received packed ends up in filling the FIFO ...

This problem goes away when the interface is up tough, so you should not 
experience 'crash' ... Do you nfs boot ? Try with a static image, just
to see, maybe having the error at boot screw something. If it doesn't 
boot with a static image then there is still another problem.

   Sylvain