Re: Message "in_cksum_skip: out of data by ...."

On Sun, Oct 7, 2012 at 9:16 AM, Michael Butler
<imb_at_protected-networks.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/07/12 11:11, David Wolfskill wrote:
>> I started seeing these messages spewed (to both console &
>> /var/log/messages) following an update from:
>>
>> FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #697 241222M: Fri Oct  5 05:32:19 PDT 2012     root_at_g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY  i386
>>
>> to
>>
>> FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #698 241245M: Sat Oct  6 08:01:23 PDT 2012     root_at_g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY  i386
>>
>> and I'm still seeing them as of
>>
>> FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #699 241309M: Sun Oct  7 07:35:41 PDT 2012     root_at_g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY  i386
>>
>> E.g.:
>> Oct  6 08:24:10 g1-227 kernel: wlan0: Ethernet address: 00:21:6a:26:34:c0
>> Oct  6 08:24:10 g1-227 kernel: Expensive timeout(9) function: 0xc0c27520(0) 0.010540166 s
>> Oct  6 08:24:10 g1-227 kernel: in_cksum_skip: out of data by 10200
>
> +1 on a laptop running with:
>
> re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet> port
> 0x2000-0x20ff mem 0xf0700000-0xf0700fff,0xf0200000-0xf0203fff irq 17 at
> device 0.0 on pci3
> re0: Using 1 MSI-X message
> re0: ASPM disabled
> re0: Chip rev. 0x28000000
> re0: MAC rev. 0x00000000
> miibus0: <MII bus> on re0
> rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
> rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
> 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master,
> 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow,
> 1000baseT-FDX-flow-master, auto, auto-flow
> re0: Ethernet address: 00:0a:cd:1d:30:a2
>
> I thought it may have had something to do with a VirtualBox module, so I
> recompiled that too .. no joy :-(

    Maybe these revisions had something to do with it... (r241245 is
more likely)?

------------------------------------------------------------------------
r241245 | glebius | 2012-10-06 03:02:11 -0700 (Sat, 06 Oct 2012) | 19 lines

  A step in resolving mess with byte ordering for AF_INET. After this change:

  - All packets in NETISR_IP queue are in net byte order.
  - ip_input() is entered in net byte order and converts packet
    to host byte order right _after_ processing pfil(9) hooks.
  - ip_output() is entered in host byte order and converts packet
    to net byte order right _before_ processing pfil(9) hooks.
  - ip_fragment() accepts and emits packet in net byte order.
  - ip_forward(), ip_mloopback() use host byte order (untouched actually).
  - ip_fastforward() no longer modifies packet at all (except ip_ttl).
  - Swapping of byte order there and back removed from the following modules:
    pf(4), ipfw(4), enc(4), if_bridge(4).
  - Swapping of byte order added to ipfilter(4), based on __FreeBSD_version
  - __FreeBSD_version bumped.
  - pfil(9) manual page updated.

Reviewed by:    ray, luigi, eri, melifaro
Tested by:      glebius (LE), ray (BE)

------------------------------------------------------------------------
r241244 | glebius | 2012-10-06 00:06:57 -0700 (Sat, 06 Oct 2012) | 5 lines

  The pfil(9) layer guarantees us presence of the protocol header,
so remove extra check, that is always false.

P.S. Also, goto there lead to unlocking a not locked rwlock.

------------------------------------------------------------------------

    Did you rebuild all of your modules, and (for David) are you
running any firmware blobs with your wireless NIC?
Cheers,
-Garrett