Hi all,
Is there some known problem in 2.4.20 with the e100 driver? I've been seen
lately a lot of errors in my kernel logs, with the messages:
<31>May 19 09:05:42 kernel: hw tcp v4 csum failed
<31>May 19 09:11:11 kernel: icmp v4 hw csum failure
repeated several times. I've switched back to the eepro100 driver and the
checksum errors messages seems to go away...
Thanks,
--
David G?mez
"The question of whether computers can think is just like the question of
whether submarines can swim." -- Edsger W. Dijkstra
On Mon, May 19, 2003 at 11:12:48PM +0200, David G?mez wrote:
> Is there some known problem in 2.4.20 with the e100 driver? I've been seen
> lately a lot of errors in my kernel logs, with the messages:
>
> <31>May 19 09:05:42 kernel: hw tcp v4 csum failed
> <31>May 19 09:11:11 kernel: icmp v4 hw csum failure
>
> repeated several times. I've switched back to the eepro100 driver and the
> checksum errors messages seems to go away...
I get this, too, on two recently-purchased machines. I suspect that
the new revs of the chips are the cause -- my kernel doesn't seem to
know about many of the device IDs on this board:
hrm@cader:~$ lspci
00:00.0 Host bridge: Intel Corp.: Unknown device 2560 (rev 03)
00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2562 (rev 03)
00:1d.0 USB Controller: Intel Corp.: Unknown device 24c2 (rev 02)
00:1d.1 USB Controller: Intel Corp.: Unknown device 24c4 (rev 02)
00:1d.2 USB Controller: Intel Corp.: Unknown device 24c7 (rev 02)
00:1d.7 USB Controller: Intel Corp.: Unknown device 24cd (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82820 820 (Camino 2) Chipset PCI (rev 82)
00:1f.0 ISA bridge: Intel Corp.: Unknown device 24c0 (rev 02)
00:1f.1 IDE interface: Intel Corp.: Unknown device 24cb (rev 02)
00:1f.3 SMBus: Intel Corp.: Unknown device 24c3 (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp.: Unknown device 24c5 (rev 02)
01:08.0 Ethernet controller: Intel Corp.: Unknown device 1039 (rev 82)
Other than the odd csum failures (average of 1-2 a day on each
box), it all seems to work perfectly.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- ... one ping(1) to rule them all, and in the ---
darkness bind(2) them.
Hi Hugo,
On May 19 at 10:33:18, Hugo Mills wrote:
> > <31>May 19 09:05:42 kernel: hw tcp v4 csum failed
> > <31>May 19 09:11:11 kernel: icmp v4 hw csum failure
>
> I get this, too, on two recently-purchased machines. I suspect that
> the new revs of the chips are the cause -- my kernel doesn't seem to
> know about many of the device IDs on this board:
Not in my case :(, i'm using a not very recent intel ethernet card:
00:0c.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
> Other than the odd csum failures (average of 1-2 a day on each
> box), it all seems to work perfectly.
I was getting a lot more, look:
[huma@fargo] [~] % grep csum /var/log/messages|grep "May 19"| wc -l
443
[huma@fargo] [~] % grep csum /var/log/messages|grep "May 18"| wc -l
486
[huma@fargo] [~] % grep csum /var/log/messages|grep "May 17"| wc -l
425
[huma@fargo] [~] % grep csum /var/log/messages|grep "May 16"| wc -l
953
[huma@fargo] [~] % grep csum /var/log/messages|grep "May 15"| wc -l
1023
[huma@fargo] [~] % grep csum /var/log/messages|grep "May 14"| wc -l
911
I've been a long time without noticing this problem, but looking casually
for another reason at the logs get me to finding these checksum errors hell ;))
--
David G?mez
"The question of whether computers can think is just like the question of
whether submarines can swim." -- Edsger W. Dijkstra
David G?mez [[email protected]] wrote:
> Is there some known problem in 2.4.20 with the e100 driver?
> I've been seen lately a lot of errors in my kernel logs, with
> the messages:
>
> <31>May 19 09:05:42 kernel: hw tcp v4 csum failed
> <31>May 19 09:11:11 kernel: icmp v4 hw csum failure
>
> repeated several times. I've switched back to the eepro100
> driver and the checksum errors messages seems to go away...
David/Hugo, can you try turning off Rx checksum offloading in e100? Set the module parameter XsumRX=0 to turn it off. Thanks.
-scott
Hi Scott,
> > <31>May 19 09:05:42 kernel: hw tcp v4 csum failed
> > <31>May 19 09:11:11 kernel: icmp v4 hw csum failure
>
> David/Hugo, can you try turning off Rx checksum offloading in e100? Set the
> module parameter XsumRX=0 to turn it off.
I reloaded again the e100 module with this parameter. Let's see how it performs.
Thanks for the advice ;)
I'll let you know if checksum errors doesn't show anymore.
--
David G?mez
"The question of whether computers can think is just like the question of
whether submarines can swim." -- Edsger W. Dijkstra
> I reloaded again the e100 module with this parameter. Let's
> see how it performs. Thanks for the advice ;)
>
> I'll let you know if checksum errors doesn't show anymore.
There are several new reports of this problem, so we're trying to repro now...
-scott
Hi Scott,
> > I reloaded again the e100 module with this parameter. Let's
> > see how it performs. Thanks for the advice ;)
> >
> > I'll let you know if checksum errors doesn't show anymore.
>
> There are several new reports of this problem, so we're trying to repro now...
Indeed disabling hardware receive hecksums made the problem go away, it's been
more that a day with no errors in my logs. If you want to know more about my
hardware/software configuration, let me know.
Thanks,
--
David G?mez
"The question of whether computers can think is just like the question of
whether submarines can swim." -- Edsger W. Dijkstra
David G?mez <[email protected]> writes:
> Hi Scott,
>
>> > I reloaded again the e100 module with this parameter. Let's
>> > see how it performs. Thanks for the advice ;)
>> >
>> > I'll let you know if checksum errors doesn't show anymore.
>>
>> There are several new reports of this problem, so we're trying to repro now...
>
> Indeed disabling hardware receive hecksums made the problem go away, it's been
> more that a day with no errors in my logs. If you want to know more about my
> hardware/software configuration, let me know.
I have had some of these too but never paid them any attention
(2.4.21-rc2).
I too tried disabling hardware checksums - now I don't see anything in
the logs...
00:0c.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
Subsystem: Intel Corp. EtherExpress PRO/100+ Management Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: Memory at d5000000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at a000 [size=64]
Region 2: Memory at d4800000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00: 86 80 29 12 17 00 90 02 08 00 00 02 08 20 00 00
10: 00 00 00 d5 01 a0 00 00 00 00 80 d4 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 0c 00
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 08 38
I disabled the PXE function on the boot rom using the DOS intel tool;
otherwise I haven't messed with the firmware.
/Rasmus
--
-- [ Rasmus "M?ffe" B?g Hansen ] ---------------------------------------
Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot.
-- Microsoft help desk
----------------------------------[ moffe at amagerkollegiet dot dk ] --