After activation of the debug traces in the driver, I see that when the things are going wrong I receive a "TSFT out of range interrupt happen" in my /var/log/message
So there's something in the BIT_26 of my csr5... gasp ???
Here is the code of the interrupt handler...
/* The interrupt handler does all of the Rx thread work and cleans up
after the Tx thread. */
static void adm8201_interrupt(int irq, void *dev_instance,
struct pt_regs *regs)
struct net_device *dev = (struct net_device *) dev_instance;
struct adm8201_private *pDevice = (struct adm8201_private *) dev->priv;
long ioaddr = dev->base_addr;
int work_budget = max_interrupt_work;
csr5 = inl(ioaddr + CSR5);
if ((csr5 & (NormalIntr | AbnormalIntr)) == 0)
outl(csr5 & 0xffffffff, ioaddr + CSR5);
if( csr5 & BIT_30 )
if (csr5 & BIT_26 )
printk("TSFT out of range interrupt happen \n");
Then the code passes in the following part and displays a "RxNoBuf"
if (csr5 & (RxStopped | RxNoBuf))
printk("Abnormal csr5 & (RxStopped | RxNoBuf)\n");
/* Missed a Rx frame or mode change. */
pDevice->stats.rx_missed_errors += inl(ioaddr + CSR8) & 0xffff;
if (csr5 & RxNoBuf)
pDevice->rx_dead = 1;
outl(pDevice->csr6 | RxOn | TxOn, ioaddr + CSR6);
I tried to tweak a bit when the Out of Range is detected, tried to dismiss the Rx Frame, etc... but nothing really better. Maybe I won a few extra seconds of connection but still disconnecting after a while.
I tried as well with the adm8211 version 1.05 (I was using the 1.03 provided by Trendnet) but same issue.
I've also discovered that I'm not alone in this cruel world of ADM 8211 drivers with a discussion quite related.
But the conclusion of this thread is not really hopeful. And of course I could restart my eth1 connection every 30 sec if the network is down, but I'm not sure about the performance...
I'm afraid to have to buy a 10m+ 802.3 cable ... or change the card for one other.
Still happy to receive any help/idea !