"Anders K. Pedersen" wrote:
> 
> ...
> > Would you be able to grab
> > vortex-diag.c from http://www.scyld.com/diag/ and do this?
> 
> Done - the output is:

Thanks.

> vortex-diag.c:v2.00 4/19/2000 Donald Becker ([EMAIL PROTECTED])
>  http://www.scyld.com/diag/index.html
> Index #1: Found a 3Com 3c590 Vortex 10Mbps adapter at 0x6200.
> The Vortex chip may be active, so FIFO registers will not be read.
> To see all register values use the '-f' flag.
> Initial window 7, registers values by window:
>   Window 0: 0000 0000 0000 0000 0000 00bf 0000 0000.
>   Window 1: FIFO FIFO 0000 2000 8000 00ff 0ffc 2000.
>   Window 2: a000 cb24 e4d2 0000 0000 0000 00de 4000.
>   Window 3: 0010 0102 0000 0000 e138 0fff 0fff 6000.
>   Window 4: 0000 00d1 0000 0c80 0000 88c0 0000 8000.
>   Window 5: 1ffc 1ffc 00de 1ffc 0007 02de 00de a000.
              ^^^^
             ^^^^^^

Bummer.

Are you running the card as a bus master?  That is, are you inserting
the module with:

   modprobe 3c59x options=0x10

or do you have

   options 3c59x options=0x10

in /etc/conf.modules?

If not, then you may care to try this.   It doesn't explain the problem,
but it may get you out of trouble...

> ...
> 
> Are you thinking of something like the following (I don't know what you
> mean by "force a new BH Tx run")?
> 
> *** 3c59x.c.orig        Wed May 24 00:15:19 2000
> --- 3c59x.c     Wed May 24 13:12:08 2000
> ***************
> *** 1489,1502 ****
> --- 1497,1511 ----
>         if (do_tx_reset) {
>                 int j;
>                 outw(TxReset, ioaddr + EL3_CMD);
>                 for (j = 200; j >= 0 ; j--)
>                         if ( ! (inw(ioaddr + EL3_STATUS) & CmdInProgress))
>                                 break;
>                 outw(TxEnable, ioaddr + EL3_CMD);
> +               clear_bit(0, (void*)&dev->tbusy);
>         }
> 
>   }

Yep.

The BH Tx run was me mumbling to myself :)  It refers to signalling the
higher layers of the network code to (almost) immediately try to
transmit another packet, if one is queued.

You may care to try
http://www.uow.edu.au/~andrewm/linux/3c59x.c-2.2.16-pre4.gz (uncompress
it and drop it on top of drivers/net/3c59x.c).  I don't expect it to
make the underruns go away though.

Has this card always generated these underruns?  Or is it a result of
installing a new kernel?  Any root cause you can point at?

-- 
-akpm-
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]

Reply via email to