From owner-freebsd-usb@FreeBSD.ORG Thu Nov 1 13:38:46 2007 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 4AB0216A418 for ; Thu, 1 Nov 2007 13:38:46 +0000 (UTC) (envelope-from henrik@gulbra.net) Received: from av12-2-sn2.hy.skanova.net (av12-2-sn2.hy.skanova.net [81.228.8.186]) by mx1.freebsd.org (Postfix) with ESMTP id D14C513C4A7 for ; Thu, 1 Nov 2007 13:38:45 +0000 (UTC) (envelope-from henrik@gulbra.net) Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id 771FF398DB; Thu, 1 Nov 2007 13:38:41 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-2-sn2.hy.skanova.net (Postfix) with ESMTP id 50F24398A0 for ; Thu, 1 Nov 2007 13:38:41 +0100 (CET) Received: from [192.168.0.2] (81-235-156-87-no29.tbcn.telia.com [81.235.156.87]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 369D537E55 for ; Thu, 1 Nov 2007 13:38:40 +0100 (CET) From: Henrik Gulbrandsen To: freebsd-usb In-Reply-To: <1193917730.1166.186.camel@Particle> References: <1193917730.1166.186.camel@Particle> Content-Type: text/plain Date: Thu, 01 Nov 2007 13:37:37 +0100 Message-Id: <1193920657.1166.192.camel@Particle> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: Patches for usb/46176 (problems with umass removal before unmount) 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: Thu, 01 Nov 2007 13:38:46 -0000 Well, apparently the list is stripping even small binary attachments, so I guess I'll just have to point you to a suitable location on the web: http://www.gulbra.net/freebsd-usb/umass.tar.gz /Henrik On Thu, 2007-11-01 at 12:48 +0100, Henrik Gulbrandsen wrote: > This is not a complete fix, but this bug has been, eh... bugging me ever > since I first crashed my system back in 2004. I had a set of patches for > 5.3-BETA3, but it was too late to have it included on the 5.3 track, and > since I was expecting some heavy redesign in the involved kernel parts, > I dropped the patch delivery. > > Unfortunately, not that much has changed in this area in the past three > years, and the current behavior is still far from the ideal I'd prefer: > when you plug in a USB memory stick, a new directory is automatically > mounted, and when it is unplugged, the directory silently disappears. > > The attached umass.tar.gz file contains patches and scripts that will > give you this functionality in about 99% of the cases. The exact point > of failure had moved a little since 5.3-BETA3, but the panic is still > not difficult to avoid. However, the code is still highly experimental. > In about 1% of USB detaches, the kernel will freeze. More specifically, > in my four test runs, it happened after 63, 107, 6, and 321 cycles of > attach followed by detach. Your mileage will most likely vary. > > I understand that the disk and file systems were not really designed for > disappearing devices, so it's not that surprising if some lock is left > locked under some circumstances. Or something completely different :-) > Normally, I would continue looking for it, but I have other plans for > the next month or two, so I don't know if I'll get the time. Perhaps > someone else is interested enough to give it a shot... > > > Anyway, here is a quick overview of the contents of umass.tar.gz: > > etc/usbd.conf.patch: an added entry in the usbd.conf file, to handle the > umass devices. Yeah, I know... this should probably have used devd.conf > instead, but this part is three years old and I didn't want to rerun the > 321 attach/detach tests to verify that there is no important difference. > > etc/usbd/umass: the script that handles mounting and unmounting of the > device directory under /media. I tried to make it work as expected, but > I only have a single environment and a single USB memory stick to test > with, so there may be some issues left. You'll get the gist, though... > > home/.umass: the main umass script will mount a directory if there is a > single X11 user, or if there is no X11 user but a single user logged in > at a local text terminal. The new directory will be owned by that user. > If a .umass file exists in the user's home directory, it will be run to > do more advanced things with the data. The included .umass is an example > script that opens the GNOME file manager when the directory is mounted. > > src/msdosfs_vfsops.c.patch: the msdosfs will normally try to write the > "clean" bit back to disk at unmount. When the drive is unplugged without > warning, this would not only leave the file system marked as dirty, but > will also cause a write failure. This patch modifies the implementation > to keep the bit clean all the time if the file system is mounted with > the "-o sync" option. This should be the case for USB memory sticks. > > src/usb_subr.c.patch: the usbd fails to match a usbd.conf entry during > detach, since the detach event is filled in after the device is gone. > This is easily fixed by moving a line to fill in the information before > we clear all the relevant data. > > src/vfs_bio.c.patch: when the device is gone, remaining write attempts > will correctly fail with ENXIO, but the failed buffer will get stuck in > the sync queue. In 5.3-BETA3, this wasn't obvious until it blocked the > unmounting of file systems at shutdown. Nowadays, it's detected earlier > but this patch still seems to help. > > src/vfs_mount.c.patch: the only null-pointer problem left in the way of > detaching is when the unmounting code discovers that it couldn't access > the device and attempts to backtrack the correct handling already done. > This patch makes it ignore the ENXIO error and finish the unmounting. > > > That's it. I would hate to see another major release of FreeBSD where a > system must be rebooted just because you forgot to do the umount before > unplugging a umass device. It may again be too late to fix the remaining > problems in time for the release, but I am at least hoping to see things > work in 8-CURRENT Real Soon Now... > > /Henrik