> [...] > >> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
