via-rhine timeouts

via-rhine timeouts

Post by Andy Carlso » Thu, 24 Jan 2002 10:10:13



I had problems on a Dragon+ using the kernel via-rhine driver.  I
started using the linxfet driver from the viahardware site.  Solved all
my problems.  I have not tried the kernel driver since early 2.4 series.

Andy Carlson                                    |\      _,,,---,,_

Cat Pics: http://andyc.dyndns.org/animal.html  |,4-  ) )-,_. ,\ (  `'-'
St. Louis, Missouri                           '---''(_/--'  `-'\_)


> I've been getting many errors due to timeouts, everything was fine while
> I was at home, but here at school it's a major problem:

> Jan 22 18:10:00 bouncybouncy kernel: NETDEV WATCHDOG: eth0: transmit
> timed out
> Jan 22 18:10:00 bouncybouncy kernel: eth0: Transmit timed out, status
> 0000, PHY
> status 782d, resetting...
> Jan 22 18:10:10 bouncybouncy kernel: NETDEV WATCHDOG: eth0: transmit
> timed out
> Jan 22 18:10:10 bouncybouncy kernel: eth0: Transmit timed out, status
> 0000, PHY
> status 782d, resetting...
> Jan 22 18:10:18 bouncybouncy kernel: NETDEV WATCHDOG: eth0: transmit
> timed out
> Jan 22 18:10:18 bouncybouncy kernel: eth0: Transmit timed out, status
> 0000, PHY
> status 782d, resetting...
> Jan 22 18:10:26 bouncybouncy kernel: NETDEV WATCHDOG: eth0: transmit
> timed out
> Jan 22 18:10:26 bouncybouncy kernel: eth0: Transmit timed out, status
> 0000, PHY
> status 782d, resetting...
> Jan 22 18:10:34 bouncybouncy kernel: NETDEV WATCHDOG: eth0: transmit
> timed out
> Jan 22 18:10:34 bouncybouncy kernel: eth0: Transmit timed out, status
> 0000, PHY
> status 782d, resetting...

> Jan 22 18:10:34 bouncybouncy kernel: eth0: reset did not complete in 10
> ms.

> once it complains about that, it stops working until I reboot.

> It seems to happen everytime a large transer is done.(apt-get updgrade
> -d the last 3 times.)

> Is this a problem with me, or are the hubs screwy?  The hubs I'm on are
> "smart hubs", lets just say they aren't too bright:)

> I have a soyo k7vdragon+ using 2.4.17:
> eth0: VIA VT6102 Rhine-II at 0xe800, 00:50:2c:01:64:a9, IRQ 11.
> eth0: MII PHY found at address 1, status 0x782d advertising 01e1 Link
> 0021.

> CC replies...
> -Justin
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

via-rhine timeouts

Post by Martin Eriksso » Thu, 24 Jan 2002 19:40:18


----- Original Message -----



Sent: Wednesday, January 23, 2002 2:58 AM
Subject: Re: via-rhine timeouts

> ahhh:)
> I managed to find that driver and installed it
> (http://www.viaarena.com/?PageID=60)

> I transfered a 100M file to someone here via http at 1.1MB/s(according
> to IE, which is usually wrong but still)

> Seems to be working great now
> thanks:)

> I wonder if that driver was included on one of those cd's that came with
> the board, I never thought to look:)

> -Justin

This is extremely interesting! I didn't even know about that page. As I have
a fondness for the via-rhine driver (I have too much of the DFE-530TX cards
at home) I'll start to reverse-engineer ASAP =)

 _____________________________________________________

|  MSc CSE student, department of Computing Science
|  Ume? University, Sweden

- ABIT BP6(RU) - 2xCeleron 400 - 128MB/PC100/C2 Acer
- Maxtor 10/5400/U33 HPT P/M - Seagate 6/5400/DMA2 HPT S/M
- 2xDE-530TX - 1xTulip - Linux 2.4.17+ide+preempt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


 
 
 

via-rhine timeouts

Post by Stephan von Krawczynsk » Fri, 25 Jan 2002 08:30:24



> >     writeb(readb(ioaddr + TxConfig) | 0x80, ioaddr + TxConfig);  
> >     np->tx_thresh = 0x20;                                        
> > (linuxfet.c)                                                      

> >         writeb(0x20, ioaddr + TxConfig);                          
> >         np->tx_thresh = 0x20;                                    
> > (via-rhine.c)                                                    

> > Note how the linuxfet driver sets a higher value but does not make

the                                                                  
Quote:> > tx_thresh follow, so if it later gets a "IntrTxUnderrun" it will  

lower the                                                            
Quote:> > threshold. But the chosen value is probably large enough.        

> > Those of you with this problem could try changing the 0x80 to 0x20

in the                                                                
Quote:> > linuxfet.c driver and see if the problem returns (or the other way

around                                                                

Quote:> > in the via-rhine.c driver).                                      

> That would certainly explain why people are seeing success          
> with linuxfet.                                                      

> Here's the test patch which you describe.  It would be              
> useful if people could try it..                                    

Forgive me being stupid, but shouldn't the comment behind follow      
somehow?                                                              
I may be dead wrong, but you're increasing the initial treshold here,
or not?                                                              
Please ignore me if I am way off.                                    

Regards,                                                              
Stephan                                                              

--- linux-2.4.18-pre6/drivers/net/via-rhine.c   Tue Jan 22 12:38:30 2002

        /* Initialize other registers. */                                  
        writew(0x0006, ioaddr + PCIBusConfig);  /* Tune configuration??? */  
        /* Configure the FIFO thresholds. */                                
-       writeb(0x20, ioaddr + TxConfig);        /* Initial threshold 32 bytes */  
+       writeb(0x80, ioaddr + TxConfig);        /* Initial threshold 128 bytes */  
        np->tx_thresh = 0x20;                                              
        np->rx_thresh = 0x60;                        /* Written in via_rhine_set_rx_mode(). */  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

via-rhine timeouts

Post by Urban Widmar » Fri, 25 Jan 2002 09:00:32



> Forgive me being stupid, but shouldn't the comment behind follow      
> somehow?                                                              
> I may be dead wrong, but you're increasing the initial treshold here,
> or not?                                                              
> Please ignore me if I am way off.                                    

The hardware doesn't care about the comment in the source code. :)

Anyway, 32bytes is incorrect for the vt6102. According to the vt6102
docs 0x20 is 256 bytes and 0x80 is "store&forward".

Test it, if it helps the comment can be changed to something that is
correct (like /* Initial threshold */ ?)

/Urban

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

via-rhine timeouts

Post by Andy Carlso » Fri, 25 Jan 2002 10:40:09


I tried this, and the problem did not go away.  I got about 300K/S
versus the 7-8M/S I get with the linuxfet driver.

Andy Carlson                                    |\      _,,,---,,_

Cat Pics: http://andyc.dyndns.org/animal.html  |,4-  ) )-,_. ,\ (  `'-'
St. Louis, Missouri                           '---''(_/--'  `-'\_)



> >     writeb(readb(ioaddr + TxConfig) | 0x80, ioaddr + TxConfig);
> >     np->tx_thresh = 0x20;
> > (linuxfet.c)

> >         writeb(0x20, ioaddr + TxConfig);
> >         np->tx_thresh = 0x20;
> > (via-rhine.c)

> > Note how the linuxfet driver sets a higher value but does not make the
> > tx_thresh follow, so if it later gets a "IntrTxUnderrun" it will lower the
> > threshold. But the chosen value is probably large enough.

> > Those of you with this problem could try changing the 0x80 to 0x20 in the
> > linuxfet.c driver and see if the problem returns (or the other way around
> > in the via-rhine.c driver).

> That would certainly explain why people are seeing success
> with linuxfet.

> Here's the test patch which you describe.  It would be
> useful if people could try it..

> --- linux-2.4.18-pre6/drivers/net/via-rhine.c      Tue Jan 22 12:38:30 2002
> +++ linux-akpm/drivers/net/via-rhine.c     Wed Jan 23 12:42:18 2002

>    /* Initialize other registers. */
>    writew(0x0006, ioaddr + PCIBusConfig);  /* Tune configuration??? */
>    /* Configure the FIFO thresholds. */
> -  writeb(0x20, ioaddr + TxConfig);        /* Initial threshold 32 bytes */
> +  writeb(0x80, ioaddr + TxConfig);        /* Initial threshold 32 bytes */
>    np->tx_thresh = 0x20;
>    np->rx_thresh = 0x60;                        /* Written in via_rhine_set_rx_mode(). */

> -

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

1. via-rhine timeouts

I re-addressed the email...the CC's got out of hand...

Ok, it was working for a while, even after a reboot...
but now
 21:04:33 up 2 days, 20 min, 10 users,  load average: 0.12, 0.47, 0.38

Jan 28 01:39:10 bouncybouncy kernel: eth0: Transmitter underflow?,
status 2008.
Jan 28 01:39:20 bouncybouncy kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 28 01:39:20 bouncybouncy kernel: eth0: Transmit timed out, status
0000, PHY status 782d, resetting...
Jan 28 01:39:20 bouncybouncy kernel: eth0: reset finished after 5
microseconds.
Jan 28 02:23:22 bouncybouncy kernel: eth0: Transmitter underflow?,
status 2008.
Jan 28 02:23:26 bouncybouncy kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 28 02:23:26 bouncybouncy kernel: eth0: Transmit timed out, status
0000, PHY status 782d, resetting...
Jan 28 02:23:26 bouncybouncy kernel: eth0: reset finished after 5
microseconds.

This went unnoticed earlier.... until it happened again:

Jan 28 20:26:03 bouncybouncy kernel: eth0: Transmitter underflow?,
status 2008.
Jan 28 20:26:06 bouncybouncy kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 28 20:26:06 bouncybouncy kernel: eth0: Transmit timed out, status
0000, PHY status 782d, resetting...
Jan 28 20:26:06 bouncybouncy kernel: eth0: reset finished after 10005
microseconds.

That repeated over and over again(every 30 seconds or so) until I got
back:

grep "Jan 28.*eth0" /var/log/messages|wc -l
    328
After reloading the driver it started working again:

linuxfet.c : v3.23 05/15/2001
  The PCI BIOS has not enabled the device at 0/144!  Updating PCI
command 0003->0007.
eth0: VIA PCI 10/100Mb Fast Ethernet Adapter                      
eth0: IO Address = 0xe800, MAC Address = 00:50:2c:01:64:a9, IRQ = 11.
eth0: MII PHY found at address 1, status 0x782d advertising 01e1 Link
0021.
eth0: netdev_open() irq 11.
eth0: Done netdev_open(), status 881a MII status: 782d.

I think that last message might be a clue on why this is happening...

--
-Justin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. VM accounting 1/3 trivial

3. VIA Rhine timeouts

4. can the process let another process sleep & wakeup?

5. via-rhine.c net driver/VIA VT6102 Rhine-II runs in spurts

6. FVWM'95 Segmentation Fault

7. OpenBSD3.3 D-Link DFE-530TX (Via-Rhine) watchdog timeout error

8. Tape Backup --> root Floppy configuration

9. via rhine bug? (timeouts and resets)

10. via-rhine weirdness with via kt8235 Southbridge

11. via-rhine.c to support new VIA's nic chip VT6105, V6105M (correct).

12. via-rhine.c to support new VIA's nic chip VT 6105, V6105M(corrected)