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
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.
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to