I am trying to debug a problem with ipipe. I am using 3.0.13 kernel with
adeos-ipipe-3.0.13-arm-1.18-09.patch
applied. The CPU is a Freescale MX35, which is an ARM11 architecture. The issue
is that I get an MDIO read timeout
from the FEC driver. I have tried using the ipipe trace, but when I turn it on,
the problem goes away. I have
managed to discover that if I put a 300 microsecond delay into the transmit
path of the FEC interrupt handler,
the problem goes away. Thus drivers/net/fec.c has a udelay(300) in the transmit
interrupt handling path as follows:
static irqreturn_t
fec_enet_interrupt(int irq, void *dev_id)
{
struct net_device *ndev = dev_id;
struct fec_enet_private *fep = netdev_priv(ndev);
uint int_events;
irqreturn_t ret = IRQ_NONE;
do {
int_events = readl(fep->hwp + FEC_IEVENT);
writel(int_events, fep->hwp + FEC_IEVENT);
if (int_events & FEC_ENET_RXF) {
ret = IRQ_HANDLED;
fec_enet_rx(ndev);
}
/* Transmit OK, or non-fatal error. Update the buffer
* descriptors. FEC handles all errors, we just discover
* them as part of the transmit process.
*/
if (int_events & FEC_ENET_TXF) {
ret = IRQ_HANDLED;
fec_enet_tx(ndev);
udelay(300);
}
if (int_events & FEC_ENET_MII) {
ret = IRQ_HANDLED;
complete(&fep->mdio_done);
}
} while (int_events);
return ret;
}
A diff would be as follows:
diff -r d5a7342d6e47 drivers/net/fec.c
--- a/drivers/net/fec.c Tue May 29 09:58:21 2012 -0400
+++ b/drivers/net/fec.c Tue May 29 10:49:24 2012 -0400
@@ -703,6 +703,7 @@
if (int_events & FEC_ENET_TXF) {
ret = IRQ_HANDLED;
fec_enet_tx(ndev);
+ udelay(300);
}
if (int_events & FEC_ENET_MII) {
Smaller delays don't work. I know this isn't a fix. My question is, does this
information give the
experts any ideas on what the real problem might be?
Cheers,
Chris.
Chris Stone
Embedded Linux Architect
Optelian
1 Brewer Hunt Way
Ottawa, Ontario K2K 2B5
Phone: 613-287-2000 x2106
www.optelian.com
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
