Hi all,
yesterday I upgraded a firewall/router of a *busy* customer site
from version 2.4.7 -> 2.4.17. Only 1-2 seconds after the reboot the
network card to the DMZ stopped working. I noticed this messages in
/var/log/messages:
Jan 8 17:07:45 liquice kernel: 8139too: rx stop wait too long
Jan 8 17:07:46 liquice kernel: eth1: Too much work at interrupt, IntrStatus=0x0050.
Jan 8 17:07:46 liquice kernel: eth1: Too much work at interrupt, IntrStatus=0x0010.
Jan 8 17:07:49 liquice kernel: 8139too: rx stop wait too long
Jan 8 17:07:49 liquice kernel: eth1: Too much work at interrupt, IntrStatus=0x0001.
Jan 8 17:07:51 liquice kernel: eth1: Too much work at interrupt, IntrStatus=0x0001.
Jan 8 17:07:57 liquice kernel: eth1: Too much work at interrupt, IntrStatus=0x0050.
Jan 8 17:07:57 liquice kernel: eth1: Setting 100mbps half-duplex based on auto-negotiated partner ability 40a1.
Jan 8 17:08:09 liquice kernel: NETDEV WATCHDOG: eth1: transmit timed out
Jan 8 17:08:09 liquice kernel: eth1: Setting 100mbps half-duplex based on auto-negotiated partner ability ffff.
after a reboot the same problem occured.
Switching back to v2.4.7 solved the problem so I don't think that
it's a hardware issue.
So has anybody an idea whats happening here? Hardware info below. Let me know if you need any additional info.
Thanks
Dennis
liquice:~# lspci
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 40)
00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16)
00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16)
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 (rev 10)
00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 (rev 10)
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 (rev 10)
00:11.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage XL AGP (rev 65)
liquice:~# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 4
model name : AMD Athlon(tm) Processor
stepping : 2
cpu MHz : 1210.814
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips : 2411.72
any reason why you posted that to me and not to the list?
On Wed, Jan 09, 2002 at 06:02:10PM -0500, Mark Hahn wrote:
> > yesterday I upgraded a firewall/router of a *busy* customer site
> ...
> > Jan 8 17:07:45 liquice kernel: 8139too: rx stop wait too long
>
> surely a "*busy*" can pay an extra $20 and get a real network card...
sure, but as I said: with kernel v2.4.7 it works! So I guess it must
be a bug in something later than version 2.4.7.
> > Jan 8 17:07:46 liquice kernel: eth1: Too much work at interrupt, IntrStatus=0x0050.
>
> did you happen to enable the use of local apic (in the new kernel's config)?
nope. I'll try that.
Dennis
Wed, Jan 09, 2002 at 10:08:55AM +0100, Dennis Schoen wrote:
> yesterday I upgraded a firewall/router of a *busy* customer site
> from version 2.4.7 -> 2.4.17. Only 1-2 seconds after the reboot the
> network card to the DMZ stopped working. I noticed this messages in
> /var/log/messages:
>
> Jan 8 17:07:45 liquice kernel: 8139too: rx stop wait too long
> Jan 8 17:07:46 liquice kernel: eth1: Too much work at interrupt, IntrStatus=0x0050.
> Jan 8 17:07:46 liquice kernel: eth1: Too much work at interrupt, IntrStatus=0x0010.
> Jan 8 17:07:49 liquice kernel: 8139too: rx stop wait too long
> Jan 8 17:07:49 liquice kernel: eth1: Too much work at interrupt, IntrStatus=0x0001.
> Jan 8 17:07:51 liquice kernel: eth1: Too much work at interrupt, IntrStatus=0x0001.
> Jan 8 17:07:57 liquice kernel: eth1: Too much work at interrupt, IntrStatus=0x0050.
> Jan 8 17:07:57 liquice kernel: eth1: Setting 100mbps half-duplex based on auto-negotiated partner ability 40a1.
> Jan 8 17:08:09 liquice kernel: NETDEV WATCHDOG: eth1: transmit timed out
> Jan 8 17:08:09 liquice kernel: eth1: Setting 100mbps half-duplex based on auto-negotiated partner ability ffff.
>
> after a reboot the same problem occured.
>
> Switching back to v2.4.7 solved the problem so I don't think that
> it's a hardware issue.
Hi dennis, I'm getting these messages too with an identical card...
8139 (rev 10)... seems to have started happening after I went to
2.4.17... strangely enough I'm getting very similar m?ssages on the
machine right beside it.. running 2.4.13, SMP, and a 3com 3c905b
(Boomerang).
Anyone have any insight on this one?
--
Patrick Cole - Debian Developer <[email protected]>
- John Curtin, ANU <[email protected]>
- Linear-G Network Solutions <[email protected]>
- PGP 1024R/60D74C7D C8E0BC7969BE7899AA0FEB16F84BFE5A
Patrick Cole <[email protected]> writes:
> Hi dennis, I'm getting these messages too with an identical card...
> 8139 (rev 10)... seems to have started happening after I went to
> 2.4.17... strangely enough I'm getting very similar m?ssages on the
> machine right beside it.. running 2.4.13, SMP, and a 3com 3c905b
> (Boomerang).
The problem with the 8139 is the fact that the chip design is really
dumb, when I say dumb here, I mean *really* dumb ;-(
The result is that when the card is bombarded with a lot of small
packets it can livelock because the queues fill up faster than the
kernel code can empty and process them.
I made some changes to improve the situation in the driver, for 2.2
kernels, which I have submitted to Jeff and he plans to integrated
them into the next release.
My patched drivers are available from
http://www.wildopensource.com/proj/download/SG_drivers.html however I
haven't tested them on 2.4.x, so I am not going to bet on them
working.
Cheers,
Jes