On Sat, 7 Jan 2017, Jochen Barth wrote: > Dear reader, > > I'm using a Seagate Dockstar with Debian jessie kernel 3.16 and an > usb-to-pata bridge from prolific, > usb device id 067b:3507. You do realize that 3.16 is really quite old by now? > On every boot, the kernel is saying > »[ 5.058082] usb 1-1.4: new high-speed USB device number 3 using > orion-ehci > [ 5.291227] usb 1-1.4: New USB device found, idVendor=067b, > idProduct=3507 > [ 5.298168] usb 1-1.4: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 5.305519] usb 1-1.4: Product: ATAPI-6 Bridge Controller > [ 5.310955] usb 1-1.4: Manufacturer: Prolific Technology Inc. > [ 5.316743] usb 1-1.4: SerialNumber: 2E38 > [ 5.336934] SCSI subsystem initialized > [ 5.345501] usb-storage 1-1.4:1.0: USB Mass Storage device detected > [ 5.352094] usb-storage 1-1.4:1.0: Quirks match for vid 067b pid > 3507: 110 > [ 5.359097] scsi0 : usb-storage 1-1.4:1.0 > [ 5.364778] usbcore: registered new interface driver usb-storage > [ 6.363192] scsi 0:0:0:0: Direct-Access SAMSUNG HD400LD > WQ10 PQ: 0 ANSI: 0 > [ 6.385758] sd 0:0:0:0: [sda] Adjusting the sector count from its > reported value: 781420655 > [ 6.394194] sd 0:0:0:0: [sda] 781420654 512-byte logical blocks: (400 > GB/372 GiB) > [ 6.402620] sd 0:0:0:0: [sda] Write Protect is off > [ 6.407456] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 > [ 6.408367] sd 0:0:0:0: [sda] No Caching mode page found > [ 6.413724] sd 0:0:0:0: [sda] Assuming drive cache: write through« > > Look at the last two lines above: »Assuming drive cache: write through« > I tought would be definitively wrong, because the hdd behind the > usb-pata-bridge has possibly a write-back cache. That may be true, but unless the USB-PATA bridge supports the SYNCHRONIZE CACHE command, there will be no way for the computer to tell the drive to write out the cache. > Ok, I never had problems with this "misconfiguration", but the computer > has not been crashed often and the filesystems are not heavy in use... > > So I tried this kernel parameter: > »usb-storage.quirks=067b:3507:p« > > then it looked better: > »[ 6.403648] sd 0:0:0:0: [sda] No Caching mode page found > [ 6.409003] sd 0:0:0:0: [sda] Assuming drive cache: write back« > > but a few seconds later: > » 23.767645] end_request: critical target error, dev sda, sector 0 > [ 23.776883] end_request: critical target error, dev sda, sector 0 > > [ 32.951535] end_request: critical target error, dev sda, sector 2103232 > [ 32.958275] Aborting journal on device sda1-8. > [ 33.179021] EXT4-fs error (device sda1): ext4_journal_check_start:56: > Detected aborted journal > [ 33.187827] EXT4-fs (sda1): Remounting filesystem read-only > [ 34.545395] end_request: critical target error, dev sda, sector 197937613 > [ 34.552309] Aborting journal on device sda2-8. > [ 36.897247] EXT4-fs error (device sda2): ext4_journal_check_start:56: > Detected aborted journal > [ 36.906044] EXT4-fs (sda2): Remounting filesystem read-only > [ 36.912845] EXT4-fs error (device sda2): ext4_journal_check_start:56: > Detected aborted journal « > > So this was no good idea - but why is setting the usb-storage to "write > back mode" no good? Without more information, such as a usbmon trace, there's no way to tell. But it could be that the bridge does not understand the SYNCRHONIZE CACHE command. Alan Stern -- 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
