From owner-freebsd-usb@FreeBSD.ORG Fri Feb 10 23:48:29 2012 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17A92106566C; Fri, 10 Feb 2012 23:48:29 +0000 (UTC) (envelope-from mckusick@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0808C8FC15; Fri, 10 Feb 2012 23:48:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1ANmSxP029047; Fri, 10 Feb 2012 23:48:28 GMT (envelope-from mckusick@freefall.freebsd.org) Received: (from mckusick@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1ANmSrT029043; Fri, 10 Feb 2012 23:48:28 GMT (envelope-from mckusick) Date: Fri, 10 Feb 2012 23:48:28 GMT Message-Id: <201202102348.q1ANmSrT029043@freefall.freebsd.org> To: oskar.nordquist@gmail.com, mckusick@FreeBSD.org, freebsd-usb@FreeBSD.org From: mckusick@FreeBSD.org Cc: Subject: Re: kern/158711: [usb] [panic] panic in ffs_blkfree and ffs_valloc 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: Fri, 10 Feb 2012 23:48:29 -0000 Synopsis: [usb] [panic] panic in ffs_blkfree and ffs_valloc State-Changed-From-To: open->closed State-Changed-By: mckusick State-Changed-When: Fri Feb 10 23:47:23 UTC 2012 State-Changed-Why: This response from one of the USB maintainers: > From: Hans Petter Selasky > To: Kirk McKusick > Subject: Re: USB Bug in kern/158711? > Date: Fri, 10 Feb 2012 21:44:08 +0100 > > Hi Kirk, > > USB SCSI commands can fail. Probably that's what is happening. > I'm not sure what we can do about it when SWAP or UFS metadata > is lost :-) > > The author could try to set: > > hw.usb.ehci.lostintrbug=1 > > In /boot/loader.conf > > Maybe that helps, if his chipset is broken. > > Else make sure USB HDD's are properly powered. > > Anyway, is it right to panic on such a failure? What if this > data is written at the moment a device is unplugged? > > --HPS The key is that the filesystem has to get an error back if a write fails or was unable to be completed. It can then take evasive action to avoid doing something that would cause an inconsistent filesystem (which triggers the panic). Admittedly the usual action is to refuse to do any further writes to the filesystem until its integrity is checked, but that is better than a panic. So, I am guessing that somehow an I/O error happened that was not reflected back to the filesystem. Apparently this lack of error reporting is possible in the presence of a broken chipset or when a device is unplugged. While there have been many later improvements to the USB subsystem since this report was filed, lack of error reporting is still possible in which case filesystem corruption and panic will happen. http://www.freebsd.org/cgi/query-pr.cgi?pr=158711