Hello,
On 01/09/2018 17:38, Alan Stern wrote:
However, the USB layer does set certain quirk bits which can cause
those other parts to avoid sending certain commands. Perhaps your
controller needs the BROKEN_FUA flag (see the existing entries in
drivers/usb/storage/unusual_devs.h with that flag).
The following seems to fix the problem (I don't know if I did it right):
--- unusual_uas.h.orig 2018-09-09 10:31:20.440751625 +0200
+++ unusual_uas.h 2018-09-09 10:32:30.491381466 +0200
@@ -95,7 +95,7 @@
"JMicron",
"JMS566",
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
- US_FL_NO_REPORT_OPCODES | US_FL_IGNORE_UAS),
+ US_FL_NO_REPORT_OPCODES | US_FL_IGNORE_UAS | US_FL_BROKEN_FUA),
/* Reported-by: Hans de Goede <[email protected]> */
UNUSUAL_DEV(0x4971, 0x1012, 0x0000, 0x9999,
When plugging in the USB enclosure, syslog now says:
Sep 09 10:36:51 lap kernel: sd 6:0:0:0: [sdc] Disabling FUA
Sep 09 10:36:51 lap kernel: sd 6:0:0:0: [sdc] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
With that, the disk can be mounted, read and written
with no error at the user level.
There is just one irritating message in the syslog:
Sep 09 10:42:53 lap kernel: sd 6:0:0:0: [sdc] Synchronizing SCSI cache
Sep 09 10:42:53 lap kernel: sd 6:0:0:0: [sdc] Synchronize Cache(10) failed:
Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
--
Prof. Dr. Klaus Kusche
Private address: Rosenberg 41, 07546 Gera, Germany
+49 365 20413058 [email protected] https://www.computerix.info
Office address: DHGE Gera, Weg der Freundschaft 4, 07546 Gera, Germany
+49 365 4341 306 [email protected] https://www.dhge.de
