You should a couple different adapters below, are you saying that
its just one of them, can you try different ones to see if its specific.

Also, would you be able to test my latest driver to see if it still
happens?

Cheers,

Jack


On 10/12/07, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> I am seeing the em driver on 7.0 sending packets with bad UDP (and
> apparently sometimes IP) packet length fields.  This is from UDP NFS
> traffic (90MB/sec over gige).  These packets are dropped on reception by
> the kernel and counted.
>
> Here is a tcpdump trace showing some bad packets:
>
> 17:50:27.912629 IP bad-len 0
> 17:50:27.912748 IP bad-len 0
> 17:50:27.912764 IP bad-len 0
>
> I havent yet caught a better tcpdump of the UDP bad packets but they are
> logged by netstat -s
>
> hydra1# netstat -s -p udp
> udp:
>          120091992 datagrams received
>          0 with incomplete header
>          1775 with bad data length field
>          ^^^^
>          14840 with bad checksum
>          0 with no checksum
>          16 dropped due to no socket
>          258 broadcast/multicast datagrams undelivered
>          0 dropped due to full socket buffers
>          0 not for hashed pcb
>          120075103 delivered
>          120190737 datagrams output
>          0 times multicast source filter matched
>
> Disabling txcsum and rxcsum didnt help.
>
> em0: <Intel(R) PRO/1000 Network Connection Version - 6.5.3> port
> 0x2000-0x201f mem 0xd8a00000-0xd8a1ffff irq 18 at device 0.0 on pci4
> em0: Ethernet address: 00:30:48:33:54:ca
> em0: [FILTER]
>
> [EMAIL PROTECTED]:0:0:   class=0x020000 card=0x000015d9 chip=0x10968086 
> rev=0x01
> hdr=0x00
>      vendor     = 'Intel Corporation'
>      device     = 'PRO/1000 EB Network Connection'
>      class      = network
>      subclass   = ethernet
>
> em0: <Intel(R) PRO/1000 Network Connection Version - 6.5.3> port
> 0x4000-0x401f mem 0xe1000000-0xe101ffff irq 16 at device 0.0 on pci18
> em0: Ethernet address: 00:30:48:8f:55:48
> em0: [FILTER]
>
> [EMAIL PROTECTED]:0:0:  class=0x020000 card=0x108c15d9 chip=0x108c8086 
> rev=0x03
> hdr=0x00
>      vendor     = 'Intel Corporation'
>      device     = 'PRO/1000 PM'
>      class      = network
>      subclass   = ethernet
>
> The second-order effect from this is that our NFS client currently
> misbehaves when UDP packets are dropped, and this leads to data corruption.
>
> Kris
>
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to