From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 15:37:18 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 1420C106567A for ; Fri, 12 Dec 2008 15:37:16 +0000 (UTC) (envelope-from CQG00620@nifty.ne.jp) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id D6D328FC23 for ; Fri, 12 Dec 2008 15:37:15 +0000 (UTC) (envelope-from CQG00620@nifty.ne.jp) Received: from asahi-net.jp (i223090.dynamic.ppp.asahi-net.or.jp [61.125.223.90]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 3E15760FA3; Sat, 13 Dec 2008 00:37:14 +0900 (JST) Date: Sat, 13 Dec 2008 00:37:14 +0900 From: WATANABE Kazuhiro To: freebsd-current In-Reply-To: <7d6fde3d0812111253n4b8f7135n76e9cef63158943e@mail.gmail.com> References: <20081210125627.25732615CD@mail.asahi-net.or.jp> <494019AB.3020505@samsco.org> <20081211130057.B53EE5D0A4@mail.asahi-net.or.jp> <7d6fde3d0812111253n4b8f7135n76e9cef63158943e@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081212153714.3E15760FA3@mail.asahi-net.or.jp> Cc: Garrett Cooper 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: Fri, 12 Dec 2008 15:37:18 -0000 Hi. I've posted a tcpdump output ("tcpdump -i de0 -w scp_local_to_remote.pcap") to the URL below. http://homepage2.nifty.com/dumb_show/unix/work/scp_local_to_remote.pcap In this output I ran "scp /boot/kernel/kernel remote_host:" on the system, and interruped it after 5 minutes (local_host = "scorpio", remote_host = "pisces"). At Thu, 11 Dec 2008 12:53:39 -0800, Garrett Cooper wrote: > 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 --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp)