From owner-freebsd-usb@FreeBSD.ORG Sun Jan 27 18:36:45 2008 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CEEB16A41B for ; Sun, 27 Jan 2008 18:36:45 +0000 (UTC) (envelope-from henrik@gulbra.net) Received: from av7-1-sn3.vrr.skanova.net (av7-1-sn3.vrr.skanova.net [81.228.9.181]) by mx1.freebsd.org (Postfix) with ESMTP id 8A51C13C4E3 for ; Sun, 27 Jan 2008 18:36:44 +0000 (UTC) (envelope-from henrik@gulbra.net) Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 4D18D38AB8; Sun, 27 Jan 2008 19:31:35 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 22BAA38931; Sun, 27 Jan 2008 19:31:35 +0100 (CET) Received: from [192.168.0.2] (81-235-156-87-no29.tbcn.telia.com [81.235.156.87]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 30A3337E44; Sun, 27 Jan 2008 19:36:41 +0100 (CET) From: Henrik Gulbrandsen To: Peter Jeremy In-Reply-To: <20080127032955.GI53741@server.vk2pj.dyndns.org> References: <200801260034.m0Q0YVVD012819@freefall.freebsd.org> <1201348494.2277.96.camel@Particle> <20080127032955.GI53741@server.vk2pj.dyndns.org> Content-Type: text/plain Date: Sun, 27 Jan 2008 19:36:28 +0100 Message-Id: <1201458988.2277.285.camel@Particle> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: oliver@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/84336: [usb] [reboot] instant system reboot when unmounting a powered off/unplugged+replugged USB device 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: Sun, 27 Jan 2008 18:36:45 -0000 On Sun, 2008-01-27 at 14:29 +1100, Peter Jeremy wrote: > This approach doesn't work because GEOM doesn't know the drive has > gone away until it's no longer present. At that point it's too late > to write unflushed buffers. And a devfs-triggered forced unmount does > not address the issue of in-flight I/O's between when the media goes > away and the filesystem is unmounted. Well, unflushed buffers will obviously be discarded, but this scenario is focused on small umass devices, which should be mounted with -o sync. In this case, everything will typically already be written to disk. The in-flight I/O part used to be a cause of crashes, but this should work now, with the patches that Warner has already committed to 8.0-CURRENT. > This problem is one of a number of problems within FreeBSD where there > is a disconnect between the people who want the problem solved and those > with the skills to actually solve the problem. This is a side-effect of > FreeBSD being a volunteer project and it's not clear how to fix this. The "volunteer project" mantra is not an excuse to leave the difficult problems unsolved. It just means that sometimes I have to be the one who volunteers a solution. Ideally, that solution would then be reviewed and either committed to the tree or rejected for a valid technical reason. Unfortunately, there are few volunteers for this part of the process :-( On Sat, 2008-01-26 at 20:40 -0700, M. Warner Losh wrote: > One of the things that I've been working on with someone (whose name > escapes me) and Bruce Evans is trying to address these issues. One > problem we have today is that when the device return ENXIO, the buffer > cache retries the operation rather than failing it upstream. There > are a number of issues with doing this, including fixing all the > filesystems to cope with errors. I've committed a number of 'keep the > system from panicing' type fixes, but much works remains to be done. I'd like to think that I'm "someone" :-) While I agree with you that there is still work to do, I think most of it would actually be side issues not directly related to usb/46176 or usb/84336. Things should be working for USB memory sticks and cameras, but perhaps flash cards still trigger it, or file systems other than msdosfs have problems, or the fix happens to introduce a memory leak. All of these problems would be better handled with more specific PRs. Writing as the guy who actually spent two and a half hours in a futile attempt to reproduce this problem with all patches applied, I'd say that the usb/46176 problem has passed on. It is no more. It has ceased to be. This is an ex-bug! At least until someone tells me why I'm a fool! :-) /Henrik P.S. I had some extra background information here, but it turned out to be longer than expected, so I will send it as a separate email.