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
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
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
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 |\ _,,,---,,_
[email protected] 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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 |\ _,,,---,,_
> [email protected] 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 [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
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
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: [email protected]
[mailto:[email protected]]Im Auftrag von Justin A
Gesendet: Mittwoch, 23. Januar 2002 00:42
An: [email protected]
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
On Wed, 23 Jan 2002 10:44:17 +0100 (CET)
Urban Widmark <[email protected]> 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
----- Original Message -----
From: "Justin A" <[email protected]>
To: "Andy Carlson" <[email protected]>
Cc: <[email protected]>
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 <[email protected]>
| 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
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
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(). */
-
> 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(). */
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(). */
>
> -
>
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
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
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 |\ _,,,---,,_
[email protected] 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(). */
>
> -
>
----- Original Message -----
From: "Justin A" <[email protected]>
To: "Andrew Morton" <[email protected]>
Cc: "Urban Widmark" <[email protected]>; "Martin Eriksson"
<[email protected]>; "Andy Carlson" <[email protected]>;
<[email protected]>; "Stephan von Krawczynski" <[email protected]>
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 <[email protected]>
| 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
I tried this patch, and it made not change, unless it was maybe a little
worse :).
Andy Carlson |\ _,,,---,,_
[email protected] 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" <[email protected]>
> To: "Andrew Morton" <[email protected]>
> Cc: "Urban Widmark" <[email protected]>; "Martin Eriksson"
> <[email protected]>; "Andy Carlson" <[email protected]>;
> <[email protected]>; "Stephan von Krawczynski" <[email protected]>
> 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 <[email protected]>
> | 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
>
----- Original Message -----
From: "Andy Carlson" <[email protected]>
To: "Martin Eriksson" <[email protected]>
Cc: "Justin A" <[email protected]>; "Andrew Morton" <[email protected]>;
"Urban Widmark" <[email protected]>; <[email protected]>;
"Stephan von Krawczynski" <[email protected]>
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 <[email protected]>
| 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
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
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
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