From: Alan Stern <stern@rowland.harvard.edu> To: Alexander Kappner <agk@godking.net> Cc: gregkh@linuxfoundation.org, <linux-usb@vger.kernel.org>, <usb-storage@lists.one-eyed-alien.net>, <linux-kernel@vger.kernel.org> Subject: Re: [usb-storage] Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work Date: Thu, 17 May 2018 10:44:30 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.4.44L0.1805171034240.1519-100000@iolanthe.rowland.org> (raw) In-Reply-To: <9c638d96-d2b4-cf19-d7e8-4ef93549bd79@godking.net> On Thu, 17 May 2018, Alexander Kappner wrote: > Hi Alan, > > thanks for reviewing. (This is my first contribution that touches > usb-storage, so please bear with me.) > > > That's kind of weird. Does the drive work under Windows in UAS mode? > > On the Windows 10 VM that I just spun up for testing this, access to the > drive uses "usbstor.inf" (rather than "uaspstor.sys"). So I believe the > answer is no. > > > If so, why are the WRITE(16) commands failing under Linux? > > I don't know exactly why they're failing, but another entry in the > unusual_uas.h shows another SimpleTech device (only with a slightly > different product ID) needing the same UAS quirk (see > https://bugzilla.redhat.com/show_bug.cgi?id=1124119). So my guess is those > drives are just buggy. Okay, that's quite possible. > > That doesn't quite make sense. Since you prevent the uas driver from > > binding to this device, it will end up using usb-storage no matter how > > the kernel was built. Therefore the second quirk flag has to go into > > unusual_devs.h no matter what. > > Yes that's what I was trying to get at. So even though the UAS flag would > conceptually belong into unusual_uas, I'm putting both into unusual_devs to > avoid having to create two separate entries for the same device. > > > You don't describe the second quirk flag at all. Are you sure it is > > needed? > > Yes. Without this flag, the device keeps throwing similar errors on > usb-storage. That's the same result I get on a host that doesn't have UAS > compiled in. Here's a dmesg: > > [ 2.183472] usb 3-1: New USB device found, idVendor=4971, idProduct=8024, bcdDevice=24.03 > [ 2.184285] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > [ 2.184980] usb 3-1: Product: G-DRIVE > [ 2.185447] usb 3-1: Manufacturer: HGST > [ 2.185829] usb 3-1: SerialNumber: AA015010004C > [ 2.195509] usb-storage 3-1:1.0: USB Mass Storage device detected > [ 2.198668] Floppy drive(s): fd0 is 2.88M AMI BIOS > [ 2.202981] scsi host2: usb-storage 3-1:1.0 > ... > [ 3.233085] scsi 2:0:0:0: Direct-Access G-DRIVE 2403 PQ: 0 ANSI: 6 > [ 3.234514] sd 2:0:0:0: Attached scsi generic sg1 type 0 > [ 3.235465] sd 2:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16). > [ 3.236847] sd 2:0:0:0: [sda] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB) > [ 3.237794] sd 2:0:0:0: [sda] 4096-byte physical blocks > [ 3.241255] sd 2:0:0:0: [sda] Write Protect is off > [ 3.242096] sd 2:0:0:0: [sda] Mode Sense: 47 00 10 08 > [ 3.243595] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA > [ 3.257893] sda: sda1 sda9 > [ 3.261402] sd 2:0:0:0: [sda] Attached SCSI disk > ... > [ 92.433428] sd 2:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > [ 92.434759] sd 2:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current] > [ 92.435637] sd 2:0:0:0: [sda] tag#0 Add. Sense: Invalid field in cdb > [ 92.436401] sd 2:0:0:0: [sda] tag#0 CDB: Write(16) 8a 08 00 00 00 00 00 00 00 00 00 00 00 08 00 00 > [ 92.437493] print_req_error: critical target error, dev sda, sector 0 > [ 92.438211] Buffer I/O error on dev sda, logical block 0, lost sync page write > [ 92.516692] EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null) > [ 101.449311] sd 2:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > [ 101.450598] sd 2:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current] > [ 101.451401] sd 2:0:0:0: [sda] tag#0 Add. Sense: Invalid field in cdb > [ 101.452041] sd 2:0:0:0: [sda] tag#0 CDB: Write(16) 8a 08 00 00 00 00 e8 c4 00 18 00 00 00 08 00 00 > [ 101.452906] print_req_error: critical target error, dev sda, sector 3905159192 > [ 101.453593] print_req_error: critical target error, dev sda, sector 3905159192 > [ 101.454889] Aborting journal on device sda-8. > [ 101.457103] sd 2:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > [ 101.457988] sd 2:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current] > [ 101.458637] sd 2:0:0:0: [sda] tag#0 Add. Sense: Invalid field in cdb > [ 101.459250] sd 2:0:0:0: [sda] tag#0 CDB: Write(16) 8a 08 00 00 00 00 e8 c4 00 00 00 00 00 08 00 00 That's bizarre too. Even though the only difference is a MODE SENSE command, the command that actually failed was WRITE(16). > Source code comments describe this as a known problem (scsiglue.c:182): > > /* > * Some devices don't like MODE SENSE with page=0x3f, > * which is the command used for checking if a device > * is write-protected. Now that we tell the sd driver > * to do a 192-byte transfer with this command the > * majority of devices work fine, but a few still can't > * handle it. The sd driver will simply assume those > * devices are write-enabled. > */ > if (us->fflags & US_FL_NO_WP_DETECT) > sdev->skip_ms_page_3f = 1; Yeah, but that comment referred to driver that fail when they receive the MODE SENSE. Have you tried using uas _and_ setting the sdev->skip_ms_page_3f flag? Alan Stern
WARNING: multiple messages have this Message-ID (diff)
From: Alan Stern <stern@rowland.harvard.edu> To: Alexander Kappner <agk@godking.net> Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net, linux-kernel@vger.kernel.org Subject: usb-storage: Add quirks to make G-Technology "G-Drive" work Date: Thu, 17 May 2018 10:44:30 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.4.44L0.1805171034240.1519-100000@iolanthe.rowland.org> (raw) On Thu, 17 May 2018, Alexander Kappner wrote: > Hi Alan, > > thanks for reviewing. (This is my first contribution that touches > usb-storage, so please bear with me.) > > > That's kind of weird. Does the drive work under Windows in UAS mode? > > On the Windows 10 VM that I just spun up for testing this, access to the > drive uses "usbstor.inf" (rather than "uaspstor.sys"). So I believe the > answer is no. > > > If so, why are the WRITE(16) commands failing under Linux? > > I don't know exactly why they're failing, but another entry in the > unusual_uas.h shows another SimpleTech device (only with a slightly > different product ID) needing the same UAS quirk (see > https://bugzilla.redhat.com/show_bug.cgi?id=1124119). So my guess is those > drives are just buggy. Okay, that's quite possible. > > That doesn't quite make sense. Since you prevent the uas driver from > > binding to this device, it will end up using usb-storage no matter how > > the kernel was built. Therefore the second quirk flag has to go into > > unusual_devs.h no matter what. > > Yes that's what I was trying to get at. So even though the UAS flag would > conceptually belong into unusual_uas, I'm putting both into unusual_devs to > avoid having to create two separate entries for the same device. > > > You don't describe the second quirk flag at all. Are you sure it is > > needed? > > Yes. Without this flag, the device keeps throwing similar errors on > usb-storage. That's the same result I get on a host that doesn't have UAS > compiled in. Here's a dmesg: > > [ 2.183472] usb 3-1: New USB device found, idVendor=4971, idProduct=8024, bcdDevice=24.03 > [ 2.184285] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > [ 2.184980] usb 3-1: Product: G-DRIVE > [ 2.185447] usb 3-1: Manufacturer: HGST > [ 2.185829] usb 3-1: SerialNumber: AA015010004C > [ 2.195509] usb-storage 3-1:1.0: USB Mass Storage device detected > [ 2.198668] Floppy drive(s): fd0 is 2.88M AMI BIOS > [ 2.202981] scsi host2: usb-storage 3-1:1.0 > ... > [ 3.233085] scsi 2:0:0:0: Direct-Access G-DRIVE 2403 PQ: 0 ANSI: 6 > [ 3.234514] sd 2:0:0:0: Attached scsi generic sg1 type 0 > [ 3.235465] sd 2:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16). > [ 3.236847] sd 2:0:0:0: [sda] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB) > [ 3.237794] sd 2:0:0:0: [sda] 4096-byte physical blocks > [ 3.241255] sd 2:0:0:0: [sda] Write Protect is off > [ 3.242096] sd 2:0:0:0: [sda] Mode Sense: 47 00 10 08 > [ 3.243595] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA > [ 3.257893] sda: sda1 sda9 > [ 3.261402] sd 2:0:0:0: [sda] Attached SCSI disk > ... > [ 92.433428] sd 2:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > [ 92.434759] sd 2:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current] > [ 92.435637] sd 2:0:0:0: [sda] tag#0 Add. Sense: Invalid field in cdb > [ 92.436401] sd 2:0:0:0: [sda] tag#0 CDB: Write(16) 8a 08 00 00 00 00 00 00 00 00 00 00 00 08 00 00 > [ 92.437493] print_req_error: critical target error, dev sda, sector 0 > [ 92.438211] Buffer I/O error on dev sda, logical block 0, lost sync page write > [ 92.516692] EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null) > [ 101.449311] sd 2:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > [ 101.450598] sd 2:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current] > [ 101.451401] sd 2:0:0:0: [sda] tag#0 Add. Sense: Invalid field in cdb > [ 101.452041] sd 2:0:0:0: [sda] tag#0 CDB: Write(16) 8a 08 00 00 00 00 e8 c4 00 18 00 00 00 08 00 00 > [ 101.452906] print_req_error: critical target error, dev sda, sector 3905159192 > [ 101.453593] print_req_error: critical target error, dev sda, sector 3905159192 > [ 101.454889] Aborting journal on device sda-8. > [ 101.457103] sd 2:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > [ 101.457988] sd 2:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current] > [ 101.458637] sd 2:0:0:0: [sda] tag#0 Add. Sense: Invalid field in cdb > [ 101.459250] sd 2:0:0:0: [sda] tag#0 CDB: Write(16) 8a 08 00 00 00 00 e8 c4 00 00 00 00 00 08 00 00 That's bizarre too. Even though the only difference is a MODE SENSE command, the command that actually failed was WRITE(16). > Source code comments describe this as a known problem (scsiglue.c:182): > > /* > * Some devices don't like MODE SENSE with page=0x3f, > * which is the command used for checking if a device > * is write-protected. Now that we tell the sd driver > * to do a 192-byte transfer with this command the > * majority of devices work fine, but a few still can't > * handle it. The sd driver will simply assume those > * devices are write-enabled. > */ > if (us->fflags & US_FL_NO_WP_DETECT) > sdev->skip_ms_page_3f = 1; Yeah, but that comment referred to driver that fail when they receive the MODE SENSE. Have you tried using uas _and_ setting the sdev->skip_ms_page_3f flag? Alan Stern --- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-05-17 14:44 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-16 20:01 [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work Alexander Kappner 2018-05-16 20:01 ` Alexander Kappner 2018-05-16 20:55 ` [PATCH] " Alan Stern 2018-05-16 20:55 ` Alan Stern 2018-05-17 8:15 ` [PATCH] " Alexander Kappner 2018-05-17 8:15 ` Alexander Kappner 2018-05-17 12:58 ` [PATCH] " Oliver Neukum 2018-05-17 12:58 ` Oliver Neukum 2018-05-17 18:38 ` [PATCH] " Alexander Kappner 2018-05-17 18:38 ` Alexander Kappner 2018-05-17 19:13 ` [PATCH] " Alan Stern 2018-05-17 19:13 ` Alan Stern 2018-05-18 17:51 ` [PATCH] " Alexander Kappner 2018-05-18 17:51 ` Alexander Kappner 2018-05-18 20:35 ` [PATCH] " Alan Stern 2018-05-18 20:35 ` Alan Stern 2018-05-19 4:50 ` [PATCH v2 0/2] " Alexander Kappner 2018-05-19 4:50 ` Alexander Kappner 2018-05-19 4:50 ` [PATCH v2 1/2] usb-storage: Add support for FL_ALWAYS_SYNC flag in the UAS driver Alexander Kappner 2018-05-19 4:50 ` [v2,1/2,usb-storage] " Alexander Kappner 2018-05-22 8:58 ` [PATCH v2 1/2] [usb-storage] " Oliver Neukum 2018-05-22 8:58 ` [v2,1/2,usb-storage] " Oliver Neukum 2018-05-19 4:50 ` [PATCH v2 2/2] usb-storage: Add compatibility quirk flags for G-Technologies G-Drive Alexander Kappner 2018-05-19 4:50 ` [v2,2/2,usb-storage] " Alexander Kappner 2018-05-21 17:47 ` [PATCH v2 0/2] Re: usb-storage: Add quirks to make G-Technology "G-Drive" work Alan Stern 2018-05-21 17:47 ` Alan Stern 2018-05-22 8:57 ` [usb-storage] Re: [PATCH v2 0/2] " Oliver Neukum 2018-05-22 8:57 ` Oliver Neukum 2018-05-17 14:44 ` Alan Stern [this message] 2018-05-17 14:44 ` Alan Stern
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Pine.LNX.4.44L0.1805171034240.1519-100000@iolanthe.rowland.org \ --to=stern@rowland.harvard.edu \ --cc=agk@godking.net \ --cc=gregkh@linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=usb-storage@lists.one-eyed-alien.net \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.