2018-03-07 14:51 GMT+01:00 Steffen Maier <maier@xxxxxxxxxxxxxxxxxx>: > > On 03/07/2018 09:24 AM, Menion wrote: >> > ... > > but from then on, you only get it roughly once every 300 seconds, i.e. 5 > minutes > > that's where I suspect user space as trigger, unless there is a kernel > feature I'm not aware of doing such sdev rescans > > preventing this would be a workaround > Is it possible that it is smartd? It is the only daemon that could do some low level access to the device (bypassing the filesystem) > >> /* >> * Many devices do not respond properly to >> READ_CAPACITY_16. >> * Tell the SCSI layer to try READ_CAPACITY_10 first. >> * However some USB 3.0 drive enclosures return capacity >> * modulo 2TB. Those must use READ_CAPACITY_16 >> */ >> if (!(us->fflags & US_FL_NEEDS_CAP16)) >> sdev->try_rc_10_first = 1; > > > if that's the cause, maybe an entry in drivers/usb/storage/unusual_devs.h > would help, but that's really just guessing as I'm not familiar with USB > It seems that the bridge does have an entry in unusual_devs.h: /* Reported by Michael Büsch <m@xxxxxxx> */ UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0116, "JMicron", "USB to ATA/ATAPI Bridge", USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_BROKEN_FUA ), VID:PID is 0x152d 0x0567, not sure what are the other two numbers, so I went back and used another enclosure with same USB to SATA bridge. The strange thing is that this other enclosure goes in UAS mode while the one for which I am reporting the issue goes in usb-storage mode because it gets somehow the quirks 0x50000000 Unfortunately I cannot move these 5 HDDs in the other enclosure. So do you think that it shall be reported to linux-usb maybe?
