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
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
