From owner-freebsd-usb@FreeBSD.ORG Sat May 26 08:21:44 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 337DE16A41F; Sat, 26 May 2007 08:21:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E3CFC13C469; Sat, 26 May 2007 08:21:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l4Q8KOLe015248; Sat, 26 May 2007 02:20:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 26 May 2007 02:20:40 -0600 (MDT) Message-Id: <20070526.022040.-1975968734.imp@bsdimp.com> To: hselasky@freebsd.org From: "M. Warner Losh" In-Reply-To: <200705261012.57815.hselasky@freebsd.org> References: <200705260602.l4Q62mZX076307@freefall.freebsd.org> <200705261012.57815.hselasky@freebsd.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 26 May 2007 02:20:24 -0600 (MDT) Cc: linimon@freebsd.org, freebsd-usb@freebsd.org, jema@mail.ru Subject: Re: usb/82569: [usb] USB mass storage plug/unplug causes system panic X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2007 08:21:44 -0000 In message: <200705261012.57815.hselasky@freebsd.org> Hans Petter Selasky writes: : On Saturday 26 May 2007 08:02, Mark Linimon wrote: : > Synopsis: [usb] USB mass storage plug/unplug causes system panic : > : > State-Changed-From-To: open->suspended : > State-Changed-By: linimon : > State-Changed-When: Sat May 26 06:02:04 UTC 2007 : > State-Changed-Why: : > Mark this 'suspended' as it is a known problem that will require an : > extensive rework to fix. : > : : This is not really an USB problem. It is a generic CAM layer problem, and we : should have a good solution for it! There's many layers to this onion. Even if one were to solve the CAM layer problem, and that's a fairly minor problem in the scheme of things, the VM layer really hates it when devices disappear. There's too many cached copies of things. The CAM problems just have to do with the SIM disappearing. One could argue that one needs to defer the device disappearance until one can be sure that all outstanding I/O is bioerrored() back to the source, which requires some help in the leaf driver nodes. One could also argue that one should have one SIM per root usb hub, and all the umass devices use it. This would allow for stupid devices to be more effectively supported (since the leave/arrival would be transparent to higher levels). firewire does something similar right now, and it works a lot better than usb's implementation. while not perfect, I can pull out a firewire disk and the system just stalls the I/Os. I can then plug it back in and resume where it left off. Very nice feature that. Warner