Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Thu, Mar 15, 2018 at 04:46:30PM +0100, Kashyap Chamarthy wrote: > (Sorry, accidentally dropped the lists. Adding it back & re-posting my > off-list response.) (Now add the missing linux-usb@vger.kernel.org list for real. Not trimming the full e-mail intentionally as I missed to Cc 'linux-usb'.) > On Thu, Mar 15, 2018 at 04:05:53PM +0100, Kashyap Chamarthy wrote: > > On Thu, Mar 15, 2018 at 03:33:46PM +0100, Douglas Gilbert wrote: > > > On 2018-03-15 02:44 PM, Douglas Gilbert wrote: > > > > On 2018-03-15 01:45 PM, Martin K. Petersen wrote: > > > > > > > > > > Kashyap, > > > > > > > > > > > /me naively wonders if it has anything to do with accessing it via > > > > > > Linux. > > > > > > > > > > I'm guessing that the drive doesn't actually support SCSI UNMAP. I > > > > > have > > > > > a T3 that reports all the right things in the bl/lbpv VPD pages but > > > > > also > > > > > has lbpme set to 0. > > > > > > > > > > Interestingly enough, my T3 does appear to be a regular SATA drive > > > > > behind a USB bridge. Have you tried to issue a DSM TRIM command via > > > > > ATA > > > > > passthrough? > > > > > > > > hdparm can do that. Look for "EXCEPTIONALLY DANGEROUS. DO NOT USE THIS > > > > OPTION!!" in its manpage :-) > > > > Hehe, near as I see, that's dangerous only if you have data on the disk. > > > > This is an empty SSD that I haven't put any data in it, I should remind. > > :-) In that case, I'll assume it is "safe" to tinker with the above. > > > > > IOWs, using Mark Lord's example: > > >hdparm --trim-sector-ranges 1000:4 /dev/sdz > > > > > > That will attempt to trim lba 1000, 1001, 1002 and 1003 on /dev/sdz > > > > Thanks; I should first educate myself more on this before I tinker with > > the above. One Ubuntu wiki page claims: "To wipe out contents of an SSD, > > SATA secure erase is the way to go", Never mind about "secure erase", even trying to set password via `hdparm' for this T5 SSD (still connected via 'Thunderbolt'): $> hdparm --user-master u --security-set-pass $SECRET /dev/sdc Fails with the unactionable & useless error: "SECURITY_SET_PASS: Input/output error" > > and '--trim-sector-ranges' is only > > "experimental and for benchmarking purpose". > > > > Just to recap: My goal is to clean (insofar as possible) the SSD of all > > and any / all pre-loaded programs & re-claim space. > > > > --- > > > > Related: The ATA Secure Erase wiki page claims[*] if you do it (Secure > > Erase) via USB interface, you might brick the SSD. I'm using the > > 'Thunderbolt' interface, and the said wiki page doesn't say anything > > useful about it. > > > > > > [*] https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Thu, Mar 15, 2018 at 08:45:05AM -0400, Martin K. Petersen wrote:
>
> Kashyap,
>
> > /me naively wonders if it has anything to do with accessing it via
> > Linux.
>
> I'm guessing that the drive doesn't actually support SCSI UNMAP. I have
> a T3 that reports all the right things in the bl/lbpv VPD pages but also
> has lbpme set to 0.
>
> Interestingly enough, my T3 does appear to be a regular SATA drive
> behind a USB bridge.
I see. So I ran `hdparm` on my SSD (still attached via the
'Thunderbolt' port), and it does show TRIM support:
$> hdparm -I /dev/sdc | grep TRIM
*Data Set Management TRIM supported (limit 8 blocks)
(Full output attached to this e-mail as a text file.)
> Have you tried to issue a DSM TRIM command via ATA
> passthrough?
I'm afraid I don't know how to do that (my SCSI / (S)ATA knowledge is
less than zero). If there's a page where I can educate myself about how
to send the TRIM command via ATA passthrough I'd appreciate it. (Aside:
>From my looking up, I don't see any ATA equivalent of SCSI's
'sg3_utils'; wonder if there is any.)
Thanks for the response.
--
/kashyap
$> hdparm -I /dev/sdc
/dev/sdc:
ATA device, with non-removable media
Model Number: Samsung Portable SSD T5
Serial Number: S3UNNV0K102165T
Firmware Revision: MVT41P1Q
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions,
SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Used: unknown (minor revision code 0x0039)
Supported: 9 8 7 6 5
Likely used: 9
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors:16514064
LBAuser addressable sectors: 268435455
LBA48 user addressable sectors: 976773168
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 476940 MBytes
device size with M = 1000*1000: 500107 MBytes (500 GB)
cache/buffer size = unknown
Form Factor: unknown (0x0006]
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 1 Current = 1
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
*SMART feature set
*Power Management feature set
*Write cache
*Look-ahead
*WRITE_BUFFER command
*READ_BUFFER command
*NOP cmd
*DOWNLOAD_MICROCODE
SET_MAX security extension
*48-bit Address feature set
*Mandatory FLUSH_CACHE
*FLUSH_CACHE_EXT
*SMART error logging
*SMART self-test
*General Purpose Logging feature set
*WRITE_{DMA|MULTIPLE}_FUA_EXT
*64-bit World wide name
Write-Read-Verify feature set
*WRITE_UNCORRECTABLE_EXT command
*{READ,WRITE}_DMA_EXT_GPL commands
*Segmented DOWNLOAD_MICROCODE
*Gen1 signaling speed (1.5Gb/s)
*Gen2 signaling speed (3.0Gb/s)
*Gen3 signaling speed (6.0Gb/s)
*Native Command Queueing (NCQ)
*Phy event counters
*READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
DMA Setup Auto-Activate optimization
*Device-initiated interface power management
*Software settings preservation
*reserved 69[4]
*DOWNLOAD MICROCODE DMA command
*SET MAX SETPASSWORD/UNLOCK DMA commands
*WRITE BUFFER DMA command
*READ BUFFER DMA command
*Data Set Management TRIM supported (limit 8 blocks)
Logical Unit WWN Device Identifier: 5002538d
NAA : 5
IEEE OUI: 002538
Unique ID : d
Checksum: correct
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On 2018-03-15 01:45 PM, Martin K. Petersen wrote: Kashyap, /me naively wonders if it has anything to do with accessing it via Linux. I'm guessing that the drive doesn't actually support SCSI UNMAP. I have a T3 that reports all the right things in the bl/lbpv VPD pages but also has lbpme set to 0. Interestingly enough, my T3 does appear to be a regular SATA drive behind a USB bridge. Have you tried to issue a DSM TRIM command via ATA passthrough? hdparm can do that. Look for "EXCEPTIONALLY DANGEROUS. DO NOT USE THIS OPTION!!" in its manpage :-) Doug Gilbert -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
Kashyap, > /me naively wonders if it has anything to do with accessing it via > Linux. I'm guessing that the drive doesn't actually support SCSI UNMAP. I have a T3 that reports all the right things in the bl/lbpv VPD pages but also has lbpme set to 0. Interestingly enough, my T3 does appear to be a regular SATA drive behind a USB bridge. Have you tried to issue a DSM TRIM command via ATA passthrough? -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Thu, Mar 15, 2018 at 12:19:11PM +0100, Douglas Gilbert wrote: > On 2018-03-15 10:47 AM, Kashyap Chamarthy wrote: > > On Wed, Mar 14, 2018 at 11:43:55PM -0400, Martin K. Petersen wrote: > > > > > > Kashyap, > > > > Hi Martin, > > > > > > Sorry, I didn't give you complete information — with the previous > > > > `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB > > > > "A Cable". > > > > > > > > Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop > > > > (Lenovo T470s), it _does_ show "UAS". Refer the arrow below: > > > > > > Do you get different sg_readcap -l output when accessing it in UAS mode? > > > I.e. is lbpme=1? > > > > Afraid, no :-( I was excited for a brief moment, but it's the same as > > earlier. The result with the SSD via 'Thunderbolt': > > > > $> sudo sg_readcap -l /dev/sdc > > Read Capacity results: > > Protection: prot_en=0, p_type=0, p_i_exponent=0 > > Logical block provisioning: lbpme=0, lbprz=0 > > Last logical block address=976773167 (0x3a38602f), Number of > > logical blocks=976773168 > > Logical block length=512 bytes > > Logical blocks per physical block exponent=0 > > Lowest aligned logical block address=0 > > Hence: > > Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB > > > > > > /me naively wonders if it has anything to do with accessing it via > > Linux. > > You can also run 'sg_readcap -l' on a Windows machine to test your theory. > Do 'sg_scan.exe' first to see where (and if) the 'physical disk' is, then > you would do something like: > sg_readcap -l pd2 > > There is no IOS port of sg3_utils. > > I am not aware of any SCSI command *** (and haven't seen any ATA or NVMe > commands) that tell a storage device something like: "BTW I'm a Linux > machine running Ubuntu 17.10 on hardware". > > It is possible that a storage device might recognize an OS by the pattern > of commands it sends, especially in the device discovery mode. > > So basically your suggestion is a long shot. There might be a "secret" > setting in a vendor specific command that another OS is aware of. > For example, according to the 'net this command: >sg_raw /dev/sr0 EA 00 00 00 00 00 01 > allows owners of Apple USB Superdrives to use them on other OSes. I see, thanks for the explanation and the specific useful commands. I'll try to get hold of a friend's Windows computer, as I don't have one with me. But your "long shot" comment adjusted my expectations to not hold my breath. > *** there are transport_ids used by PERSISTENT RESERVATION commands to > differentiate one machine from another. But they convey about as > much information as a random number does. Also that applies to a > multi-initiator, single target model which isn't the case when we > are talking about USB/Thunderbolt attachment. > -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On 2018-03-15 10:47 AM, Kashyap Chamarthy wrote: On Wed, Mar 14, 2018 at 11:43:55PM -0400, Martin K. Petersen wrote: Kashyap, Hi Martin, Sorry, I didn't give you complete information — with the previous `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB "A Cable". Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop (Lenovo T470s), it _does_ show "UAS". Refer the arrow below: Do you get different sg_readcap -l output when accessing it in UAS mode? I.e. is lbpme=1? Afraid, no :-( I was excited for a brief moment, but it's the same as earlier. The result with the SSD via 'Thunderbolt': $> sudo sg_readcap -l /dev/sdc Read Capacity results: Protection: prot_en=0, p_type=0, p_i_exponent=0 Logical block provisioning: lbpme=0, lbprz=0 Last logical block address=976773167 (0x3a38602f), Number of logical blocks=976773168 Logical block length=512 bytes Logical blocks per physical block exponent=0 Lowest aligned logical block address=0 Hence: Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB /me naively wonders if it has anything to do with accessing it via Linux. You can also run 'sg_readcap -l' on a Windows machine to test your theory. Do 'sg_scan.exe' first to see where (and if) the 'physical disk' is, then you would do something like: sg_readcap -l pd2 There is no IOS port of sg3_utils. I am not aware of any SCSI command *** (and haven't seen any ATA or NVMe commands) that tell a storage device something like: "BTW I'm a Linux machine running Ubuntu 17.10 on hardware". It is possible that a storage device might recognize an OS by the pattern of commands it sends, especially in the device discovery mode. So basically your suggestion is a long shot. There might be a "secret" setting in a vendor specific command that another OS is aware of. For example, according to the 'net this command: sg_raw /dev/sr0 EA 00 00 00 00 00 01 allows owners of Apple USB Superdrives to use them on other OSes. Doug Gilbert *** there are transport_ids used by PERSISTENT RESERVATION commands to differentiate one machine from another. But they convey about as much information as a random number does. Also that applies to a multi-initiator, single target model which isn't the case when we are talking about USB/Thunderbolt attachment. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Wed, Mar 14, 2018 at 11:43:55PM -0400, Martin K. Petersen wrote: > > Kashyap, Hi Martin, > > Sorry, I didn't give you complete information — with the previous > > `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB > > "A Cable". > > > > Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop > > (Lenovo T470s), it _does_ show "UAS". Refer the arrow below: > > Do you get different sg_readcap -l output when accessing it in UAS mode? > I.e. is lbpme=1? Afraid, no :-( I was excited for a brief moment, but it's the same as earlier. The result with the SSD via 'Thunderbolt': $> sudo sg_readcap -l /dev/sdc Read Capacity results: Protection: prot_en=0, p_type=0, p_i_exponent=0 Logical block provisioning: lbpme=0, lbprz=0 Last logical block address=976773167 (0x3a38602f), Number of logical blocks=976773168 Logical block length=512 bytes Logical blocks per physical block exponent=0 Lowest aligned logical block address=0 Hence: Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB /me naively wonders if it has anything to do with accessing it via Linux. -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
Kashyap, > Sorry, I didn't give you complete information — with the previous > `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB > "A Cable". > > Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop > (Lenovo T470s), it _does_ show "UAS". Refer the arrow below: Do you get different sg_readcap -l output when accessing it in UAS mode? I.e. is lbpme=1? -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Wed, Mar 14, 2018 at 12:29:50PM +0100, Oliver Neukum wrote: > Am Mittwoch, den 14.03.2018, 11:22 +0100 schrieb Kashyap Chamarthy: > > I see. So I ran `dmesg -w`, as I attached the disk & see the following: > > UAS and no quirk for your device. It looks like it indeed just does > not support TRIM. Sorry, I didn't give you complete information — with the previous `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB "A Cable". Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop (Lenovo T470s), it _does_ show "UAS". Refer the arrow below: [...] [131839.680706] usb 4-1: new SuperSpeedPlus USB device number 2 using xhci_hcd [131839.698814] usb 4-1: New USB device found, idVendor=04e8, idProduct=61f5 [131839.698817] usb 4-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [131839.698818] usb 4-1: Product: Portable SSD T5 [131839.698819] usb 4-1: Manufacturer: Samsung [131839.698820] usb 4-1: SerialNumber: 1234567A7AD6 [131839.701232] scsi host2: uas <--- [131839.701631] scsi 2:0:0:0: Direct-Access Samsung Portable SSD T5 0 PQ: 0 ANSI: 6 [131839.703470] sd 2:0:0:0: Attached scsi generic sg1 type 0 [131839.705486] sd 2:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/466 GiB) [131839.705895] sd 2:0:0:0: [sdc] Write Protect is off [131839.705900] sd 2:0:0:0: [sdc] Mode Sense: 43 00 00 00 [131839.706146] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [131839.709656] sd 2:0:0:0: [sdc] Attached SCSI disk [131839.927167] EXT4-fs (sdc): recovery complete [131839.927175] EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: (null) [...] -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
Am Mittwoch, den 14.03.2018, 11:22 +0100 schrieb Kashyap Chamarthy: > I see. So I ran `dmesg -w`, as I attached the disk & see the following: UAS and no quirk for your device. It looks like it indeed just does not support TRIM. Sorry Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Wed, Mar 14, 2018 at 10:52:36AM +0100, Oliver Neukum wrote: > Am Dienstag, den 13.03.2018, 12:50 +0100 schrieb Kashyap Chamarthy: > > Earlier, I didn't know which list to email, so I wrote to Martin K. > > Petersen (who pointed me to the lists when I asked where I can post > > publicly), and he made this observation on the above quoted text: > > > > "Linux can run USB block devices in either legacy or UAS mode. > > Chances are this device is being driven in usb-storage mode. We > > usually have quirks based on the model strings that decide whether > > to use one or the other." > > Neither driver would edit commands or result to that degree. > Whether UAS or storage are used dmesg will tell you. I see. So I ran `dmesg -w`, as I attached the disk & see the following: --- [...] [474027.606253] sd 3:0:0:0: Attached scsi generic sg1 type 0 [474027.607751] sd 3:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB) [474027.607857] sd 3:0:0:0: [sdb] Write Protect is off [474027.607858] sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00 [474027.608019] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [474027.612347] sd 3:0:0:0: [sdb] Attached SCSI disk [474027.863216] EXT4-fs (sdb): recovery complete [474027.866955] EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: (null) [474038.146095] usb 3-1: USB disconnect, device number 4 [474038.147543] print_req_error: I/O error, dev sdb, sector 0 [474038.155354] sd 3:0:0:0: [sdb] Synchronizing SCSI cache [474038.175128] print_req_error: I/O error, dev sdb, sector 0 [474038.179130] print_req_error: I/O error, dev sdb, sector 0 [474038.183135] print_req_error: I/O error, dev sdb, sector 0 [474038.183156] print_req_error: I/O error, dev sdb, sector 0 [474038.267134] sd 3:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [474076.230377] usb 3-1: new SuperSpeed USB device number 5 using xhci_hcd [474076.248589] usb 3-1: New USB device found, idVendor=04e8, idProduct=61f5 [474076.248593] usb 3-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [474076.248596] usb 3-1: Product: Portable SSD T5 [474076.248598] usb 3-1: Manufacturer: Samsung [474076.248600] usb 3-1: SerialNumber: 1234567A7AD6 [474076.254990] scsi host3: uas [474076.255605] scsi 3:0:0:0: Direct-Access Samsung Portable SSD T5 0 PQ: 0 ANSI: 6 [474076.263707] sd 3:0:0:0: Attached scsi generic sg1 type 0 [474076.264140] sd 3:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB) [474076.264220] sd 3:0:0:0: [sdb] Write Protect is off [474076.264222] sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00 [474076.264546] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [474076.267595] sd 3:0:0:0: [sdb] Attached SCSI disk [474076.463067] EXT4-fs (sdb): recovery complete [474076.463070] EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: (null) --- -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
Am Dienstag, den 13.03.2018, 12:50 +0100 schrieb Kashyap Chamarthy: > Earlier, I didn't know which list to email, so I wrote to Martin K. > Petersen (who pointed me to the lists when I asked where I can post > publicly), and he made this observation on the above quoted text: > > "Linux can run USB block devices in either legacy or UAS mode. > Chances are this device is being driven in usb-storage mode. We > usually have quirks based on the model strings that decide whether > to use one or the other." Neither driver would edit commands or result to that degree. Whether UAS or storage are used dmesg will tell you. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Tue, Mar 13, 2018 at 12:42:47PM +0100, Kashyap Chamarthy wrote: > [Cross-posted to 'linux-scsi' and 'linux-usb' lists; please keep me > Cced, as I'm not subscribed to either of them.) [...] > I was suggested to return this SSD. But the Interweb[%] claims Samsung > T5 *does* have 'TRIM' (i.e. SCSI 'UNMAP') support via UASP. Earlier, I didn't know which list to email, so I wrote to Martin K. Petersen (who pointed me to the lists when I asked where I can post publicly), and he made this observation on the above quoted text: "Linux can run USB block devices in either legacy or UAS mode. Chances are this device is being driven in usb-storage mode. We usually have quirks based on the model strings that decide whether to use one or the other." [...] -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
