From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 11:01:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B985A16A41F for ; Sat, 3 Sep 2005 11:01:22 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7005A43D55 for ; Sat, 3 Sep 2005 11:01:21 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j83B1EBS022930 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 3 Sep 2005 13:01:16 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j83B0gqK032316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Sep 2005 13:00:42 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j83B0fjH013658; Sat, 3 Sep 2005 13:00:41 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j83B0a9V013657; Sat, 3 Sep 2005 13:00:36 +0200 (CEST) (envelope-from ticso) Date: Sat, 3 Sep 2005 13:00:36 +0200 From: Bernd Walter To: Scott Long Message-ID: <20050903110035.GN3267@cicely12.cicely.de> References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <4315CEEC.80100@samsco.org> <20050831174631.GE37930@cicely12.cicely.de> <4315F15D.4090209@samsco.org> <20050831221535.GB670@cicely12.cicely.de> <4316370E.4030809@samsco.org> <20050901000216.GD670@cicely12.cicely.de> <43164B88.8010903@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43164B88.8010903@samsco.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Report: * -3.3 ALL_TRUSTED Did not pass through any untrusted hosts * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on cicely12.cicely.de Cc: freebsd-current@freebsd.org, Kyle Brooks , ticso@cicely.de, Ben Kaduk Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 11:01:22 -0000 On Wed, Aug 31, 2005 at 06:30:00PM -0600, Scott Long wrote: > Bernd Walter wrote: > >On Wed, Aug 31, 2005 at 05:02:38PM -0600, Scott Long wrote: > >>Bernd Walter wrote: > >>>On Wed, Aug 31, 2005 at 12:05:17PM -0600, Scott Long wrote: > You could probably get around the problem of sleeping in the USB event > thread by doing the sleep parts of the detach in a taskqueue. But that > just adds more complexity and more need for synchronization. If the > only choice was to retain the SIM-per-device model then this is what I > would do, but it's not a choice that I like. I don't see how your single-SIM per bus solves that problem - you still have to delete a SIM in case an USB-controller is detached. USB-controller detachments can happen more often as one think, e.g. in case of a cardbus host controller. > >What I mean is a single USB device with multiple umass instances. > >umass ist just a logical interface in the USB world, normaly ment > >to allow e.g. an ulpt and umass on the same USB device, but also > >possible to have multiple umass interfaces on the same USB device. > >Since an umass interface needs at least two bulk endpoints a single > >USB-channel can have up to 16 * 127 umass instances. > > > > CAM right now is really geared for parallel SCSI with only 16 targets, > but it should work fine with 2048 targets. A project for CAMng is to > properly support FC fabrics properly as well as iSCSI; in both cases > the max-target-per-bus concept has little meaning and would need > fundamental changes. That's future work, though. OK - 2048 per bus should be fine for any possible case of umass compliant devices. I personally was worried about bus scan-time with that many targets. > For a physical device with multiple umass logical devices, each logical > device would again just be a target. The actual target and bus numbers > don't really matter in practical use because they aren't exposed to > /dev. To make it truly transparent we would need to have an automounter > like other OSes that mounts based on filesystem label, not based on > device node name. But that's mostly a detail at this point. Not exactly the same, but there is already glabel. > >OK - I got it now. > >Nevertheless I could imagine a pseudo USB-SCSI converter that just > >enhances umass transactions with a target-ID. > >This won't invalidate what you wrote above, since you still don't have > >full access on the SCSI-bus, but also requires a sim per (enhanced)umass. > > > > I assume that this is really just a mythical device, right? If it were > really just a very simple extension of the umass protocol then I'd > probably elect to treat it as multiple targets with the same single > SIM. USB to SCSI converters do exist, but I don't know if ant of them is really based on umass, so yes one can call it mythical. > >>>OK - that won't help for a practical solution. > >>>In the practical way it sounded easier to go the multiple sim way. > >>>sim detach needs to be fixed either way. > >> > >>Yes. It somewhat works now as long as the system is completely idle. > >>It breaks down horribly if I/O or error recovery is in progress and > >>a periph driver is left with CCBs in flight and/or a dangling > >>reference to a SIM. The only way to deal with this is to allow > >>blocking while CAM drains itself. > > > > > >Have to think about it. OK - dangling SIM reference is bad. But Sorry - I still don't understand any other influences. In which way a loaded single SIM system is in a better position than a multi SIM one? > >>>Are there any other technical reasons for doing single sim? > >>>You've mentioned rescource arbitration and error recovery. > >>>Is there anything that can CAM do for us that it won't with multiple > >>>sim? > >>> > >> > >>It means that you'll be able to detach umass targets without doing the > >>complicated dance of sleeping for CAM to drain itself. It also will Ack, but your proposed way of using a SIM per bus still requires SIM detaching in some cases. In the meantime I understood your point of view why you think that SIMs are logically assigned with the USB channels, but I still don't understand what it brings code-wise. I still don't see any other positive effects other than reducing the places where we need to detach a SIM. > So was the motivation to change from a single SIM to SIM-per-device > based solely on the problem of doing manual bus rescans when a device > got inserted? If not, what were the other problems that got solved? The motivation was a mix of rescan, max_lun and flexibility for mythical devices. > Btw, I envision my changes resulting in a SIM per USB controller. So > on a system with 3-4 controllers (as seem to be common these days), > you'd have that many SIMs. umass targets would be paired with the SIM > that was associated with the physical USB controller/bus of the target. > > Scott -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de