<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi folks,<br>
<br>
this problem I had a few weeks ago with the sundance driver as well.<br>
<br>
I could fix it with merging the original driver into the kernel tree. <br>
Anyway doing that i figured that the problem was caused by the
collision detection. This was resetting to fast the transmitter.<br>
<br>
SNIP with kernel....<br>
if (intr_status & (IntrTxDone | IntrDrvRqst)) {<br>
tx_status = ioread16 (ioaddr + TxStatus);<br>
for (tx_cnt=32; tx_status & 0x80; --tx_cnt) {<br>
if (netif_msg_tx_done(np))<br>
printk<br>
("%s: Transmit status is %2.2x.\n",<br>
dev->name, tx_status);<br>
if (tx_status & 0x1e) {<br>
np->stats.tx_errors++;<br>
if (tx_status & 0x10)<br>
np->stats.tx_fifo_errors++;<br>
if (tx_status & 0x08)<br>
np->stats.collisions++;<br>
if (tx_status & 0x02)<br>
np->stats.tx_window_errors++;<br>
/* This reset has not been verified!. */<br>
if (tx_status & 0x10) { /* Reset the Tx. */<br>
np->stats.tx_fifo_errors++;<br>
spin_lock(&np->lock);<br>
reset_tx(dev);<br>
spin_unlock(&np->lock);<br>
}<br>
if (tx_status & 0x1e) /* Restart the Tx. */<br>
iowrite16 (TxEnable,<br>
ioaddr + MACCtrl1);<br>
}<br>
/* Yup, this is a documentation bug. It cost me
*hours*. */<br>
SNAP with kernel<br>
<br>
SNIP original from DLINK...<br>
if (intr_status & (IntrTxDone | IntrDrvRqst)) {<br>
tx_status = readw (ioaddr + TxStatus);<br>
for (tx_cnt=32; tx_status & 0x80; --tx_cnt)
{<br>
if (netif_msg_tx_done(np))<br>
printk<br>
("%s: Transmit status is
%2.2x.\n",<br>
dev->name, tx_status);<br>
if (tx_status & 0x1e) {<br>
np->stats.tx_errors++;<br>
if (tx_status & 0x10)<br>
np->stats.tx_fifo_errors++;<br>
if (tx_status & 0x08)<br>
np->stats.collisions++;<br>
if (tx_status & 0x02)<br>
np->stats.tx_window_errors++;<br>
/* This reset has not been
verified!. */<br>
if (tx_status & 0x10) { /*
Reset the Tx. */<br>
np->stats.tx_fifo_errors++;<br>
spin_lock(&np->lock);<br>
reset_tx(dev);<br>
spin_unlock(&np->lock);<br>
}<br>
if (tx_status & 0x1e) {<br>
/* It could fail to restart the
tx when MaxCollions, need to try more times */<br>
int i = 10;<br>
do {<br>
writew
(readw(ioaddr + MACCtrl1) | TxEnable, ioaddr + MACCtrl1);<br>
if
(readw(ioaddr + MACCtrl1) & TxEnabled)<br>
break;<br>
mdelay(1);<br>
} while (--i);<br>
}<br>
}<br>
/* Yup, this is a documentation bug.
It cost me *hours*. */<br>
SNAP original from DLINK<br>
<br>
this was the main difference I could find. maybe some body with more
experience can have a look?<br>
both extracts coming from sundance driver function intr_handler<br>
<br>
see you<br>
Frank<br>
<br>
Mary Ellen Foster wrote:
<blockquote cite="midf58861e00505230819275ec392@mail.gmail.com"
type="cite">
<pre wrap="">On 5/23/05, Kevin Huffenberger <a class="moz-txt-link-rfc2396E" href="mailto:khuffenb@gmail.com"><khuffenb@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Meanwhile, the other error messages with regard to networking remain:
i.e. NETDEV WATCHDOG: eth0: transmit timed out. I've attached below
the diagnostics run under the new kernel. I'd like to chase down this
problem, but I'm unsure from what angle to attack.
</pre>
</blockquote>
<pre wrap=""><!---->
These look somewhat similar to problems I'm having with the network
card in my laptop (Broadcom something-or-other; the kernel driver is
b44).
See <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154512">https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154512</a> for a
description of my problems.
MEF
</pre>
</blockquote>
<br>
</body>
</html>