via-rhine timeouts

via-rhine timeouts

[Justin A]

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

Re: via-rhine timeouts

[Urban Widmark]

On Tue, 22 Jan 2002, Justin A wrote:

> 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:

You did get them at home too? (with the same (type of) hardware?)

> 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.

10ms is a very long time. Normally the hardware resets a lot faster than
that, and when it doesn't I suspect it is in some really bad state.

You are not the first to report this. And it is a message that could be
caused by a lot of things, I guess.


But I have finally managed to get these timeouts to happen on my VT6102
too (using an evil combination of running a remote Internet Explorer over
VNC). I have planned to examine it, but I probably won't get around to
that for at least a couple of weeks.

Some ideas you could try:
+ The via-rhine driver at
  http://www.scyld.com/network/ethercard.html
  (the one in the kernel is almost the same as this one)
+ Move the card to another slot (remove/re-arrange other cards in the box)
+ Since it appears to be load related, perhaps it can be hidden by slowing
  things down (eg add a small udelay() to via_rhine_start_tx)

(or you could try to figure out what the driver is doing when these 
 things happen.)

/Urban

Re: via-rhine timeouts

[Justin A]

On Wed, Jan 23, 2002 at 01:37:05AM +0100, Urban Widmark wrote:
> On Tue, 22 Jan 2002, Justin A wrote:
> 
> > 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:
> 
> You did get them at home too? (with the same (type of) hardware?)
>
(checks his logs) no, first time I got that message was at school.
(I just found out something, read the end of this email)
> 
> > 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.
> 
> 10ms is a very long time. Normally the hardware resets a lot faster than
> that, and when it doesn't I suspect it is in some really bad state.
> 
> You are not the first to report this. And it is a message that could be
> caused by a lot of things, I guess.

It only does that after resetting the card over and over again, perhaps
it tries to reset it again before its ready?

> 
> But I have finally managed to get these timeouts to happen on my VT6102
> too (using an evil combination of running a remote Internet Explorer over
> VNC). I have planned to examine it, but I probably won't get around to
> that for at least a couple of weeks.
> 
> Some ideas you could try:
> + The via-rhine driver at
>   http://www.scyld.com/network/ethercard.html
>   (the one in the kernel is almost the same as this one)

I tried to build that, the compile command it had didn't work, it ended
up thinking it was compiled for 2.4.13. Probably need to have it include
/usr/src/linux/include/linux or something.

> + Move the card to another slot (remove/re-arrange other cards in the box)
It's built into the motherboard:)

> + Since it appears to be load related, perhaps it can be hidden by slowing
>   things down (eg add a small udelay() to via_rhine_start_tx)
> 
> (or you could try to figure out what the driver is doing when these 
>  things happen.)
> 
> /Urban
> 

I just found this in my old logs:
Nov 18 19:01:14 bouncybouncy kernel: NETDEV WATCHDOG: eth0: transmit timed out
Nov 18 19:01:14 bouncybouncy kernel: eth0: transmit timed out, Tx_status 00 status 2000 Tx FIFO room 520.

That was with my old motherboard, and an isa 3c509.

The 'smart' hubs here have had many problems in the past, I think they
are still supposed to be replaced soon with normal switches.  Could it
just be that the hub gets confused up and the card resets itself for no
reason?

-Justin

Re: via-rhine timeouts

[Urban Widmark]

On Tue, 22 Jan 2002, Justin A wrote:

> It only does that after resetting the card over and over again, perhaps
> it tries to reset it again before its ready?

Andrew Morton sent me some stuff on this. It seems via changed the
meaning of some register bits, but the driver doesn't understand that. So
it reads certain status events all wrong and does the wrong thing.

I'll have a look and see if I can do something over the weekend.


> > + Move the card to another slot (remove/re-arrange other cards in the box)
> It's built into the motherboard:)

So bring out your soldering iron ... :)


> I just found this in my old logs:
> Nov 18 19:01:14 bouncybouncy kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Nov 18 19:01:14 bouncybouncy kernel: eth0: transmit timed out, Tx_status 00 status 2000 Tx FIFO room 520.
> 
> That was with my old motherboard, and an isa 3c509.

Probably completely unrelated as it is a different card and a different
mb (and a different network?).

/Urban

Re: via-rhine timeouts

[Stephan von Krawczynski]

On Wed, 23 Jan 2002 10:44:17 +0100 (CET)
Urban Widmark <urban@teststation.com> wrote:

> On Tue, 22 Jan 2002, Justin A wrote:
> 
> > It only does that after resetting the card over and over again, perhaps
> > it tries to reset it again before its ready?
> 
> Andrew Morton sent me some stuff on this. It seems via changed the
> meaning of some register bits, but the driver doesn't understand that. So
> it reads certain status events all wrong and does the wrong thing.
> 
> I'll have a look and see if I can do something over the weekend.

Would be very nice to have some fix. These cards are in widespread use...

Regards,
Stephan

Re: via-rhine timeouts

[Andy Carlson]

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                                    |\      _,,,---,,_
naclos@swbell.net                         ZZZzz /,`.-'`'    -.  ;-;;,_
Cat Pics: http://andyc.dyndns.org/animal.html  |,4-  ) )-,_. ,\ (  `'-'
St. Louis, Missouri                           '---''(_/--'  `-'\_)


On Tue, 22 Jan 2002, Justin A wrote:

> 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
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: via-rhine timeouts

[Justin A]

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

On Tue, Jan 22, 2002 at 07:07:16PM -0600, Andy Carlson wrote:
> 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                                    |\      _,,,---,,_
> naclos@swbell.net                         ZZZzz /,`.-'`'    -.  ;-;;,_
> Cat Pics: http://andyc.dyndns.org/animal.html  |,4-  ) )-,_. ,\ (  `'-'
> St. Louis, Missouri                           '---''(_/--'  `-'\_)
> 
> 
> On Tue, 22 Jan 2002, Justin A wrote:
> 
> > 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
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
> 

Re: via-rhine timeouts

[Martin Eriksson]

----- Original Message -----
From: "Justin A" <justin@bouncybouncy.net>
To: "Andy Carlson" <naclos@swbell.net>
Cc: <linux-kernel@vger.kernel.org>
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 =)

 _____________________________________________________
|  Martin Eriksson <nitrax@giron.wox.org>
|  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

Re: via-rhine timeouts

[Urban Widmark]

On Wed, 23 Jan 2002, Martin Eriksson wrote:

> >
> > 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 =)

It's not much to reverse engineer, it comes in source form.

It's based on Donald Beckers via-rhine, they have added code for some
hardware issues(?) and removed some copyright texts. Some of the
workarounds have already been added to the kernel driver (I have seen a
similar version of this driver before).

I believe the reason that driver works better is that they use a larger
starting value for the TX threshold.

    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).

/Urban

Re: via-rhine timeouts

[Andrew Morton]

Urban Widmark wrote:
> 
>     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
@@ -965,7 +965,7 @@ static void init_registers(struct net_de
 	/* 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(). */
 
-

Re: via-rhine timeouts

[Stephan von Krawczynski]

> Urban Widmark wrote:                                                
> >                                                                   
> >     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..                                     
                                                                      
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
+++ linux-akpm/drivers/net/via-rhine.c	Wed Jan 23 12:42:18 2002       
@@ -965,7 +965,7 @@ static void init_registers(struct net_de          
 	/* 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(). */   
                                                                      
                                                                      

Re: via-rhine timeouts

[Urban Widmark]

On Thu, 24 Jan 2002, Stephan von Krawczynski wrote:

> 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

Re: via-rhine timeouts

[Justin A]

I don't think thats the full problem, I just noticed I had been getting
errors too with the via driver, but it's been working fine otherwise:

(heres all of them, don't know what was going on at all the times, but I
was browsing the web for a bit at 9:50)

Jan 23 00:56:56 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 00:57:30 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 00:58:50 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 00:59:50 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 01:12:45 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 01:14:38 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 01:23:13 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 01:37:20 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 01:44:13 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 02:04:27 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 02:12:48 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 03:12:29 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 04:40:48 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 04:42:13 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 04:43:50 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 04:44:16 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 04:47:58 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 04:49:32 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 09:43:40 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 09:44:32 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 09:45:52 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 09:49:33 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 09:51:50 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
Jan 23 17:55:15 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.

the status makes sense from what I can tell, I could never figure out
what 782d was.
ifconfig reports:
TX packets:657170 errors:52 dropped:0 overruns:0 carrier:52

Is it possible that the problem is with the hub and via-rhine resetting
the card repetedly just makes it worse?

-Justin

On Wed, Jan 23, 2002 at 12:44:21PM -0800, Andrew Morton wrote:
> Urban Widmark wrote:
> > 
> >     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
> @@ -965,7 +965,7 @@ static void init_registers(struct net_de
>  	/* 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(). */
>  
> -
> 

Re: via-rhine timeouts

[Urban Widmark]

On Wed, 23 Jan 2002, Justin A wrote:

> I don't think thats the full problem, I just noticed I had been getting
> errors too with the via driver, but it's been working fine otherwise:
> 
[snip]
> Jan 23 09:45:52 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
> Jan 23 09:49:33 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
> Jan 23 09:51:50 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
> Jan 23 17:55:15 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.

0100 is that it sees too many collisions. The netdev watchdog I can
trigger seems to be caused by a lot of collisions.


> Is it possible that the problem is with the hub and via-rhine resetting
> the card repetedly just makes it worse?

The hub can be the problem and I suppose resetting could make something
worse (if it is done wrong, for example).

/Urban

Re: via-rhine timeouts

[Martin Eriksson]

[-- Attachment #1: Type: text/plain, Size: 3247 bytes --]

----- Original Message -----
From: "Justin A" <justin@bouncybouncy.net>
To: "Andrew Morton" <akpm@zip.com.au>
Cc: "Urban Widmark" <urban@teststation.com>; "Martin Eriksson"
<nitrax@giron.wox.org>; "Andy Carlson" <naclos@swbell.net>;
<linux-kernel@vger.kernel.org>; "Stephan von Krawczynski" <skraw@ithnet.com>
Sent: Thursday, January 24, 2002 12:41 AM
Subject: Re: via-rhine timeouts


> I don't think thats the full problem, I just noticed I had been getting
> errors too with the via driver, but it's been working fine otherwise:
>
> (heres all of them, don't know what was going on at all the times, but I
> was browsing the web for a bit at 9:50)
>
> Jan 23 00:56:56 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
<snip>
>
> the status makes sense from what I can tell, I could never figure out
> what 782d was.
> ifconfig reports:
> TX packets:657170 errors:52 dropped:0 overruns:0 carrier:52
>
> Is it possible that the problem is with the hub and via-rhine resetting
> the card repetedly just makes it worse?

Hmm, if I'm not wrong, it seems that the linuxfet driver is doing some
strange hack on txstatus 0x0800 and 0x0100. Instead of waiting for
netdev_error to handle things it does its own stuff:

np->tx_ring[entry].tx_status = cpu_to_le32(DescOwn);
writel(virt_to_bus(&np->tx_ring[entry]), ioaddr + TxRingPtr);
/* Turn on Tx On*/
writew(CmdTxOn | np->chip_cmd, dev->base_addr + ChipCmd);
/* Stats counted in Tx-done handler, just restart Tx. */
writew(CmdTxDemand | np->chip_cmd, dev->base_addr + ChipCmd);

What differs from the normal error handler is the "CmdTxOn" command I guess.
But I am also seeing that they have removed any entry from "if (intr_status
& IntrTxAbort) {" in "netdev_error". Might 0x0100 be the new secret abort
code?

What if you tried (or at least reviewed) this patch: (also attached, as OE
foggs opp whitespace)

--- via-rhine.c.orig Fri Dec 21 18:41:54 2001
+++ via-rhine.c Thu Jan 24 09:30:42 2002
@@ -1264,7 +1264,7 @@

   /* Abnormal error summary/uncommon events handlers. */
   if (intr_status & (IntrPCIErr | IntrLinkChange | IntrMIIChange |
-         IntrStatsMax | IntrTxAbort | IntrTxUnderrun))
+         IntrStatsMax | IntrTxAbort | IntrTxUnderrun | 0x0100))
    via_rhine_error(dev, intr_status);

   if (--boguscnt < 0) {
@@ -1481,8 +1481,14 @@
    printk(KERN_INFO "%s: Transmitter underrun, increasing Tx "
        "threshold setting to %2.2x.\n", dev->name, np->tx_thresh);
  }
+ if (intr_status & 0x0100) {
+  /* VIA hack */
+  writew(CmdTxOn | np->chip_cmd, dev->base_addr + ChipCmd);
+  /* Restart Tx */
+  writew(CmdTxDemand | np->chip_cmd, dev->base_addr + ChipCmd);
+ }
  if ((intr_status & ~( IntrLinkChange | IntrStatsMax |
-        IntrTxAbort | IntrTxAborted))) {
+        IntrTxAbort | IntrTxAborted | 0x0100))) {
   if (debug > 1)
    printk(KERN_ERR "%s: Something Wicked happened! %4.4x.\n",
       dev->name, intr_status);


 _____________________________________________________
|  Martin Eriksson <nitrax@giron.wox.org>
|  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

[-- Attachment #2: via-rhine.patch --]
[-- Type: application/octet-stream, Size: 1070 bytes --]

--- via-rhine.c.orig	Fri Dec 21 18:41:54 2001
+++ via-rhine.c	Thu Jan 24 09:30:42 2002
@@ -1264,7 +1264,7 @@
 
 		/* Abnormal error summary/uncommon events handlers. */
 		if (intr_status & (IntrPCIErr | IntrLinkChange | IntrMIIChange |
-						   IntrStatsMax | IntrTxAbort | IntrTxUnderrun))
+						   IntrStatsMax | IntrTxAbort | IntrTxUnderrun | 0x0100))
 			via_rhine_error(dev, intr_status);
 
 		if (--boguscnt < 0) {
@@ -1481,8 +1481,14 @@
 			printk(KERN_INFO "%s: Transmitter underrun, increasing Tx "
 				   "threshold setting to %2.2x.\n", dev->name, np->tx_thresh);
 	}
+	if (intr_status & 0x0100) {
+		/* VIA hack */
+		writew(CmdTxOn | np->chip_cmd, dev->base_addr + ChipCmd);
+		/* Restart Tx */
+		writew(CmdTxDemand | np->chip_cmd, dev->base_addr + ChipCmd);
+	}
 	if ((intr_status & ~( IntrLinkChange | IntrStatsMax |
-						  IntrTxAbort | IntrTxAborted))) {
+						  IntrTxAbort | IntrTxAborted | 0x0100))) {
 		if (debug > 1)
 			printk(KERN_ERR "%s: Something Wicked happened! %4.4x.\n",
 			   dev->name, intr_status);

Re: via-rhine timeouts

[Andy Carlson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3906 bytes --]

I tried this patch, and it made not change, unless it was maybe a little
worse :).

Andy Carlson                                    |\      _,,,---,,_
naclos@swbell.net                         ZZZzz /,`.-'`'    -.  ;-;;,_
Cat Pics: http://andyc.dyndns.org/animal.html  |,4-  ) )-,_. ,\ (  `'-'
St. Louis, Missouri                           '---''(_/--'  `-'\_)


On Thu, 24 Jan 2002, Martin Eriksson wrote:

> ----- Original Message -----
> From: "Justin A" <justin@bouncybouncy.net>
> To: "Andrew Morton" <akpm@zip.com.au>
> Cc: "Urban Widmark" <urban@teststation.com>; "Martin Eriksson"
> <nitrax@giron.wox.org>; "Andy Carlson" <naclos@swbell.net>;
> <linux-kernel@vger.kernel.org>; "Stephan von Krawczynski" <skraw@ithnet.com>
> Sent: Thursday, January 24, 2002 12:41 AM
> Subject: Re: via-rhine timeouts
>
>
> > I don't think thats the full problem, I just noticed I had been getting
> > errors too with the via driver, but it's been working fine otherwise:
> >
> > (heres all of them, don't know what was going on at all the times, but I
> > was browsing the web for a bit at 9:50)
> >
> > Jan 23 00:56:56 bouncybouncy kernel: eth0: Transmit error, Tx status 8100.
> <snip>
> >
> > the status makes sense from what I can tell, I could never figure out
> > what 782d was.
> > ifconfig reports:
> > TX packets:657170 errors:52 dropped:0 overruns:0 carrier:52
> >
> > Is it possible that the problem is with the hub and via-rhine resetting
> > the card repetedly just makes it worse?
>
> Hmm, if I'm not wrong, it seems that the linuxfet driver is doing some
> strange hack on txstatus 0x0800 and 0x0100. Instead of waiting for
> netdev_error to handle things it does its own stuff:
>
> np->tx_ring[entry].tx_status = cpu_to_le32(DescOwn);
> writel(virt_to_bus(&np->tx_ring[entry]), ioaddr + TxRingPtr);
> /* Turn on Tx On*/
> writew(CmdTxOn | np->chip_cmd, dev->base_addr + ChipCmd);
> /* Stats counted in Tx-done handler, just restart Tx. */
> writew(CmdTxDemand | np->chip_cmd, dev->base_addr + ChipCmd);
>
> What differs from the normal error handler is the "CmdTxOn" command I guess.
> But I am also seeing that they have removed any entry from "if (intr_status
> & IntrTxAbort) {" in "netdev_error". Might 0x0100 be the new secret abort
> code?
>
> What if you tried (or at least reviewed) this patch: (also attached, as OE
> foggs opp whitespace)
>
> --- via-rhine.c.orig Fri Dec 21 18:41:54 2001
> +++ via-rhine.c Thu Jan 24 09:30:42 2002
> @@ -1264,7 +1264,7 @@
>
>    /* Abnormal error summary/uncommon events handlers. */
>    if (intr_status & (IntrPCIErr | IntrLinkChange | IntrMIIChange |
> -         IntrStatsMax | IntrTxAbort | IntrTxUnderrun))
> +         IntrStatsMax | IntrTxAbort | IntrTxUnderrun | 0x0100))
>     via_rhine_error(dev, intr_status);
>
>    if (--boguscnt < 0) {
> @@ -1481,8 +1481,14 @@
>     printk(KERN_INFO "%s: Transmitter underrun, increasing Tx "
>         "threshold setting to %2.2x.\n", dev->name, np->tx_thresh);
>   }
> + if (intr_status & 0x0100) {
> +  /* VIA hack */
> +  writew(CmdTxOn | np->chip_cmd, dev->base_addr + ChipCmd);
> +  /* Restart Tx */
> +  writew(CmdTxDemand | np->chip_cmd, dev->base_addr + ChipCmd);
> + }
>   if ((intr_status & ~( IntrLinkChange | IntrStatsMax |
> -        IntrTxAbort | IntrTxAborted))) {
> +        IntrTxAbort | IntrTxAborted | 0x0100))) {
>    if (debug > 1)
>     printk(KERN_ERR "%s: Something Wicked happened! %4.4x.\n",
>        dev->name, intr_status);
>
>
>  _____________________________________________________
> |  Martin Eriksson <nitrax@giron.wox.org>
> |  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
>

[-- Attachment #2: Type: APPLICATION/OCTET-STREAM, Size: 1070 bytes --]

--- via-rhine.c.orig	Fri Dec 21 18:41:54 2001
+++ via-rhine.c	Thu Jan 24 09:30:42 2002
@@ -1264,7 +1264,7 @@
 
 		/* Abnormal error summary/uncommon events handlers. */
 		if (intr_status & (IntrPCIErr | IntrLinkChange | IntrMIIChange |
-						   IntrStatsMax | IntrTxAbort | IntrTxUnderrun))
+						   IntrStatsMax | IntrTxAbort | IntrTxUnderrun | 0x0100))
 			via_rhine_error(dev, intr_status);
 
 		if (--boguscnt < 0) {
@@ -1481,8 +1481,14 @@
 			printk(KERN_INFO "%s: Transmitter underrun, increasing Tx "
 				   "threshold setting to %2.2x.\n", dev->name, np->tx_thresh);
 	}
+	if (intr_status & 0x0100) {
+		/* VIA hack */
+		writew(CmdTxOn | np->chip_cmd, dev->base_addr + ChipCmd);
+		/* Restart Tx */
+		writew(CmdTxDemand | np->chip_cmd, dev->base_addr + ChipCmd);
+	}
 	if ((intr_status & ~( IntrLinkChange | IntrStatsMax |
-						  IntrTxAbort | IntrTxAborted))) {
+						  IntrTxAbort | IntrTxAborted | 0x0100))) {
 		if (debug > 1)
 			printk(KERN_ERR "%s: Something Wicked happened! %4.4x.\n",
 			   dev->name, intr_status);

Re: via-rhine timeouts

[Martin Eriksson]

----- Original Message -----
From: "Andy Carlson" <naclos@swbell.net>
To: "Martin Eriksson" <nitrax@giron.wox.org>
Cc: "Justin A" <justin@bouncybouncy.net>; "Andrew Morton" <akpm@zip.com.au>;
"Urban Widmark" <urban@teststation.com>; <linux-kernel@vger.kernel.org>;
"Stephan von Krawczynski" <skraw@ithnet.com>
Sent: Thursday, January 24, 2002 2:01 PM
Subject: Re: via-rhine timeouts


I tried this patch, and it made not change, unless it was maybe a little
worse :).



Well I guess someone better than me has to research this more thoroughly
then =) I don't really have the time... (gonna make some nice persian food
for my wife).

 _____________________________________________________
|  Martin Eriksson <nitrax@giron.wox.org>
|  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

Re: via-rhine timeouts

[Andy Carlson]

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                                    |\      _,,,---,,_
naclos@swbell.net                         ZZZzz /,`.-'`'    -.  ;-;;,_
Cat Pics: http://andyc.dyndns.org/animal.html  |,4-  ) )-,_. ,\ (  `'-'
St. Louis, Missouri                           '---''(_/--'  `-'\_)


On Wed, 23 Jan 2002, Andrew Morton wrote:

> Urban Widmark wrote:
> >
> >     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
> @@ -965,7 +965,7 @@ static void init_registers(struct net_de
>  	/* 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(). */
>
> -
>

AW: via-rhine timeouts

[Roland Schwarz]

Hi there !

I have the same problems with an older gigabyte dual p2 mainboard an 3com
pci network cards, thread posted some days ago.
I have now mooved the network cards through the slots, the first time it
apeared only with ine card, now there are three cards in the machine and it
works fine.
I think it was a problem with the interrupt sharing in combination with some
heavier network load.

[cut from syslog]
Jan 17 10:18:20 highfidelity kernel: eth0: Interrupt posted but not
delivered -- IRQ blocked by another device?
Jan 17 10:18:20 highfidelity kernel:   Flags; bus-master 1, dirty
11892733(13) current 11892733(13)
Jan 17 10:18:20 highfidelity kernel:   Transmit list 00000000 vs. cf505540.
Jan 17 10:18:20 highfidelity kernel:   0: @cf505200  length 800000ff status
000100ff

[...continue until reboot or until bored]

so for the last days with "reorganized card arrangement" the systems run
really fine, and it is definitly under heavy load ..
( i'm mirroring some pages and transferring some gigabytes of files to
friends .. just for testing )
ifconfig gave me a thoughput of ~ 4 Gigabytes over three days, that looks
fine.
for the moment :-)

So, if your network card is mounted onboard, maybe you can play around with
the bios settings so change something ?

I hope, that can help you a little .


have fun & may the tux-force be with you !

blacky ( roland ... )




-----Ursprungliche Nachricht-----
Von: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]Im Auftrag von Justin A
Gesendet: Mittwoch, 23. Januar 2002 00:42
An: linux-kernel@vger.kernel.org
Betreff: via-rhine timeouts


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
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/