On 24/08/2018 17:39, Alan Stern wrote:
On Fri, 24 Aug 2018, Klaus Kusche wrote:
On 24/08/2018 16:15, Alan Stern wrote:
On Fri, 24 Aug 2018, Klaus Kusche wrote:
I entered the following USB bug into kernel bugzilla yesterday:
https://bugzilla.kernel.org/show_bug.cgi?id=200917
"Since 4.18, all my external USB3-to-SATA Icybox disk enclosures with usb Id
357d:7788 (seems to be a very common controller chip: Sharkoon QuickPort XT)
fail with the following error when mounting an ext4 fs:
If all else fails, you can try using git-bisect to find the commit
which causes the errors.
Uhh, I'm not sure I have the time to do that...
(that's something like 15 kernel builds?)
print_req_error: critical target error, dev sdd, sector 2048
Buffer I/O error on dev sdd1, logical block 0, lost sync page write
EXT4-fs (sdd1): I/O error while writing superblock
EXT4-fs (sdd1): mount failed
- They worked before 4.18.
- Reading is definitely ok, async writing seems to work, too.
- The problem occurs with several different disks (I only tested HGST drives).
- The same disks work in enclosures with other controllers."
It does sound like a bug in the enclosure.
It is that specific controller chip.
I tried 3 enclosures with that usb id (all fail since 4.18),
and 5 enclosures with different usb id's (all still work).
Please provide the output from "dmesg".
[ 3692.559336] sd 7:0:0:0: [sdd] 976773168 512-byte logical blocks: (500 GB/466
GiB)
[ 3692.559595] sd 7:0:0:0: [sdd] Write Protect is off
[ 3692.559598] sd 7:0:0:0: [sdd] Mode Sense: 47 00 10 08
[ 3692.559881] sd 7:0:0:0: [sdd] Write cache: enabled, read cache: enabled,
supports DPO and FUA
[ 3692.575820] sdd: sdd1
[ 3692.576941] sd 7:0:0:0: [sdd] Attached SCSI disk
[ 3725.164065] sd 7:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 3725.164071] sd 7:0:0:0: [sdd] tag#0 Sense Key : Illegal Request [current]
[ 3725.164075] sd 7:0:0:0: [sdd] tag#0 Add. Sense: Invalid field in cdb
[ 3725.164080] sd 7:0:0:0: [sdd] tag#0 CDB: Write(10) 2a 08 00 00 08 00 00 00 08 00
This indicates the error occurred shortly after the drive was plugged
in. A usbmon trace might be helpful. Can you collect and send a trace
for bus 4, starting shortly before you plug in the drive and ending
after the error occurs?
I'll try tomorrow (I don't have usbmon installed or configured).
The error does not happen when plugging the drive in.
It happens when rw-mounting an ext4 fs on the drive
(as far as I know, the affected sector 2048 is indeed the ext4 superblock).
Ro-mounting and reading the same ext4 fs in the same enclusoure works fine,
and a vfat on such a drive can even be rw-mounted and successfully written.
Hence, obviously rw-mounting an ext4 fs emits some special write command
which fails with that controller since 4.18.
And a completely different guess: The controller is UAS-blacklisted.
Do you know if it has always been, or if it was blacklisted with 4.18?
If linux used UAS before 4.18 and switched to usb-storage in 4.18,
that could also explain why I never saw that error before...
(just telling from the speed I'd assume that the enclosures used UAS
up to now: These are my backup drives, and before 4.18,
they had sustained read/write transfer rates at physical drive speed,
around 120 MB/s. I don't think usb-storage is able to do that...).
--
Prof. Dr. Klaus Kusche
Private address: Rosenberg 41, 07546 Gera, Germany
+49 365 20413058 klaus.kusche@xxxxxxxxxxxxxxx https://www.computerix.info
Office address: DHGE Gera, Weg der Freundschaft 4, 07546 Gera, Germany
+49 365 4341 306 klaus.kusche@xxxxxxx https://www.dhge.de
