From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 17:51:33 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A13251065670 for ; Sun, 7 Oct 2012 17:51:33 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5DAFB8FC08 for ; Sun, 7 Oct 2012 17:51:33 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so4206687oag.13 for ; Sun, 07 Oct 2012 10:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4NnUfXivX6LfahrXx52fh66p2eXwXvobzzXCyNrN9g8=; b=CbO+JJy0woyl48AXBAinFSZBFkv01wFdj1m07AiwnLVBU4PBcAVgIckuupuEPG5zKX n5TTnqb2wjCYrrYAEGqZ5+/EhSgvqFulr5DBg5XrCxmDTgMCJBunp1No6Huc/e2TCbxS mT1SnnbAWYJ+LGIRBxg5QbC65WHT8IzGXfkVe+0qVPV6iF+xmJiPnVTnwYt0TEusqVOF n4/40yIQrrAfZ8TM7rwiLOm6RRntjsRUleKudzOfaR55aoxz/dVJ02yp+hS4zxymuYuN gSvxoTTU6M1wHJTyHfWXVoTAmHdT7SuwuJXEU3DW08vqtyT1AH9nmSTSbZR9GVBAotG8 ap7w== MIME-Version: 1.0 Received: by 10.182.144.70 with SMTP id sk6mr5941042obb.67.1349632292853; Sun, 07 Oct 2012 10:51:32 -0700 (PDT) Received: by 10.76.167.202 with HTTP; Sun, 7 Oct 2012 10:51:32 -0700 (PDT) In-Reply-To: <20121007174331.GA2583@albert.catwhisker.org> References: <20121007151128.GL23688@albert.catwhisker.org> <5071AAF6.9020009@protected-networks.net> <20121007174331.GA2583@albert.catwhisker.org> Date: Sun, 7 Oct 2012 10:51:32 -0700 Message-ID: From: Garrett Cooper To: David Wolfskill Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: Message "in_cksum_skip: out of data by ...." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 17:51:33 -0000 On Sun, Oct 7, 2012 at 10:43 AM, David Wolfskill wrote: > On Sun, Oct 07, 2012 at 10:03:04AM -0700, Garrett Cooper wrote: >> ... >> 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: >> ... >> ------------------------------------------------------------------------ >> 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. >> ... > >> Did you rebuild all of your modules, and (for David) are you >> running any firmware blobs with your wireless NIC? > > Yes; when I update, my changes from the process in src/UPDATING > generally augment what's there (e.g., to clear /usr/include & > /usr/share/man before the make installworld). > > And the NIC that's in use (at home -- and most other places) on the > laptop is iwn(4), so yes, there is a firmware blob: > > 4 1 0xc138a000 54e38 iwn5000fw.ko > > (Well, that particular line is from kldstat when it's running stable/9; > I just checked the head slice, and the blob had been rebuilt (based on > mtime), and has contents different from the contents in stable/9: > > g1-227(9.1-P)[3] md5 /{,S4/}boot/kernel/iwn5000fw.ko > MD5 (/boot/kernel/iwn5000fw.ko) = 8f98e8f28c70fe801c73aec4f717973f > MD5 (/S4/boot/kernel/iwn5000fw.ko) = a0150e03bfd307595ab37b0924252844 > g1-227(9.1-P)[4] ls -lT !$ > ls -lT /{,S4/}boot/kernel/iwn5000fw.ko > -r-xr-xr-x 1 root wheel 345868 Oct 7 07:48:46 2012 /S4/boot/kernel/iwn5000fw.ko > -r-xr-xr-x 1 root wheel 344416 Oct 7 04:51:11 2012 /boot/kernel/iwn5000fw.ko > g1-227(9.1-P)[5] > > FWIW.) > > As noted, the message does not appear to be associated with (other) > unwanted behavior, so I wouldn't consider this of earth-shattering > importance. It just seemed rather odd, and I got to wondering if > the developer who committed the change had intended this result. > And if said result was actually of use to anyone. :-} Given that the issue is present on both your machine and Michael's, it's unlikely that it's firmware related (unless re(4) is doing something hacktacularly awesome!), but I just wanted to gather all the facts before something's brought up to glebius@, if the issue is indeed one of the two commits (or both) mentioned above. Could you guys please try reverting one or both of the commits to see if the issue goes away? Thanks! -Garrett