2.6.3 RT8139too NIC problems

2.6.3 RT8139too NIC problems

[Nick Warne]

Hello all,

Due to traffic restraints, I am not on the lkml - please CC replies.

Yesterday I built 2.6.3.  Clean build, and system runs nice.

I have two NIC's in the box, both rt8139.

But I noticed I am getting this in syslogs:

Linux233 kernel: NETDEV WATCHDOG: eth1: transmit timed out
Linux233 kernel: eth1: link up, 10Mbps, half-duplex, lpa 0x0000
Linux233 kernel: nfs: server 486Linux not responding, still trying
Linux233 kernel: nfs: server 486Linux not responding, still trying
Linux233 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Linux233 kernel: nfs: server 486Linux OK
Linux233 kernel: nfs: server 486Linux OK
Linux233 kernel: nfs: server 486Linux not responding, still trying
Linux233 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Linux233 kernel: nfs: server 486Linux OK

This happens about once every 3 hours.

>From my config file:

# CONFIG_8139CP is not set
CONFIG_8139TOO=y
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_8139_RXBUF_IDX= is not set

No other NIC drivers are used.

I am also stuck as to what the new RXBUF_IDX is for.  It appears the 
new build needs it, as I cannot remove.

These cards have worked fine under all 2.4.x and 2.6.1/2.6.2 kernels.

Ideas?

TIA,

Nick

-- 
"I am not Spock", said Leonard Nimoy.
"And it is highly illogical of humans to assume so."

Re: 2.6.3 RT8139too NIC problems

[Paul Mundt]

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

On Thu, Feb 19, 2004 at 04:47:08PM -0000, Nick Warne wrote:
> >From my config file:
> 
> # CONFIG_8139CP is not set
> CONFIG_8139TOO=y
> # CONFIG_8139TOO_PIO is not set
> # CONFIG_8139TOO_TUNE_TWISTER is not set
> # CONFIG_8139TOO_8129 is not set
> # CONFIG_8139_OLD_RX_RESET is not set
> # CONFIG_8139_RXBUF_IDX= is not set
> 
> No other NIC drivers are used.
> 
> I am also stuck as to what the new RXBUF_IDX is for.  It appears the 
> new build needs it, as I cannot remove.
> 
So read the help entry in Kconfig. Before this change went in, pretty much
everyone defaulted to a 32k receive ring size, which is also the current
default. If you had used the default value of 2 instead of trying to hack
around it, you might get better behavior from your driver..


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.3 RT8139too NIC problems

[Nick Warne]

> On Thu, Feb 19, 2004 at 04:47:08PM -0000, Nick Warne wrote:
> > >From my config file:
> > 
> > # CONFIG_8139CP is not set
> > CONFIG_8139TOO=y
> > # CONFIG_8139TOO_PIO is not set
> > # CONFIG_8139TOO_TUNE_TWISTER is not set
> > # CONFIG_8139TOO_8129 is not set
> > # CONFIG_8139_OLD_RX_RESET is not set
> > # CONFIG_8139_RXBUF_IDX= is not set
> > 
> > No other NIC drivers are used.
> > 
> > I am also stuck as to what the new RXBUF_IDX is for.  It appears the 
> > new build needs it, as I cannot remove.
> > 
> So read the help entry in Kconfig. Before this change went in, pretty much
> everyone defaulted to a 32k receive ring size, which is also the current
> default. If you had used the default value of 2 instead of trying to hack
> around it, you might get better behavior from your driver..

Hi Paul,

My bad...

I did use the default 2... unfortunately that snippet I copied here 
was what I tried to do to rebuild kernel with out it, but make just 
adds the line back in CONFIG and asks what option I what.

So it is set to 2 as per the default.

So, corrected (and as the kernel was built):

# CONFIG_8139CP is not set
CONFIG_8139TOO=y
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_8139_RXBUF_IDX=2

Nick

-- 
"I am not Spock", said Leonard Nimoy.
"And it is highly illogical of humans to assume so."

Re: 2.6.3 RT8139too NIC problems

[Nick Warne]

> So, corrected (and as the kernel was built):
> 
> # CONFIG_8139CP is not set
> CONFIG_8139TOO=y
> # CONFIG_8139TOO_PIO is not set
> # CONFIG_8139TOO_TUNE_TWISTER is not set
> # CONFIG_8139TOO_8129 is not set
> # CONFIG_8139_OLD_RX_RESET is not set
> CONFIG_8139_RXBUF_IDX=2

OK, I think there _is_ a problem here.  I was suspecting my NFS setup 
maybe causing the NIC (eth0) to timeout and get reset, as I mount 
files from an old 486 -> 2.6.3 box.

But after messing about a bit, I checked the logs on my 2.4.24 box 
via SSH (AND eth1).  It hung as issued #> pico /var/log/messages  for 
about 3 seconds.. then came to life.  So...

... in the logs on 2.6.3 box straight after:

Feb 19 19:33:13 Linux233 kernel: NETDEV WATCHDOG: eth1: transmit 
timed out
Feb 19 19:33:13 Linux233 kernel: eth1: link up, 10Mbps, half-duplex, 
lpa 0x0000

Nick

-- 
"I am not Spock", said Leonard Nimoy.
"And it is highly illogical of humans to assume so."

Re: 2.6.3 RT8139too NIC problems

[Jeff Garzik]

Nick Warne wrote:
> Hello all,
> 
> Due to traffic restraints, I am not on the lkml - please CC replies.
> 
> Yesterday I built 2.6.3.  Clean build, and system runs nice.
> 
> I have two NIC's in the box, both rt8139.
> 
> But I noticed I am getting this in syslogs:
> 
> Linux233 kernel: NETDEV WATCHDOG: eth1: transmit timed out
> Linux233 kernel: eth1: link up, 10Mbps, half-duplex, lpa 0x0000
> Linux233 kernel: nfs: server 486Linux not responding, still trying
> Linux233 kernel: nfs: server 486Linux not responding, still trying
> Linux233 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Linux233 kernel: nfs: server 486Linux OK
> Linux233 kernel: nfs: server 486Linux OK
> Linux233 kernel: nfs: server 486Linux not responding, still trying
> Linux233 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Linux233 kernel: nfs: server 486Linux OK


This is usually irq routing related...  Try booting with 'noapic' or 
similar.

	Jeff

Re: 2.6.3 RT8139too NIC problems

[Nick Warne]

> > Linux233 kernel: NETDEV WATCHDOG: eth1: transmit timed out
> > Linux233 kernel: eth1: link up, 10Mbps, half-duplex, lpa 0x0000
> > Linux233 kernel: nfs: server 486Linux not responding, still trying
> > Linux233 kernel: nfs: server 486Linux not responding, still trying
> > Linux233 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> > Linux233 kernel: nfs: server 486Linux OK
> > Linux233 kernel: nfs: server 486Linux OK
> > Linux233 kernel: nfs: server 486Linux not responding, still trying
> > Linux233 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> > Linux233 kernel: nfs: server 486Linux OK
> 
> 
> This is usually irq routing related...  Try booting with 'noapic' or 
> similar.

I don't have apic built in the kernel.  This has only started to 
happen on 2.6.3.  As I said, on all other kernels, 2.4.x, 2.6.0, 
2.6.1, 2.6.2 these NIC are OK.

With 2.6.3 my logs are now riddled with these messages (and the 
period is totally random - sometimes 10 times in an hour), and I lose 
connectivity during these periods.

I will be booting back into 2.6.2 tonight until I can resolve this.

Nick

-- 
"I am not Spock", said Leonard Nimoy.
"And it is highly illogical of humans to assume so."

Re: 2.6.3 RT8139too NIC problems

[Nick Warne]

> > > Linux233 kernel: NETDEV WATCHDOG: eth1: transmit timed out
> > > Linux233 kernel: eth1: link up, 10Mbps, half-duplex, lpa 0x0000
> > > Linux233 kernel: nfs: server 486Linux not responding, still trying
> > > Linux233 kernel: nfs: server 486Linux not responding, still trying
> > > Linux233 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> > > Linux233 kernel: nfs: server 486Linux OK
> > > Linux233 kernel: nfs: server 486Linux OK
> > > Linux233 kernel: nfs: server 486Linux not responding, still trying
> > > Linux233 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> > > Linux233 kernel: nfs: server 486Linux OK

Well, I am at a loss now or any idea what to do next.  I have tried 
everything this morning to build this an eliminate the problem.  
Whatever I do, kernel builds nice, boots nice and no problems... 
except for these NIC timeouts - it makes 2.6.3 totally unusable for 
me.

I state again, these _very_same_ cards work perfectly under any other 
kernel I have ever used over the last 3 years (like I am back on 
2.6.2 right now).

Nick

-- 
"I am not Spock", said Leonard Nimoy.
"And it is highly illogical of humans to assume so."

Re: 2.6.3 RT8139too NIC problems

[Nick Warne]

 > Ok, the normal step from here is a binary search for the offending patch. 
> You know it works on 2.6.2 and not on 2.6.3.  There should be daily BK 
> snapshots for the period from 2.6.2 to 2.6.3.  See if it broke in the first 
> half/second half and so on.  If you can find the offending patch or day 
> then I am sure someone can find the issue.
>

Hi Andy,

Thanks for reply.

Funnily enough, I looked at this at work today and decided to check 
against 8139too.c from 2.6.2 and 2.6.3 trees.  There was a lot of 
changes, but it appeared only to that file (i.e. nothing referencing 
it) - so I have just built 2.6.3 with the 8139too.c source from 2.6.2 
just to make sure it isn't code elsewhere (i.e. pci stuff?) that is 
causing it.

So far it is running perfectly.  I will wait a while to test, and if 
it doesn't show any problems, we can presume it is the changes that 
caused this problem for me on my system.

Enquiries to the HantsLUG seem to be that no-one else gets this 
problem.

Nick
-- 
"I am not Spock", said Leonard Nimoy.
"And it is highly illogical of humans to assume so."

Re: 2.6.3 RT8139too NIC problems

[Nick Warne]

 > Funnily enough, I looked at this at work today and decided to check 
> against 8139too.c from 2.6.2 and 2.6.3 trees.  There was a lot of 
> changes, but it appeared only to that file (i.e. nothing referencing 
> it) - so I have just built 2.6.3 with the 8139too.c source from 2.6.2 
> just to make sure it isn't code elsewhere (i.e. pci stuff?) that is 
> causing it.
> 
> So far it is running perfectly.  I will wait a while to test, and if 
> it doesn't show any problems, we can presume it is the changes that 
> caused this problem for me on my system.
> 
> Enquiries to the HantsLUG seem to be that no-one else gets this 
> problem.

This has solved the problem for me.  Please can anyone tell me what 
details are required to provide a bug report on this strange one off 
issue, as I wouldn't know where to start.

To recap:

rtl8139too cards worked on all kernels up until 2.6.3 (like 3 years).

The timeout issues started with 2.6.3 (using make oldconfig)... new 
settings applied.

Tried lilo 'append="noapic"  -> problem still persisted.

After reading I changed: 2.6.2 source-> 8139too.c to replace new 
2.6.3 source-> 8139too.c -> rebuilt with same .config.  No timeouts - 
all hunky dory.

Thanks,

Nick

[root@Linux233 log]# lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT82C585VP [Apollo 
VP1/VPX] (rev 23)
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA 
[Apollo VP] (rev 27)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 02)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 
(rev 10)
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 
(rev 10)


-- 
"When you're chewing on life's gristle,
Don't grumble,
Give a whistle
And this'll help things turn out for the best."