From owner-freebsd-stable@FreeBSD.ORG Mon Apr 4 11:18:06 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DEA916A4CE for ; Mon, 4 Apr 2005 11:18:06 +0000 (GMT) Received: from mail22.syd.optusnet.com.au (mail22.syd.optusnet.com.au [211.29.133.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id A033B43D54 for ; Mon, 4 Apr 2005 11:18:05 +0000 (GMT) (envelope-from gmenhennitt@optusnet.com.au) Received: from [203.2.73.8] (c220-237-137-84.mckinn1.vic.optusnet.com.au [220.237.137.84])j34BI3oi004556; Mon, 4 Apr 2005 21:18:04 +1000 Message-ID: <425121DF.3070203@optusnet.com.au> Date: Mon, 04 Apr 2005 21:15:43 +1000 From: Graham Menhennitt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Doug White References: <42436771.3060006@optusnet.com.au> <20050325133558.U16071@carver.gumbysoft.com> <42449BCE.7010600@optusnet.com.au> <20050327130409.F35584@carver.gumbysoft.com> <4247AFDB.1060307@optusnet.com.au> <20050329184539.C58510@carver.gumbysoft.com> In-Reply-To: <20050329184539.C58510@carver.gumbysoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-stable@freebsd.org Subject: Re: "ffs_mountroot: can't find rootvp" after cvsup and making worldfmen X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2005 11:18:06 -0000 Doug White wrote: >>Anyway, I now have a working kernel. I presume that I should file a PR >>on this. >> >> > >Yes please. > > Done - kern/79332 >Do you have a long delay at the point where the bogus messages are printed >in the newer kernel, but in the older? The change implies that it will get >out of a busted channel faster, but your disk apparently needs a longer >delay. If its hanging for the full 30s on the working kernel then that >woud explain why shortening the dealy ends up with a missing disk. > > No, there is about a 3 second delay. >If you want to try another workaround, increase the ata_udelay(100000); by >2, and progressively longer until your disk reappears. (You may want to >reduce the for exit condition on timeout since it'll wait 310 iterations.) >If that doesn't work, start increasing the DELAY()s. > > I've increased it to 400000 and it fixes the problem - 300000 doesn't. I'll update the PR to reflect this. Thanks for your help, Graham