From owner-freebsd-current@FreeBSD.ORG Sat Jun 28 16:54:52 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 00AA1106567A for ; Sat, 28 Jun 2008 16:54:52 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id B09F28FC12 for ; Sat, 28 Jun 2008 16:54:51 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:a188:959c:f273:4400] (unknown [IPv6:2001:7b8:3a7:0:a188:959c:f273:4400]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A8EA43C; Sat, 28 Jun 2008 18:54:49 +0200 (CEST) Message-ID: <48666CD7.9020706@andric.com> Date: Sat, 28 Jun 2008 18:54:47 +0200 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.16pre (Windows/20080621) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20080607035911.GD4565@cdnetworks.co.kr> <484BC9FB.2040605@andric.com> <20080609012657.GD12521@cdnetworks.co.kr> <484D215A.7050700@andric.com> <20080609123206.GF12521@cdnetworks.co.kr> <484D25CC.9050106@andric.com> <20080610050550.GB17874@cdnetworks.co.kr> <484E9377.2050609@andric.com> <20080611005814.GA3529@cdnetworks.co.kr> In-Reply-To: <20080611005814.GA3529@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Call for testers: re(4) and RTL8168C/RTL8168CP/RTL8111C/RTL8111CP 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: Sat, 28 Jun 2008 16:54:52 -0000 On 2008-06-11 02:58, Pyun YongHyeon wrote: > > This seems to work better, although it still takes quite some time > > (~10s) for the interfaces to go up at boot time. I haven't yet been > > able to get them "stuck", however, so that's good. :) > Hmm, that's interesting. Can you spot where re(4) spends its time? > Did RELENG_7 also have this issue? Apparently it's experiencing timeouts, I usually get these: re0: link state changed to DOWN re0: watchdog timeout re0: 3 link states coalesced re0: link state changed to UP re1: link state changed to DOWN I've been running all tests under RELENG_7, btw. Note also, these delays don't always happen, in some cases the interfaces react very quickly. In rare cases, they don't work at all, until you manually ifconfig down and up them a few times. What's funny though, is that the interfaces seem to start in DOWN mode: [...booting...] Mounting local file systems:. Setting hostname: tensor.andric.com. re0: link state changed to DOWN re1: link state changed to DOWN lo0: flags=8049 metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff000000 re0: flags=8843 metric 0 mtu 1500 options=399b ether 00:30:18:a6:f1:a8 inet6 fe80::230:18ff:fea6:f1a8%re0 prefixlen 64 tentative scopeid 0x1 inet 87.251.56.140 netmask 0xffffffc0 broadcast 87.251.56.191 media: Ethernet autoselect (none) status: no carrier re1: flags=8843 metric 0 mtu 1500 options=399b ether 00:30:18:a6:f1:a9 inet6 fe80::230:18ff:fea6:f1a9%re1 prefixlen 64 tentative scopeid 0x2 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (none) status: no carrier [...more initialization...] net.inet6.ip6.forwarding: 0 -> 1 net.inet6.ip6.accept_rtadv: 0 -> 0 re0: link state changed to UP re1: link state changed to UP and only then do they "really" go up... :) Do you have any good suggestions on where I could put some debug printfs in re to find out what it's timing out on? > Plugging/unplugging UTP cable to ethernet controller during boot > change the long delay? How about disabling WOL before system > shutdown?(e.g. ifconfig re0 -wol) Plugging/unplugging the cable doesn't seem to make much difference, and neither does disabling WOL before shutdown (or altogether)...