Trying to fix 8139too driver problems

[Frank Sander]

Hi folks,

this problem I had a few weeks ago with the sundance driver as well.

I could fix it with merging the original driver into the kernel tree.
Anyway doing that i figured that the problem was caused by the collision 
detection. This was resetting to fast the transmitter.

SNIP with kernel....
        if (intr_status & (IntrTxDone | IntrDrvRqst)) {
            tx_status = ioread16 (ioaddr + TxStatus);
            for (tx_cnt=32; tx_status & 0x80; --tx_cnt) {
                if (netif_msg_tx_done(np))
                    printk
                        ("%s: Transmit status is %2.2x.\n",
                         dev->name, tx_status);
                if (tx_status & 0x1e) {
                    np->stats.tx_errors++;
                    if (tx_status & 0x10)
                        np->stats.tx_fifo_errors++;
                    if (tx_status & 0x08)
                        np->stats.collisions++;
                    if (tx_status & 0x02)
                        np->stats.tx_window_errors++;
                    /* This reset has not been verified!. */
                    if (tx_status & 0x10) {    /* Reset the Tx. */
                        np->stats.tx_fifo_errors++;
                        spin_lock(&np->lock);
                        reset_tx(dev);
                        spin_unlock(&np->lock);
                    }
                    if (tx_status & 0x1e)    /* Restart the Tx. */
                        iowrite16 (TxEnable,
                            ioaddr + MACCtrl1);
                }
                /* Yup, this is a documentation bug.  It cost me *hours*. */
SNAP with kernel

SNIP original from DLINK...
                if (intr_status & (IntrTxDone | IntrDrvRqst)) {
                        tx_status = readw (ioaddr + TxStatus);
                        for (tx_cnt=32; tx_status & 0x80; --tx_cnt) {
                                if (netif_msg_tx_done(np))
                                        printk
                                            ("%s: Transmit status is 
%2.2x.\n",
                                        dev->name, tx_status);
                                if (tx_status & 0x1e) {
                                        np->stats.tx_errors++;
                                        if (tx_status & 0x10)
                                                np->stats.tx_fifo_errors++;
                                        if (tx_status & 0x08)
                                                np->stats.collisions++;
                                        if (tx_status & 0x02)
                                                
np->stats.tx_window_errors++;
                                        /* This reset has not been 
verified!. */
                                        if (tx_status & 0x10) { /* Reset 
the Tx. */
                                                np->stats.tx_fifo_errors++;
                                                spin_lock(&np->lock);
                                                reset_tx(dev);
                                                spin_unlock(&np->lock);
                                        }
                                        if (tx_status & 0x1e) {
                                        /* It could fail to restart the 
tx when MaxCollions, need to try more times */
                                                int i = 10;
                                                do {
                                                        writew 
(readw(ioaddr + MACCtrl1) | TxEnable, ioaddr + MACCtrl1);
                                                        if (readw(ioaddr 
+ MACCtrl1) & TxEnabled)
                                                                break;
                                                        mdelay(1);
                                                } while (--i);
                                        }
                                }
                                /* Yup, this is a documentation bug.  It 
cost me *hours*. */
SNAP original from DLINK

this was the main difference I could find. maybe some body with more 
experience can have a look?
both extracts coming from sundance driver function intr_handler

see you
Frank

Mary Ellen Foster wrote:

>On 5/23/05, Kevin Huffenberger <khuffenb at gmail.com> wrote:
>  
>
>>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.
>>    
>>
>
>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 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154512 for a
>description of my problems.
>
>MEF
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20050523/bb36a552/attachment.htm>