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 <hans.petter.sela...@bitfrost.no> > To: Kirk McKusick <mckus...@mckusick.com> > 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 _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"