Re: 2.6.29 & network stack strangeness

[Matthew Lear <matt@bubblegen.co.uk>]

Lanttor wrote:
> I met the interrupt issue before on mcf5445x platform, following is my fixed patch, but I am not sure it could help resolve your problem, just have a try  :-) 

Thanks but this makes no difference. From what I can tell, the patch to entry.S
is essentially benign because ret_from_interrupt() is not invoked anywhere.

Also, the patch to ints.c adds invocations of irq_enter() and irq_exit()
to process_int(). These macros really just force entry/exit to/from hard
interrupt context and increment/decrement a count (used for tracking
nested interrupts). Given that process_int() is called by inthandler() in
entry.S, I think this is always going to be in interrupt context anyway, so I
can't see the advantage of this. Maybe I'm missing something?

> 
> For your mcf54455 platform, if you use one ether net port, try to disable second ether net port (FEC2) on the menuconfig to see whether it would affect the net working. 

Yes. I've already got the second net port disabled.

I have had some level of success by calling flush_cache_all() immediately after
calling netif_rx() in the rx part of the fec interrupt handler - fec_enet_rx()
in fec.c.

This plus a hack to netif_rx() seems to vastly improve things in that I can wget
large files, run netcat tests although in the cast of netcat there is still a
high number of rx overruns in the fec driver.

Hack:

--- a/net/core/dev.c        2009-05-12 07:02:24.000000000 +0100
+++ b/net/core/dev.c       2009-06-10 10:26:47.000000000 +0100
@@ -1969,16 +1969,18 @@
                        __skb_queue_tail(&queue->input_pkt_queue, skb);
                        local_irq_restore(flags);
                        return NET_RX_SUCCESS;
                }

                napi_schedule(&queue->backlog);
                goto enqueue;
        }
+        else
+                napi_schedule(&queue->backlog);

        __get_cpu_var(netdev_rx_stat).dropped++;
        local_irq_restore(flags);

        kfree_skb(skb);
        return NET_RX_DROP;
 }

This effectively ignores the backlog check and schedules the receive function to
run.

I think all this points to is that there is a timing problem in the system. That
said, I can believe the cache coherency issue as I've read some postings on the
net about similar issues with ethernet tx on ppc...

--  Matt