RE: e100 driver

RE: e100 driver

[Feldman, 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...

-scott

Re: e100 driver

[David Gómez]

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

Re: e100 driver

[Rasmus Bøg Hansen]

David Gómez <david@pleyades.net> 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 ] --

RE: e100 driver

[Feldman, Scott]

David Gómez [david@pleyades.net] 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

Re: e100 driver

[David Gómez]

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

e100 driver

[David Gómez]

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

Re: e100 driver

[Hugo Mills]

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

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.                          

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

Re: e100 driver

[David Gómez]

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