From owner-freebsd-stable@FreeBSD.ORG Fri May 24 05:58:34 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0C1BCC26 for ; Fri, 24 May 2013 05:58:34 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by mx1.freebsd.org (Postfix) with ESMTP id 885ABDD6 for ; Fri, 24 May 2013 05:58:33 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta11.emeryville.ca.mail.comcast.net with comcast id fhvp1l0031eYJf8ABhyZ0L; Fri, 24 May 2013 05:58:33 +0000 Received: from jdc.koitsu.org ([67.180.84.87]) by omta19.emeryville.ca.mail.comcast.net with comcast id fhyY1l00R1t3BNj01hyY7f; Fri, 24 May 2013 05:58:33 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7763773A33; Thu, 23 May 2013 22:58:32 -0700 (PDT) Date: Thu, 23 May 2013 22:58:32 -0700 From: Jeremy Chadwick To: YongHyeon PYUN Subject: Re: Apparent fxp regression in FreeBSD 8.4-RC3 Message-ID: <20130524055832.GA42673@icarus.home.lan> References: <20130524010943.GA37252@icarus.home.lan> <20130524012117.GE1672@glenbarber.us> <20130524030351.GA39091@icarus.home.lan> <20130524031303.GC28865@glenbarber.us> <20130524033806.GA39720@icarus.home.lan> <20130524034244.GD28865@glenbarber.us> <20130524044035.GA40957@icarus.home.lan> <20130524044919.GA41292@icarus.home.lan> <20130524054720.GA1496@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130524054720.GA1496@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369375113; bh=w+iL3L+LK2+aPkNnfeXppJYHjevC6RPhnzwSYW4fmHM=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=iOg/CG8ncfR88nyD/4p05n8D5nWt4ILSgns/3IG1bzGs0Q3IHGT/17StTJTWRCEcv etKMt6bSrLbhGB8TfRn2xvbpZIkFwqCHcD+0zFque0fREoFtCJHdAnSxWQwG6vi3VX gwYV5oVgqrfh90MotB+EaPEL+nBPfFBEM7E12gczts5iWSLn+y3KdaiPRqfqjNAQV9 zQs61ZQpH5MAhv48dAO1ZXkPGFaTwCHGVq80jMGkKgc6h9hxgbNNZo9Tfpohwe1ySJ c3BXDiFXHRYtMY4RC7V2auqF+Ffz7oqmMj55JVeVtDG8XAAxCK+TdPAcm5n3Di42vA w2U/JRMXra9tw== Cc: Glen Barber , freebsd-stable@freebsd.org, FreeBSD Release Engineering Team X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 05:58:34 -0000 On Fri, May 24, 2013 at 02:47:20PM +0900, YongHyeon PYUN wrote: > On Thu, May 23, 2013 at 09:49:19PM -0700, Jeremy Chadwick wrote: > > On Thu, May 23, 2013 at 09:40:35PM -0700, Jeremy Chadwick wrote: > > > On Thu, May 23, 2013 at 11:42:44PM -0400, Glen Barber wrote: > > > > On Thu, May 23, 2013 at 08:38:06PM -0700, Jeremy Chadwick wrote: > > > > > If someone wants me to test DHCP via fxp(4) on the above system (I can > > > > > do so with both NICs), just let me know; it should only take me half an > > > > > hour or so. > > > > > > > > > > I'll politely wait for someone to say "please do so" else won't bother. > > > > > > > > > > > > > For the sake of completeness... > > > > > > > > "Please do so." :) > > > > > > Issue reproduced 100% reliably, even within sysinstall. > > > > > > {snip} > > > > Forgot to add: > > > > This issue ONLY happens when using DHCP. > > > > Statically assigning the IP address works fine; fxp0 goes down once, > > up once, then stays up indefinitely. > > I asked Mike to try backing out dhclient(8) change(r247336) but it > seems he missed that. Jeremy, could you try that? > > I guess dhclient(8) does not like flow-control negotiation of > fxp(4) after link establishment. I can't test anything without an ISO -- the system in question is truly "bare-bones" (no hard disk, can't boot USB memsticks, etc.). I'm not a good test subject for changes on this one, I'm sorry to say. :-( If there's some way to disable flow-control negotiation in fxp(4) or miibus(4) via loader, I can try that, but I don't know what the MIB name would be. If r247336 turns out to be the cause: ironic, as r247336 references PR 166656, which was tested against -- wait for it -- xl(4). People in *this* thread are saying "screw legacy hardware" yet the PR is for something as old as the 3C905B? Maybe I should bow out of this thread before I have an aneurysm. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |