From owner-freebsd-stable@FreeBSD.ORG Tue Jan 13 15:27:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2D0F1065673 for ; Tue, 13 Jan 2009 15:27:38 +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 AEA968FC1E for ; Tue, 13 Jan 2009 15:27:38 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:288b:5365:201d:ccd6] (unknown [IPv6:2001:7b8:3a7:0:288b:5365:201d:ccd6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8E9EF11F838; Tue, 13 Jan 2009 16:27:37 +0100 (CET) Message-ID: <496CB2E7.2060902@andric.com> Date: Tue, 13 Jan 2009 16:27:35 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b3pre) Gecko/20090108 Shredder/3.0b2pre MIME-Version: 1.0 To: pyunyh@gmail.com References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com> <8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com> <88527079.20090111192206@donpac.ru> <20090112011146.GC46346@cdnetworks.co.kr> <64114.83.221.215.168.1231741940.squirrel@83.221.215.168> <20090112064121.GF46346@cdnetworks.co.kr> <496B71D3.5050203@andric.com> <20090113050223.GH46346@cdnetworks.co.kr> In-Reply-To: <20090113050223.GH46346@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, eugene@donpac.ru Subject: Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2009 15:27:39 -0000 On 2009-01-13 06:02, Pyun YongHyeon wrote: > > I'm also having problems with re's, in my case the interfaces take about > > 10 seconds to come up, if they come up at all. After the interfaces are > > up, half the time no packets go out at all. Usually it helps to bring > > them down via the console, wait about 10 seconds, and then bring them up > > again... > It looks like that RTL8169SC users see regression and I vaguely > remember a couple of issues on RTL8169SC. As Jung-uk said in other > post, would yoy try reverting r180519? Reverting r180519 seems to solve the problem of not being able to send any packets. It does not solve the other problem, which is that the interfaces can take a very long time to come up at boot time, e.g: Setting hostuuid: 3ee65237-8025-11dc-9ab5-003018a6f1a8. Setting hostid: 0xaaedab9a. Mounting local file systems:. Setting hostname: tensor.andric.com. [... pauses for 10 seconds here ...] 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 0x4 inet 127.0.0.1 netmask 0xff000000 re0: flags=8843 metric 0 mtu 1500 options=389b 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=389b 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 [...] (note also the "no carrier" just after upping those interfaces) > If that have no effect would > you try attached patch? Apply this patch sometimes speeds up the interfaces going up at boot time, sometimes it doesn't, I'd say about 50/50. It doesn't solve the problem of not being able to send any packets. > > And just FYI, r187080-r187083 that you recently committed (MFCs of > > r184240-184243, r184245, 185575 and r186390), don't seem to change > > anything for this situation. :( > Those MFC are for rl(4), not re(4) so you should see no behavioural > changes in re(4). Sorry about that, I always keep mixing up re(4) and rl(4)...