> [...]
>
>> sd 8:0:0:0: [sdb] Synchronizing SCSI cache
>> sd 8:0:0:0: Device offlined - not ready after error recovery
>>
>> Unplugging and replugging the device does not result in the
>> reappearance of the /dev/sdb device file like it does with my other
>> external drives.  The only way to bring the /dev/sdb device file back
>> is to 'modprobe -r xhci_hcd && modprobe xhci_hcd'.
>
> [...]
>
> I'm not sure where the problem is exactly but I think it is really
> a problem with the power down of some USB hardware in the chain.
> I am wondering why this still exists on your quite new hardware.

Do you think it must be a problem with power down of the USB3 SSD
since this doesn't happen with a USB3 HD I have?

> I see this here on my own (a few years old) laptop with experimenting
> some power control settings.
> I think your USB port got power switched off and so can't detect that
> you have re-plugged a new device.
> So my idea is, with reloading the kernel module the power is switched
> on again.
> Maybe there should be a config option in userspace to disable
> powerdown and only unmount filesystems if it is not possible
> to detect powerdown support of hardware?!

I'm not sure I follow.  Why only unmount filesystems if it isn't
possible to detect powerdown support of hardware (is that the port or
the drive)?

I noticed this in linux-3.10-rc2 for the first time but I think it is
always enabled on previous kernels and this option only allows it to
be disabled:

CONFIG_USB_DEFAULT_PERSIST:

Say N here if you don't want USB power session persistance
enabled by default.  If you say N it will make suspended USB
devices that lose power get reenumerated as if they had been
unplugged, causing any mounted filesystems to be lost.  The
persist feature can still be enabled for individual devices
through the power/persist sysfs node. See
Documentation/usb/persist.txt for more info.

Should I file a kernel bug?

- Grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to