From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 20:53:40 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 852B61065670 for ; Thu, 11 Dec 2008 20:53:40 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 5619C8FC1D for ; Thu, 11 Dec 2008 20:53:40 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1030967rvf.43 for ; Thu, 11 Dec 2008 12:53:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SNIIPK6UJ742j1HUQ/JOhiSz5GLHD4kcnEeNIAokItU=; b=GyTCP9whXFOjgIePoJFORqUVPzr4AJRL2l6A4gK1c5nQmEiwB2m2rGCBFC3bxr5LJV YnIOLW95DdC5gugOFahMKJfaA9OdwWI6YpWix6Lt1Ud9JHJyj2HVLN1i7WTU4jmT8BrH KfV26WpG+Y0UNdrjtjYmH8PyYi3wraxsb2M7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=DEOxDc+FVmDwzWW93Pku8k/jUZjYA3HxMDZ3leHGXkych/mAXXwD2h7scoBYKgre/V TJyTmiVNPqh1iZ75730A7qz+PvtZ4t/zFRxi/zVZUX3u3nRs2nkxztGFdbU8CghVzoq2 zYJ2dojJ001H6bXdHUtj07N0f4ZiA4j3wrh2E= Received: by 10.141.84.17 with SMTP id m17mr1478577rvl.64.1229028820006; Thu, 11 Dec 2008 12:53:40 -0800 (PST) Received: by 10.140.158.13 with HTTP; Thu, 11 Dec 2008 12:53:39 -0800 (PST) Message-ID: <7d6fde3d0812111253n4b8f7135n76e9cef63158943e@mail.gmail.com> Date: Thu, 11 Dec 2008 12:53:39 -0800 From: "Garrett Cooper" To: "WATANABE Kazuhiro" In-Reply-To: <20081211130057.B53EE5D0A4@mail.asahi-net.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081210125627.25732615CD@mail.asahi-net.or.jp> <494019AB.3020505@samsco.org> <20081211130057.B53EE5D0A4@mail.asahi-net.or.jp> Cc: freebsd-current Subject: Re: [patch] de(4) has not worked on 8-current since Feb 13 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: Thu, 11 Dec 2008 20:53:40 -0000 On Thu, Dec 11, 2008 at 5:00 AM, WATANABE Kazuhiro wrote: > CC'ed to freebsd-current. > > At Wed, 10 Dec 2008 12:34:03 -0700, > Scott Long wrote: >> WATANABE Kazuhiro wrote: >> > Hi, all. >> > >> > My de(4) NICs has not worked on 8-current since Feb 13. >> > >> > >> >> Can you define "not worked" a little better? Does it give errors, or >> corrupt data, or appear to not transmit and/or receive? >> >> Scott > > Thanks for your reply. I should have written more details about the > problem... > > On recent 8-current, my de(4) NICs cannot send any (almost all) data > from it. > > * The system boots normally. > > * Probing/attaching the de(4) NICs are done successfully. > > * The system can receive data from the other hosts. For example the > following command was finished normally in 14 seconds: > > $ /usr/bin/time scp other_host:/boot/kernel/kernel . > Password: > kernel 100% 4717KB 471.7KB/s 00:10 > 14.03 real 0.53 user 0.40 sys > $ > > * The system cannot send any data to the other hosts. For example > the following command was "stalled" and never finished > (I interrupted the command after 5 minutes). None of the data were > sent: > > $ /usr/bin/time scp /boot/kernel/kernel other_host: > Password: > kernel 1% 192KB 0.0KB/s - stalled -^CKilled by signal 2. > 336.01 real 0.05 user 0.17 sys > $ > > * The system doesn't show any error/warning messages. > > * I can "slogin" from the other hosts to the system, and some small > amount of text output (ex. an output of "dmesg") are done > successfully. But a bit large amount of text output are stopped > after a few seconds. For example: > > $ ls -l /boot/kernel/kernel > -r-xr-xr-x 1 root wheel 10975839 Dec 11 13:46 /boot/kernel/kernel > $ hd /boot/kernel/kernel | head > 00000000 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 |.ELF............| > 00000010 02 00 03 00 01 00 00 00 e0 c5 46 c0 34 00 00 00 |..........F.4...| > 00000020 58 22 92 00 00 00 00 00 34 00 20 00 05 00 28 00 |X"......4. ...(.| > 00000030 23 00 20 00 06 00 00 00 34 00 00 00 34 00 40 c0 |#. .....4...4.@.| > 00000040 34 00 40 c0 a0 00 00 00 a0 00 00 00 05 00 00 00 |4.@.............| > 00000050 04 00 00 00 03 00 00 00 d4 00 00 00 d4 00 40 c0 |..............@.| > 00000060 d4 00 40 c0 0d 00 00 00 0d 00 00 00 04 00 00 00 |..@.............| > 00000070 01 00 00 00 01 00 00 00 00 00 00 00 00 00 40 c0 |..............@.| > 00000080 00 00 40 c0 a0 ca 81 00 a0 ca 81 00 05 00 00 00 |..@.............| > 00000090 00 10 00 00 01 00 00 00 a0 ca 81 00 a0 da c1 c0 |................| > $ hd /boot/kernel/kernel > 00000000 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 |.ELF............| > 00000010 02 00 03 00 01 00 00 00 e0 c5 46 c0 34 00 00 00 |..........F.4...| > 00000020 58 22 92 00 00 00 00 00 34 00 20 00 05 00 28 00 |X"......4. ...(.| > 00000030 23 00 20 00 06 00 00 00 34 00 00 00 34 00 40 c0 |#. .....4...4.@.| > 00000040 34 00 40 c0 a0 00 00 00 a0 00 00 00 05 00 00 00 |4.@.............| > (snip) > 00005d90 0a 20 00 00 0b 00 00 00 00 00 00 00 70 15 00 00 |. ..........p...| > 00005da0 ce 2a 00 00 36 23 00 00 c6 2a 00 00 0b 14 00 00 |.*..6#...*......| > 00005db0 7c 03 00 00 b1 27 00 00 d9 1e 00 00 2e 15 00 00 ||....'..........| > 00005dc0 00 00 00 00 6d 22 00 00 04 2a 00 00 72 23 00 00 |....m"...*..r#..| > 00005dd0 00 00 00 00 00 00 00 00 d3 1f 00 00 00 00 00 00 |................| > (Stopped here. 0x5de0 == 24032 bytes) Hmm... definitely a TXO issue. msk(4) had similar problems with my chipset using an MTU of 1492 and checksumming until I provided Pyun some data which helped him improve the driver code for the chipset. Probably not the case here, but are there any tcpdump sessions with raw frames that we could get to help traceback the cause? Thanks, -Garrett