From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 18:32:53 2010 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 F17C7106566B for ; Thu, 14 Jan 2010 18:32:53 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 7A01A8FC1B for ; Thu, 14 Jan 2010 18:32:52 +0000 (UTC) Received: by fxm27 with SMTP id 27so1142166fxm.3 for ; Thu, 14 Jan 2010 10:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=zn/fiA7kiasTm4bzWORIDeo2zyCXdkgt/kd2hJhSo4Y=; b=jADibHUfI/XL096/OzMmZlcnt7yZdEAG4VZ0EHDNH7W1Q4bebqRqdRTILH9GjaGLBB 4ERxDQtMOMfcSJTKsx+5ScqnvCYtpR0oeH70uvlEWtt/jffgZopLIwFj/PwnsNU/kaDY RAAkfZNxdpbmzbJOyUgWKu+WohCgHT+R4+zFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ORv9lnIVoRJ/2i5ga4mwmR8bGVT1240yVoSk7iRYZjZOixnAGlhJQi6QBucK2KOJmg 22xR6VHV3RGOAAxznpau7EnwB3ZVLGk1/VM4hcQRKz6WVKj5ya2yHg0b8ubTixGkPBOP 4c87sDUaQSOzgtAwu02dQBHEYuPAU0ASdpOZ4= Received: by 10.223.21.15 with SMTP id h15mr1473476fab.15.1263493963448; Thu, 14 Jan 2010 10:32:43 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm47314fxm.8.2010.01.14.10.32.41 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Jan 2010 10:32:42 -0800 (PST) Sender: Alexander Motin Message-ID: <4B4F6346.3090404@FreeBSD.org> Date: Thu, 14 Jan 2010 20:32:38 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: "James R. Van Artsdalen" References: <20091002150931.K35591@pooker.samsco.org> <200911050922.10205.hselasky@c2i.net> <4AFCB277.5070306@delphij.net> <200911130909.30828.hselasky@c2i.net> <4B4F4E55.1050906@jrv.org> In-Reply-To: <4B4F4E55.1050906@jrv.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Marcel Moolenaar , Hans Petter Selasky Subject: Re: Fix for USB media not found at boot 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: Thu, 14 Jan 2010 18:32:54 -0000 James R. Van Artsdalen wrote: > Hans Petter Selasky wrote: >> The changeset in question has not been committed to mainstream. >> >> Scott Long is working on an improved solution. Please coordinate with him. > > Has anything happened with the general case? A friend of mine reported > to me a regression between 8.0-RELEASE and 8-STABLE that turns out to be > this issue with SATA port multipliers. > > I have the same problem, except that I need to further wait for GEOM to > make visible a gmirror made of two slow devices (behind SATA port > multiplier). There is a set of several related problems I am aware of and working on: 1. There are problems with synchronization of different CAM parts. It wasn't so important for SCSI, but it does for ATA, especially for error recovery. Recently I have made patch in Perforce (one you are testing now) to solve that. 2. Automatic device hot-plug is not very unified in CAM and just not implemented yet for plain SATA (without PMP). It is related to the topic by several questions like: what if controller detects device appearance before CAM initially scanned, should we do it twice? 3. There are problems with late-coming SIMs, such as umass on USB, ATA on PCCard/CardBus and so on. As they may arrive too late for system-wide CAM bus scanning, each of them have to handle own scan by them selves. Now I am going to rewrite scan process, to make every bus scanned automatically on arrive, as soon as system will be able to do it. It will remove some duplicate code from about ten different drivers and should make process more unified. 4. Port Multiplier is a some kind of late-coming device. It has own scanning routine, which may only start, when main scan is already completing. There are two possible ways: either make main bus scan call wait for some event from PMP driver before return, or ignore it there and let system wait on root mounting, while all such scan processes will be finished. I haven't decided yet, which way to go. 5. To make device ordering repeatable between reboots, CAM originally used quite simple and dirty practice of not loading peripheral drivers, until all buses complete scan. It was working fine in a simple world without hot-plug. But it just not working any more for late-coming devices. At this moment I don't see really good solution here, as there is no moment when we can be sure that all possible devices are arrived. It is possible to bind device numbers by hands, but it is overcomplicated for the most cases. Problems 4 and 5 result in common general question: What to do with late devices? Either try in any possible way extend CAM bus scanning period for them (which is even theoretically impossible, as some device will always trying to get late there), or gave up there and put all chips on delaying FS mounting stage. In last case we have to do something with unstable device numbering. -- Alexander Motin