dtrace discuss - Aug 2007 - udp checksum error with ipcl_tcpconn_cache

Dear All,
recently our customer met some udp checksum error in v40z, we have
done below testing:

Sending: v40z, solaris 10 update 2 with 125121-03 patch
receiving: v40z with solaris 10 update 2 and a PC-server with windows
2 receiving host connect in the same network switch.
in sending v40z, we set ip:dohwcksum=0 in /etc/system.

The sending peer send out packets at about 40M/s, the windows machines
don''t
report checksum error, but v40z report checksum error, using dtrace we found
following stack during checksum error:

dtrace: description ''udpInCksumErrs '' matched 2 probes
CPU ID FUNCTION:NAME
2 842 ipcl_tcpconn_cache:udpInCksumErrs
ip`ip_input+0x729
dls`i_dls_link_ether_rx+0x153
mac`mac_rx+0x46
e1000g`e1000g_intr_work+0x1a8
e1000g`e1000g_intr+0x3c
unix`av_dispatch_autovect+0x78
unix`intr_thread+0x50


2 842 ipcl_tcpconn_cache:udpInCksumErrs
ip`ip_input+0x729
dls`i_dls_link_ether_rx+0x153
mac`mac_rx+0x46
e1000g`e1000g_intr_work+0x1a8
e1000g`e1000g_intr+0x3c
unix`av_dispatch_autovect+0x78
unix`intr_thread+0x50


and netstat -s also report udpInChecksumErr, What make me confused is why
ipcl_tcpconn_cache is appeared in the stack, does it have any
relationship with
udpInCksumErr, I using mdb to walk through ipcl_tcpconn_cache, it''s all
tcp conn_t data. Can anyone help to explain the stack?

Thanks!

Lily

[Removed the @sun.com cc entry.  Please don''t copy both internal and
external lists on the same message.]

lily zhao writes:
> dtrace: description ''udpInCksumErrs '' matched 2 probes
> CPU ID FUNCTION:NAME
> 2 842 ipcl_tcpconn_cache:udpInCksumErrs
[...]
> and netstat -s also report udpInChecksumErr, What make me confused is why
> ipcl_tcpconn_cache is appeared in the stack, does it have any
That _should_ be the name of a function.  ipcl_tcpconn_cache isn''t the
name of a function at all, so I can only conclude that the kernel
symbol table on this system is broken.

I don''t think this is a problem in TCP/IP, but rather something in CTF
or (if this is S10) the way patches are generated.

(The checksum error still needs to be narrowed down.  At a guess, I
think you''re probably looking at the wrong issue here, and should be
verifying whether the checksums are correct on the wire itself.)

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677