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/

Re: via-rhine timeouts

[Justin A]

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

On Sat, 2002-01-26 at 10:21, Urban Widmark wrote:
> 
> Hello, troubled via-rhine users ...
> 
> The attached patch vs 2.4.17 is a merge of bits from various sources. It
> contains useful stuff such as turning on bit2 in the cards PCI
> configuration register 0x53 (undocumented).
> 
> Please test this and see if the problems go away. Note that this version
> reports a little more information, so send 'dmesg' output even of you 
> sent it before.
> 

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

Re: via-rhine timeouts

[Urban Widmark]

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

On 28 Jan 2002, Justin A wrote:

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

This is not a transmit underflow (I was lazy when adding that message,
this is what the ? is about). It is a transmit abort caused by excessive
collisions.
2000 - transmit abort because of excessive collisions
0008 - transmit error

It is interesting that the linuxfet driver does not fail/recovers. I have
added some more code from that driver and attached a new version of the
patch. It re-initializes the ring pointer and tells the card to try to
transmit the packet again.


> Jan 28 20:26:06 bouncybouncy kernel: eth0: reset finished after 10005
> microseconds.

The "You have reset me too many times. Go away." error.


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

0003->0007 is that it turns on bus mastering. I have copied the code from
the linuxfet driver that sets that bit. But for me that is set later by
the pci_set_master function, and I think the warning is incorrect.

After reloading the linuxfet driver, does the via-rhine driver work better
if you switch back to it without rebooting?


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

Which message are you refering to? I don't feel particularly clueful after
reading any of it. :)

/Urban

[-- Attachment #2: Type: TEXT/PLAIN, Size: 18555 bytes --]

diff -urN -X exclude linux-2.4.17-orig/drivers/net/via-rhine.c linux-2.4.17-rhine/drivers/net/via-rhine.c
--- linux-2.4.17-orig/drivers/net/via-rhine.c	Sat Jan 12 16:56:50 2002
+++ linux-2.4.17-rhine/drivers/net/via-rhine.c	Tue Jan 29 21:49:43 2002
@@ -82,7 +82,7 @@
 /* A few user-configurable values.
    These may be modified when a driver module is loaded. */
 
-static int debug = 1;			/* 1 normal messages, 0 quiet .. 7 verbose. */
+static int debug = 3;			/* 1 normal messages, 0 quiet .. 7 verbose. */
 static int max_interrupt_work = 20;
 
 /* Set the copy breakpoint for the copy-only-tiny-frames scheme.
@@ -318,7 +318,7 @@
 
 enum chip_capability_flags {
 	CanHaveMII=1, HasESIPhy=2, HasDavicomPhy=4,
-	ReqTxAlign=0x10, HasWOL=0x20, };
+	ReqTxAlign=0x10, HasWOL=0x20, HasIntTxUnderFlow=0x40, };
 
 #ifdef USE_MEM
 #define RHINE_IOTYPE (PCI_USES_MEM | PCI_USES_MASTER | PCI_ADDR1)
@@ -332,11 +332,13 @@
 	{ "VIA VT86C100A Rhine", RHINE_IOTYPE, 128,
 	  CanHaveMII | ReqTxAlign },
 	{ "VIA VT6102 Rhine-II", RHINE_IOTYPE, 256,
-	  CanHaveMII | HasWOL },
+	  CanHaveMII | HasWOL | HasIntTxUnderFlow },
 	{ "VIA VT3043 Rhine",    RHINE_IOTYPE, 128,
 	  CanHaveMII | ReqTxAlign }
 };
 
+#define MII_DAVICOM_DM9101		0x0181b800
+
 static struct pci_device_id via_rhine_pci_tbl[] __devinitdata =
 {
 	{0x1106, 0x6100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VT86C100A},
@@ -373,27 +375,14 @@
 	IntrRxDone=0x0001, IntrRxErr=0x0004, IntrRxEmpty=0x0020,
 	IntrTxDone=0x0002, IntrTxAbort=0x0008, IntrTxUnderrun=0x0010,
 	IntrPCIErr=0x0040,
-	IntrStatsMax=0x0080, IntrRxEarly=0x0100, IntrMIIChange=0x0200,
+	IntrStatsMax=0x0080, IntrRxEarly=0x0100,
+	IntrMIIChange=0x0200, IntrTxUnderflow=0x0200,	/* see HasIntTxUnderFlow */
 	IntrRxOverflow=0x0400, IntrRxDropped=0x0800, IntrRxNoBuf=0x1000,
 	IntrTxAborted=0x2000, IntrLinkChange=0x4000,
 	IntrRxWakeUp=0x8000,
 	IntrNormalSummary=0x0003, IntrAbnormalSummary=0xC260,
 };
 
-/* MII interface, status flags.
-   Not to be confused with the MIIStatus register ... */
-enum mii_status_bits {
-	MIICap100T4			= 0x8000,
-	MIICap10100HdFd		= 0x7800,
-	MIIPreambleSupr		= 0x0040,
-	MIIAutoNegCompleted	= 0x0020,
-	MIIRemoteFault		= 0x0010,
-	MIICapAutoNeg		= 0x0008,
-	MIILink				= 0x0004,
-	MIIJabber			= 0x0002,
-	MIIExtended			= 0x0001
-};
-
 /* The Rx and Tx buffer descriptors. */
 struct rx_desc {
 	s32 rx_status;
@@ -453,6 +442,7 @@
 
 	/* Frequently used values: keep some adjacent for cache effect. */
 	int chip_id, drv_flags;
+	u8 rev_id;
 	struct rx_desc *rx_head_desc;
 	unsigned int cur_rx, dirty_rx;		/* Producer/consumer ring indices */
 	unsigned int cur_tx, dirty_tx;
@@ -469,13 +459,13 @@
 	u16 advertising;					/* NWay media advertisement */
 	unsigned char phys[MAX_MII_CNT];			/* MII device addresses. */
 	unsigned int mii_cnt;			/* number of MIIs found, but only the first one is used */
-	u16 mii_status;						/* last read MII status */
+	u32 mii;
 };
 
 static int  mdio_read(struct net_device *dev, int phy_id, int location);
 static void mdio_write(struct net_device *dev, int phy_id, int location, int value);
 static int  via_rhine_open(struct net_device *dev);
-static void via_rhine_check_duplex(struct net_device *dev);
+static int  via_rhine_check_duplex(struct net_device *dev);
 static void via_rhine_timer(unsigned long data);
 static void via_rhine_tx_timeout(struct net_device *dev);
 static int  via_rhine_start_tx(struct sk_buff *skb, struct net_device *dev);
@@ -554,7 +544,8 @@
 #ifdef USE_MEM
 	long ioaddr0;
 #endif
-	
+	u16 pci_command, new_command;
+
 /* when built into the kernel, we only print version if device is found */
 #ifndef MODULE
 	static int printed_version;
@@ -570,6 +561,9 @@
 	if (pci_enable_device (pdev))
 		goto err_out;
 
+	pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
+	printk(KERN_DEBUG "PCI_COMMAND: %4.4x\n", pci_command);
+
 	/* this should always be supported */
 	if (pci_set_dma_mask(pdev, 0xffffffff)) {
 		printk(KERN_ERR "32-bit PCI DMA addresses not supported by the card!?\n");
@@ -589,6 +583,20 @@
 	if (pci_flags & PCI_USES_MASTER)
 		pci_set_master (pdev);
 
+	pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
+	printk(KERN_DEBUG "PCI_COMMAND: %4.4x\n", pci_command);
+	if (!(pci_command & PCI_COMMAND_MASTER)) {
+		/* Try to set */
+		printk(KERN_INFO "  The PCI BIOS has not enabled the"
+			   " device at %d/%d!  Updating PCI command %4.4x->%4.4x.\n",
+			   pdev->bus->number, pdev->devfn, pci_command, new_command);
+		new_command = pci_command | (pci_flags & 7);
+		pci_write_config_word(pdev, PCI_COMMAND, new_command);
+
+		pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
+		printk(KERN_DEBUG "PCI_COMMAND: %4.4x\n", pci_command);
+	}
+
 	dev = alloc_etherdev(sizeof(*np));
 	if (dev == NULL) {
 		printk (KERN_ERR "init_ethernet failed for card #%d\n", card_idx);
@@ -667,19 +675,31 @@
 		goto err_out_unmap;
 	}
 
+	/* "3065" specials ... */
 	if (chip_id == VT6102) {
+		u8 mode3_reg;
+
 		/*
 		 * for 3065D, EEPROM reloaded will cause bit 0 in MAC_REG_CFGA
 		 * turned on.  it makes MAC receive magic packet
 		 * automatically. So, we turn it off. (D-Link)
 		 */
 		writeb(readb(ioaddr + ConfigA) & 0xFE, ioaddr + ConfigA);
+
+		/*
+		 * turn on bit2 in PCI configuration register 0x53 ("PCI_REG_MODE3")
+		 * 0x04 == MODE3_MIION
+		 * FIXME: what does this do?
+		 */
+		pci_read_config_byte(pdev, 0x53, &mode3_reg);
+		pci_write_config_byte(pdev, 0x53, mode3_reg | 0x04);
 	}
 
 	dev->irq = pdev->irq;
 
 	np = dev->priv;
 	spin_lock_init (&np->lock);
+	pci_read_config_byte(pdev, PCI_REVISION_ID, &(np->rev_id));
 	np->chip_id = chip_id;
 	np->drv_flags = via_rhine_chip_info[chip_id].drv_flags;
 	np->pdev = pdev;
@@ -718,8 +738,9 @@
 	if (i)
 		goto err_out_unmap;
 
-	printk(KERN_INFO "%s: %s at 0x%lx, ",
+	printk(KERN_INFO "%s: %s (rev 0x%02x) at 0x%lx, ",
 		   dev->name, via_rhine_chip_info[chip_id].name,
+		   np->rev_id,
 		   (pci_flags & PCI_USES_IO) ? ioaddr : memaddr);
 
 	for (i = 0; i < 5; i++)
@@ -732,23 +753,26 @@
 		int phy, phy_idx = 0;
 		np->phys[0] = 1;		/* Standard for this chip. */
 		for (phy = 1; phy < 32 && phy_idx < MAX_MII_CNT; phy++) {
-			int mii_status = mdio_read(dev, phy, 1);
+			int mii_status = mdio_read(dev, phy, MII_BMSR);
 			if (mii_status != 0xffff  &&  mii_status != 0x0000) {
 				np->phys[phy_idx++] = phy;
-				np->advertising = mdio_read(dev, phy, 4);
-				printk(KERN_INFO "%s: MII PHY found at address %d, status "
+				np->advertising = mdio_read(dev, phy, MII_ADVERTISE);
+				np->mii = (mdio_read(dev, phy, MII_PHYSID1) << 16) +
+					mdio_read(dev, phy, MII_PHYSID2);
+				printk(KERN_INFO "%s: MII PHY %8.8x found at address %d, status "
 					   "0x%4.4x advertising %4.4x Link %4.4x.\n",
-					   dev->name, phy, mii_status, np->advertising,
-					   mdio_read(dev, phy, 5));
+					   dev->name, np->mii, phy, mii_status, np->advertising,
+					   mdio_read(dev, phy, MII_LPA));
 
-				/* set IFF_RUNNING */
-				if (mii_status & MIILink)
-					netif_carrier_on(dev);
-				else
-					netif_carrier_off(dev);
+				if ((np->mii & ~0xf) == MII_DAVICOM_DM9101)
+					np->drv_flags |= HasDavicomPhy;
 			}
 		}
 		np->mii_cnt = phy_idx;
+		if (phy_idx == 0) {
+			printk(KERN_WARNING "%s: MII PHY not found -- this device may "
+				   "not operate correctly.\n", dev->name);
+		}
 	}
 
 	/* Allow forcing the media type. */
@@ -757,15 +781,13 @@
 			np->full_duplex = 1;
 		np->default_port = option & 0x3ff;
 		if (np->default_port & 0x330) {
-			/* FIXME: shouldn't someone check this variable? */
-			/* np->medialock = 1; */
 			printk(KERN_INFO "  Forcing %dMbs %s-duplex operation.\n",
 				   (option & 0x300 ? 100 : 10),
 				   (option & 0x220 ? "full" : "half"));
 			if (np->mii_cnt)
-				mdio_write(dev, np->phys[0], 0,
-						   ((option & 0x300) ? 0x2000 : 0) |  /* 100mbps? */
-						   ((option & 0x220) ? 0x0100 : 0));  /* Full duplex? */
+				mdio_write(dev, np->phys[0], MII_BMCR,
+						   ((option & 0x300) ? 0x2000 : 0) |  /* 100mbps */
+						   ((option & 0x220) ? 0x0100 : 0));  /* Full duplex */
 		}
 	}
 
@@ -946,10 +968,26 @@
 	for (i = 0; i < 6; i++)
 		writeb(dev->dev_addr[i], ioaddr + StationAddr + i);
 
-	/* Initialize other registers. */
+	/* Turn on bit3 (OFSET) in TCR during MAC initialization. */
+	writeb(readb(ioaddr + TxConfig) | 0x08, ioaddr + TxConfig);
+
+	/* Turn off mauto */
+	writeb(readb(ioaddr + MIICmd) & 0x7f, ioaddr + MIICmd);
+	if (np->drv_flags & HasDavicomPhy)  {
+		udelay(100);
+	} else {
+		int boguscnt = 0x3fff;
+		while (!(readb(ioaddr + MIIRegAddr) & 0x80) && --boguscnt > 0)
+			;
+	}
+
 	writew(0x0006, ioaddr + PCIBusConfig);	/* Tune configuration??? */
+
+	/* Clear the lower 4 bits in Config D. */
+	outb(inb(ioaddr + ConfigD) & 0xf0, ioaddr + ConfigD);
+
 	/* Configure the FIFO thresholds. */
-	writeb(0x20, ioaddr + TxConfig);	/* Initial threshold 32 bytes */
+	writeb(0x20, ioaddr + TxConfig);	/* Initial threshold */
 	np->tx_thresh = 0x20;
 	np->rx_thresh = 0x60;			/* Written in via_rhine_set_rx_mode(). */
 
@@ -972,13 +1010,31 @@
 		np->chip_cmd |= CmdFDuplex;
 	writew(np->chip_cmd, ioaddr + ChipCmd);
 
+	/* Restart MII auto-negotiation for davidcom phy bug */
+	if (np->drv_flags & HasDavicomPhy) {
+		mdio_write(dev,np->phys[0], MII_BMCR,
+				   mdio_read(dev, np->phys[0], MII_BMCR) | 0x1200);
+		/* FIXME: shouldn't we wait for it to complete? Adding silly-delay. */
+		udelay(100);
+	}
+
 	via_rhine_check_duplex(dev);
 
 	/* The LED outputs of various MII xcvrs should be configured.  */
+	/* For Davicom phys, turn on bit 5 in register 0x16. */
 	/* For NS or Mison phys, turn on bit 1 in register 0x17 */
 	/* For ESI phys, turn on bit 7 in register 0x17. */
-	mdio_write(dev, np->phys[0], 0x17, mdio_read(dev, np->phys[0], 0x17) |
-			   (np->drv_flags & HasESIPhy) ? 0x0080 : 0x0001);
+	if (np->drv_flags & HasDavicomPhy) {
+		mdio_write(dev, np->phys[0], 0x16,
+				   mdio_read(dev, np->phys[0], 0x16) | 0x20);
+	} else if (np->drv_flags & HasESIPhy) {
+		mdio_write(dev, np->phys[0], 0x17,
+				   mdio_read(dev, np->phys[0], 0x17) | 0x80);
+	} else {
+		/* All unknowns get this. Could be a problem. */
+		mdio_write(dev, np->phys[0], 0x17,
+				   mdio_read(dev, np->phys[0], 0x17) | 0x01);
+	}
 }
 /* Read and write over the MII Management Data I/O (MDIO) interface. */
 
@@ -1059,7 +1115,7 @@
 		printk(KERN_DEBUG "%s: Done via_rhine_open(), status %4.4x "
 			   "MII status: %4.4x.\n",
 			   dev->name, readw(ioaddr + ChipCmd),
-			   mdio_read(dev, np->phys[0], 1));
+			   mdio_read(dev, np->phys[0], MII_BMSR));
 
 	netif_start_queue(dev);
 
@@ -1073,29 +1129,70 @@
 	return 0;
 }
 
-static void via_rhine_check_duplex(struct net_device *dev)
+static int via_rhine_check_duplex(struct net_device *dev)
 {
 	struct netdev_private *np = dev->priv;
 	long ioaddr = dev->base_addr;
-	int mii_reg5 = mdio_read(dev, np->phys[0], 5);
-	int negotiated = mii_reg5 & np->advertising;
+	int mii_reg;
 	int duplex;
+	int changed = 0;
 
-	if (np->duplex_lock  ||  mii_reg5 == 0xffff)
-		return;
-	duplex = (negotiated & 0x0100) || (negotiated & 0x01C0) == 0x0040;
+	mii_reg = mdio_read(dev, np->phys[0], MII_BMSR);
+	if (mii_reg == 0xffff)
+		return changed;
+
+	if (debug > 3)
+		printk(KERN_DEBUG "%s: MII #%d reports: %4.4x, carrier is: %d\n",
+			   dev->name, np->phys[0], mii_reg, netif_carrier_ok(dev));
+	if (!(mii_reg & BMSR_LSTATUS)) {
+		if (netif_carrier_ok(dev)) {
+			if (debug > 1)
+				printk(KERN_DEBUG "%s: MII #%d reports no link. Disabling watchdog.\n",
+					   dev->name, np->phys[0]);
+			netif_carrier_off(dev);
+		}
+	} else if (!netif_carrier_ok(dev)) {
+		if (debug > 1)
+			printk(KERN_DEBUG "%s: MII #%d link is back. Enabling watchdog.\n",
+				   dev->name, np->phys[0]);
+		netif_carrier_on(dev);
+	}
+
+	if (np->drv_flags & HasDavicomPhy) {
+		/* If the link partner doesn't support autonegotiation
+		 * the MII detects it's abilities with the "parallel detection".
+		 * Some MIIs update the LPA register to the result of the parallel
+		 * detection, some don't.
+		 * The Davicom PHY [at least 0181b800] doesn't.
+		 * Instead bit 8 and 13 of the BMCR are updated to the result
+		 * of the negotiation..
+		 */
+		mii_reg = mdio_read(dev, np->phys[0], MII_BMCR);
+		duplex = mii_reg & 0x100;
+	} else {
+		int negotiated;
+		mii_reg = mdio_read(dev, np->phys[0], MII_LPA);
+		negotiated = mii_reg & np->advertising;
+
+		duplex = (negotiated & 0x0100) || ((negotiated & 0x02C0) == 0x0040);
+	}
+
+	if (np->duplex_lock || mii_reg == 0xffff)
+		return changed;
 	if (np->full_duplex != duplex) {
 		np->full_duplex = duplex;
+		changed = 1;
 		if (debug)
 			printk(KERN_INFO "%s: Setting %s-duplex based on MII #%d link"
 				   " partner capability of %4.4x.\n", dev->name,
-				   duplex ? "full" : "half", np->phys[0], mii_reg5);
+				   duplex ? "full" : "half", np->phys[0], mii_reg);
 		if (duplex)
 			np->chip_cmd |= CmdFDuplex;
 		else
 			np->chip_cmd &= ~CmdFDuplex;
 		writew(np->chip_cmd, ioaddr + ChipCmd);
 	}
+	return changed;
 }
 
 
@@ -1105,7 +1202,6 @@
 	struct netdev_private *np = dev->priv;
 	long ioaddr = dev->base_addr;
 	int next_tick = 10*HZ;
-	int mii_status;
 
 	if (debug > 3) {
 		printk(KERN_DEBUG "%s: VIA Rhine monitor tick, status %4.4x.\n",
@@ -1113,19 +1209,7 @@
 	}
 
 	spin_lock_irq (&np->lock);
-
 	via_rhine_check_duplex(dev);
-
-	/* make IFF_RUNNING follow the MII status bit "Link established" */
-	mii_status = mdio_read(dev, np->phys[0], 1);
-	if ( (mii_status & MIILink) != (np->mii_status & MIILink) ) {
-		if (mii_status & MIILink)
-			netif_carrier_on(dev);
-		else
-			netif_carrier_off(dev);
-	}
-	np->mii_status = mii_status;
-
 	spin_unlock_irq (&np->lock);
 
 	np->timer.expires = jiffies + next_tick;
@@ -1141,7 +1225,7 @@
 	printk (KERN_WARNING "%s: Transmit timed out, status %4.4x, PHY status "
 		"%4.4x, resetting...\n",
 		dev->name, readw (ioaddr + IntrStatus),
-		mdio_read (dev, np->phys[0], 1));
+		mdio_read (dev, np->phys[0], MII_BMSR));
 
 	dev->if_port = 0;
 
@@ -1243,6 +1327,8 @@
 	long ioaddr;
 	u32 intr_status;
 	int boguscnt = max_interrupt_work;
+	struct netdev_private *np = dev->priv;
+	int underflow = np->drv_flags & HasIntTxUnderFlow ? IntrTxUnderflow : 0;
 
 	ioaddr = dev->base_addr;
 	
@@ -1259,7 +1345,7 @@
 			via_rhine_rx(dev);
 
 		if (intr_status & (IntrTxDone | IntrTxAbort | IntrTxUnderrun |
-						   IntrTxAborted))
+						   IntrTxAborted | underflow))
 			via_rhine_tx(dev);
 
 		/* Abnormal error summary/uncommon events handlers. */
@@ -1286,6 +1372,7 @@
 {
 	struct netdev_private *np = dev->priv;
 	int txstatus = 0, entry = np->dirty_tx % TX_RING_SIZE;
+	long ioaddr = dev->base_addr;
 
 	spin_lock (&np->lock);
 
@@ -1307,7 +1394,25 @@
 			if (txstatus & 0x0100) np->stats.tx_aborted_errors++;
 			if (txstatus & 0x0080) np->stats.tx_heartbeat_errors++;
 			if (txstatus & 0x0002) np->stats.tx_fifo_errors++;
+
 			/* Transmitter restarted in 'abnormal' handler. */
+			if (txstatus & 0x0900) {
+				np->stats.tx_aborted_errors++;
+				wmb();
+				np->tx_ring[entry].tx_status = cpu_to_le32(DescOwn);
+				wmb();
+				writel(np->tx_ring_dma + entry * sizeof(struct tx_desc),
+					   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);
+				if (debug > 1) 
+					printk(KERN_ERR "Tx Abort");
+				break;
+			}
 		} else {
 			np->stats.collisions += (txstatus >> 3) & 15;
 			np->stats.tx_bytes += np->tx_skbuff[entry]->len;
@@ -1449,30 +1554,46 @@
 {
 	struct netdev_private *np = dev->priv;
 	long ioaddr = dev->base_addr;
+	int mii       = np->drv_flags & HasIntTxUnderFlow ? 0 : IntrMIIChange;
+	int underflow = np->drv_flags & HasIntTxUnderFlow ? IntrTxUnderflow : 0;
 
 	spin_lock (&np->lock);
 
-	if (intr_status & (IntrMIIChange | IntrLinkChange)) {
+	if (intr_status & (mii | IntrLinkChange)) {
+		int changed;
+		if (debug)
+			printk(KERN_DEBUG "%s: Link change, status=%4.4x\n",
+			   dev->name, intr_status);
 		if (readb(ioaddr + MIIStatus) & 0x02) {
 			/* Link failed, restart autonegotiation. */
 			if (np->drv_flags & HasDavicomPhy)
-				mdio_write(dev, np->phys[0], 0, 0x3300);
+				mdio_write(dev, np->phys[0], MII_BMCR, 0x3300);
+			/* Will the new link status be reported late? */
+			changed = 0;
 		} else
-			via_rhine_check_duplex(dev);
-		if (debug)
+			changed = via_rhine_check_duplex(dev);
+		if (debug && changed)
 			printk(KERN_ERR "%s: MII status changed: Autonegotiation "
 				   "advertising %4.4x  partner %4.4x.\n", dev->name,
-			   mdio_read(dev, np->phys[0], 4),
-			   mdio_read(dev, np->phys[0], 5));
+			   mdio_read(dev, np->phys[0], MII_ADVERTISE),
+			   mdio_read(dev, np->phys[0], MII_LPA));
 	}
 	if (intr_status & IntrStatsMax) {
 		np->stats.rx_crc_errors	+= readw(ioaddr + RxCRCErrs);
 		np->stats.rx_missed_errors	+= readw(ioaddr + RxMissed);
 		clear_tally_counters(ioaddr);
 	}
-	if (intr_status & IntrTxAbort) {
+	if (intr_status & (underflow | IntrTxAbort)) {
 		/* Stats counted in Tx-done handler, just restart Tx. */
 		writew(CmdTxDemand | np->chip_cmd, dev->base_addr + ChipCmd);
+		if (debug > 1) {
+			if (intr_status & underflow)
+				printk(KERN_INFO "%s: Transmitter underflow, status %4.4x.\n",
+					   dev->name, intr_status);
+			if (intr_status & (IntrTxAbort | IntrTxAborted))
+				printk(KERN_INFO "%s: Excessive collisions, status %4.4x.\n",
+					   dev->name, intr_status);
+		}
 	}
 	if (intr_status & IntrTxUnderrun) {
 		if (np->tx_thresh < 0xE0)
@@ -1481,8 +1602,7 @@
 			printk(KERN_INFO "%s: Transmitter underrun, increasing Tx "
 				   "threshold setting to %2.2x.\n", dev->name, np->tx_thresh);
 	}
-	if ((intr_status & ~( IntrLinkChange | IntrStatsMax |
-						  IntrTxAbort | IntrTxAborted))) {
+	if ((intr_status & ~( IntrLinkChange | IntrStatsMax | IntrTxAborted))) {
 		if (debug > 1)
 			printk(KERN_ERR "%s: Something Wicked happened! %4.4x.\n",
 			   dev->name, intr_status);

Re: via-rhine timeouts

[Justin A]

On Tue, 2002-01-29 at 16:06, Urban Widmark wrote:
> On 28 Jan 2002, Justin A wrote:
> 
> > 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.
> 
> This is not a transmit underflow (I was lazy when adding that message,
> this is what the ? is about). It is a transmit abort caused by excessive
> collisions.
> 2000 - transmit abort because of excessive collisions
> 0008 - transmit error
> 
> It is interesting that the linuxfet driver does not fail/recovers. I have
> added some more code from that driver and attached a new version of the
> patch. It re-initializes the ring pointer and tells the card to try to
> transmit the packet again.

I'll send an email to the resnet people seeing if they can login to the
hubs and get some kind of stats to fidn out if there is a general
problem with collisions...

> 
> > Jan 28 20:26:06 bouncybouncy kernel: eth0: reset finished after 10005
> > microseconds.
> 
> The "You have reset me too many times. Go away." error.
> 
> 
> > 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.
> 
> 0003->0007 is that it turns on bus mastering. I have copied the code from
> the linuxfet driver that sets that bit. But for me that is set later by
> the pci_set_master function, and I think the warning is incorrect.
> 
> After reloading the linuxfet driver, does the via-rhine driver work better
> if you switch back to it without rebooting?
> 

Well...I tried...
ifdown eth0;rmmod linuxfet;modprobe via-rhine;ifup eth0 and it worked
fine for a minute. 

Then I went to switch back to linuxfet. somehow both modules got loaded
at the same time, rmmod'd them both and when I did ifup eth0 again it
locked up.

So I'm back to a 0 uptime using linuxfet again...I'll have to repatch
and build via-rhine...

one thing that I have noticed is that it only ever gets the 
"The PCI BIOS has not enabled the device at 0/144!  Updating PCI command 
0003->0007."
after via-rhine stops working and I load linuxfet.

-Justin