Thread (1 message) 1 message, 1 author, 2004-12-16

Re: [Bug 3904] New: CHECKSUM_HW gets set even w/o hardware support.

From: Stephen Hemminger <hidden>
Date: 2004-12-16 19:08:17

On Tue, 14 Dec 2004 22:42:40 -0800
bugme-daemon@osdl.org wrote:
http://bugme.osdl.org/show_bug.cgi?id=3904

           Summary: CHECKSUM_HW gets set even w/o hardware support.
    Kernel Version: 2.6.9
            Status: NEW
          Severity: normal
             Owner: shemminger@osdl.org
         Submitter: tcc_linux@thinkthink.com


Distribution:
   Debian w/ kernel from kernel.org
Hardware Environment:
   Fujitsu LifeBook N5010
Software Environment:
   Debian unstable distro
Problem Description:
   CHECKSUM_HW is improperly set in udp.c resulting in udp frames being sent
with bad checksums. The hardware and therefore the driver (8139cp) is not
setting CHECKSUM_HW (I checked). Possibly a problem with any NIC that doesn't do
hardware checksumming. #if 0'ing out the hw checksum code in
udp.c:udp_push_pending_frames() works as a workaround (but obviously does not
identify who set CHECKSUM_HW).
Steps to reproduce:
   Need board that uses 8139cp driver. Write a small program that sends udp
data. Observe with tcpdump.  Sendto, send, and write all behave the same.
Tcpdump also has a problem displaying what the checksum should be, but does
properly flag the bad checksum.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
I believe the problem is that the 8139cp driver allows enabling TX csum,
via ethtool but does not support it.  What does ethtool report as being
enabled on that ethernet. I doubt it is a udp problem.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help