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
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: at91sam9x5: USB mass storage gadget problems
On 15-11-12 05:18 PM, Alan Stern wrote:
On Thu, 12 Nov 2015, Douglas Gilbert wrote:
Yes, the X201 has USB 2.0 host ports. It is running a stock Ubuntu
15.10 kernel: 4.2.0-18-generic and the log indicates that the
ehci_pci driver is being used. Part of the X201's syslog is
attached in which a driver complains about the invalid maxpacket
values of 64.
So its seems that the ehci drivers as used on the X201 can work
around the invalid maxpacket value (64) while the xhci drivers
used by the X240 (due to the USB 3.0 host ports) get tripped up.
Yes, I think that's right. The restriction that high speed bulk
endpoints must have a maxpacket size of 512 is enforced by the xHCI
hardware but not by the EHCI hardware; this explains why ehci-hcd is
able to work around such violations while xhci-hcd isn't.
Still looking at drivers/usb/gadget/udc/atmel_usba_udc.c which
has lots of changes between lk 3.19.0-rc4 and 4.0.0-rc4 . The
maxpacket value seems (to me) to be related to the fifo-size
in the gadget section of this dts include file:
arch/arm/boot/dts/at91sam9x5.dtsi
which has 1024 for ep1 through ep5 and 64 for ep0.
The assignment of endpoints isn't done in the UDC driver; it is carried
out by epautoconf.c in drivers/usb/gadget/. So you may need to expand
your bisection search beyond the single UDC driver source file.
Have you tried enabling debugging in the gadget drivers and checking
out the kernel log on the gadget?
So it looks like 1.5 bugs:
- one in atmel's udc driver for the at91sam9x5 family, and
- the inconsistency between the ehci driver working around
invalid maxpacket values and the xhci driver behaving
badly (lots of bus resets and a badly made SCSI storage
device [e.g. INQUIRY works but READ(10) fails]).
The first is clearly a bug, although at the moment we can't be sure
where. The second is an unavoidable hardware restriction, not a bug.
Anyway, if you fix the first problem then the second won't be an issue.
Found the udc driver bug. A shadow register value was introduced
around lk 4.0 for the Atmel 9x5/sama5d3 UDPHS driver
(atmel_usba_udc.c) for the interrupt status register. It used the
interrupt enable register (last written) value as a mask. At least
for the at91sam9g25 that works apart from the SPEED bit (bit 0)
which is only present in the interrupt status register.
It seems that USB negotiates the link speed during resets and at
the G25 end, even though the hardware had negotiated a "high
speed" link with the host, the logic in usba_udc_irq() deduced it
was only a full speed link (due to the above bug). Thereafter
there was confusion which the ehci_hcd host driver could handle
but the xhci_pci driver could not. In the xhci_pci case there
were multiple high speed link resets in the host log, matched
at the device (G25) end with a similar number of reported _full_
speed resets.
The author of the changes to the code that caused this is
cc-ed on this post. He might like to consider the attached
patch which fixed my problem. However the shadow mask register
technique might have other subtle issues that I'm not
qualified to address.
If I don't hear anything on this issue then I can produce
a patch. Does it go through the ARM or USB (or both) trees?
If my patch is sufficient, then perhaps it should also be
issued against the lk 4.0, 4.1, 4.2 and 4.3 kernels that are
still actively maintained.
Doug Gilbert
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index f0f2b06..f92f5af 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1633,7 +1633,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
spin_lock(>lock);
int_enb = usba_int_enb_get(udc);
- status = usba_readl(udc, INT_STA) & int_enb;
+ status = usba_readl(udc, INT_STA) & (int_enb | USBA_HIGH_SPEED);
DBG(DBG_INT, "irq, status=%#08x\n", status);
if (status & USBA_DET_SUSPEND) {
[PATCH] Atmel USB High speed device port, speed fix
Following changes that appeared in lk 4.0.0, the gadget udc driver for
some ARM based Atmel SoCs (e.g. at91sam9x5 and sama5d3 families)
incorrectly deduced full-speed USB link speed even when the hardware
had negotiated a high-speed link. The fix is to make sure that the
UDPHS Interrupt Enable Register value does not mask the SPEED bit
in the Interrupt Status Register.
For a mass storage gadget this problem lead to failures when the host
had a USB 3 port with the xhci_hcd driver. If the host was a USB 2
port using the ehci_hcd driver then the mass storage gadget worked
(but probably at a lower speed than it should have).
Signed-of-by: Douglas Gilbert <dgilb...@interlog.com>
Cc: <sta...@vger.kernel.org> #4.0+
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index f0f2b06..f92f5af 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1633,7 +1633,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
spin_lock(>lock);
int_enb = usba_int_enb_get(udc);
- status = usba_readl(udc, INT_STA) & int_enb;
+ status = usba_readl(udc, INT_STA) & (int_enb | USBA_HIGH_SPEED);
DBG(DBG_INT, "irq, status=%#08x\n", status);
if (status & USBA_DET_SUSPEND) {
Re: at91sam9x5: USB mass storage gadget problems
On 15-11-12 02:37 PM, Alan Stern wrote: On Thu, 12 Nov 2015, Felipe Balbi wrote: Also, my problem seems to be sensitive to the host port being USB 3.0 since I have an older Lenovo X201 with USB 2.0 ports that does _not_ exhibit this problem. IOW when I connect my Arietta G25 mass storage gadget to the X201, it works properly for all G25 kernels that I have tried. I'd blame UDC driver. We have several other UDCs working with the same configuration. Sounds reasonable to me. But that doesn't explain why it works okay with the older Lenovo X201 laptop. it seems like only x240 is running > 4.0. What is x201 running ? Could be older, buggy xhci driver. Or maybe it uses EHCI, since Douglas described it as having USB 2.0 ports. Yes, the X201 has USB 2.0 host ports. It is running a stock Ubuntu 15.10 kernel: 4.2.0-18-generic and the log indicates that the ehci_pci driver is being used. Part of the X201's syslog is attached in which a driver complains about the invalid maxpacket values of 64. So its seems that the ehci drivers as used on the X201 can work around the invalid maxpacket value (64) while the xhci drivers used by the X240 (due to the USB 3.0 host ports) get tripped up. Still looking at drivers/usb/gadget/udc/atmel_usba_udc.c which has lots of changes between lk 3.19.0-rc4 and 4.0.0-rc4 . The maxpacket value seems (to me) to be related to the fifo-size in the gadget section of this dts include file: arch/arm/boot/dts/at91sam9x5.dtsi which has 1024 for ep1 through ep5 and 64 for ep0. So it looks like 1.5 bugs: - one in atmel's udc driver for the at91sam9x5 family, and - the inconsistency between the ehci driver working around invalid maxpacket values and the xhci driver behaving badly (lots of bus resets and a badly made SCSI storage device [e.g. INQUIRY works but READ(10) fails]). Doug Gilbert usb 1-1.2: new high-speed USB device number 6 using ehci-pci usb 1-1.2: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 64 usb 1-1.2: config 1 interface 0 altsetting 0 bulk endpoint 0x2 has invalid maxpacket 64 usb 1-1.2: New USB device found, idVendor=0525, idProduct=a4a5 usb 1-1.2: New USB device strings: Mfr=3, Product=4, SerialNumber=0 usb 1-1.2: Product: Mass Storage Gadget usb 1-1.2: Manufacturer: Linux 4.0.0-rc4-armv5-r2 with atmel_usba_udc link mtp-probe: checking bus 1, device 6: "/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2" link mtp-probe: bus: 1, device: 6 was not an MTP device usb-storage 1-1.2:1.0: USB Mass Storage device detected usb-storage 1-1.2:1.0: Quirks match for vid 0525 pid a4a5: 1 scsi host6: usb-storage 1-1.2:1.0
Re: [PATCH 1/5] USB: ehci-atmel: rework clk handling
On 15-03-18 08:28 AM, Greg Kroah-Hartman wrote: On Wed, Mar 18, 2015 at 12:16:22PM +0100, Nicolas Ferre wrote: Le 17/03/2015 20:01, Alan Stern a écrit : On Tue, 17 Mar 2015, Boris Brezillon wrote: The EHCI IP only needs the UTMI/UPLL (uclk) and the peripheral (iclk) clocks to work properly. Remove the useless system clock (fclk). Avoid calling set_rate on the fixed rate UTMI/IPLL clock and remove useless IS_ENABLED(CONFIG_COMMON_CLK) tests (all at91 platforms have been moved to the CCF). This patch also fixes a bug introduced by 3440ef1 (ARM: at91/dt: fix USB high-speed clock to select UTMI), which was leaving the usb clock uninitialized and preventing the OHCI driver from setting the usb clock rate to 48MHz. This bug was caused by several things: 1/ usb clock drivers set the CLK_SET_RATE_GATE flag, which means the rate cannot be changed once the clock is prepared 2/ The EHCI driver was retrieving and preparing/enabling the uhpck clock which was in turn preparing its parent clock (the usb clock), thus preventing any rate change because of 1/ Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Alan Stern st...@rowland.harvard.edu Acked-by: Nicolas Ferre nicolas.fe...@atmel.com and: Fixes: 3440ef169100 (ARM: at91/dt: fix USB high-speed clock to select UTMI) Alan, Greg, Can you please take this patch (only this patch 1/5 of the series) as a fix for the 4.0-rc? It would solve the issue that we see on at91sam9x5/at91sam9n12. I'll take care of the rest of the series for 4.1. If you want me to take it of to re-send the patch, tell me. I'll queue it up now, thanks. You can take the rest of the series :) Hi, I reported this error to Nicolas based on tests with lk 4.0-rc4. With the same USB WiFi dongle and platform this patch fixes my problem. Tested-by: Douglas Gilbert dgilb...@interlog.com -- 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: Issues with commit 34b48db6 (block: remove artifical max_hw_sectors cap)
On 14-12-30 10:34 AM, Alan Stern wrote: On Tue, 30 Dec 2014, Christoph Hellwig wrote: The only limits usb-storage imposes on max_sectors are those needed to work around bugs in the devices' USB bridges. (Okay, there's also something for tape drive devices, but it probably doesn't belong in usb-storage -- it should be handled by the SCSI tape driver.) If the ATA layer needs to set a limit on max_sectors, why doesn't it simply go ahead and do so? Because the ATA layer doesn't control the device, the bridge does. And it seems like it doesn't communicate the maximum transfer size properly. _Is_ there any way to communicate the maximum transfer size? I'm not aware of any SCSI command for it. It isn't part of the USB mass-storage spec. In SCSI, the VPD page 0xb0 (Block limits) has a Maximum transfer length field (32 bits long). Its units are logical blocks. Useful if 0 as 0 means unreported. USB to SATA bridges should comply with SAT. However SAT and SAT-2 don't even mention that VPD page. SAT-3 and SAT-4 mention that page but have unspecified next to that field. Basically useless. IMO about the best SATL is in the MPT SAS-2 and SAS-3 HBAs and here is that page for a SAS expander attached SATA disk: # sg_vpd -p bl /dev/sg3 Block limits VPD page (SBC): Write same non-zero (WSNZ): 0 Maximum compare and write length: 0 blocks Optimal transfer length granularity: 0 blocks Maximum transfer length: 0 blocks Optimal transfer length: 0 blocks Maximum prefetch length: 0 blocks Maximum unmap LBA count: 0 Maximum unmap block descriptor count: 0 Optimal unmap granularity: 0 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0x0 blocks Maximum atomic transfer length: 0 Atomic alignment: 0 Atomic transfer length granularity: 0 Maximum atomic transfer length with atomic boundary: 0 Maximum atomic boundary size: 0 Not sure why LSI/Avago even bothered even implementing that page ... Doug Gilbert BTW here is the output of that page from a SAS SSD: # sg_vpd -p bl /dev/sg5 Block limits VPD page (SBC): Write same non-zero (WSNZ): 0 Maximum compare and write length: 0 blocks Optimal transfer length granularity: 8 blocks Maximum transfer length: 65535 blocks Optimal transfer length: 0 blocks Maximum prefetch length: 0 blocks Maximum unmap LBA count: 393216 Maximum unmap block descriptor count: 512 Optimal unmap granularity: 8 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0x0 blocks Maximum atomic transfer length: 0 Atomic alignment: 0 Atomic transfer length granularity: 0 Maximum atomic transfer length with atomic boundary: 0 Maximum atomic boundary size: 0 -- 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: Updated linux uas driver, please test
On 14-09-10 08:13 AM, Hans de Goede wrote: Hi All, I'm mailing all of you because you've reported various problems with the new uas support in kernel 3.16 and later. I've been working on making the uas driver more resilient to errors, as well as improved logging so we can easier figure out the cause of errors. I would like to ask you all to test a standalone version of the new uas driver with the devices you've been having trouble with before, and report the results to me. Testing instructions: 1) Remove any usb-storage.quirks= setting from the kernel commandline, and remove any /etc/modprobe.conf* files doing the same, boot your machine without the uas device attached. 2) Make sure your machine is set up for building kernel modules, usually this means installing kernel-devel and gcc packages, see your distributions documentation for more info 3) Download all files from here: https://fedorapeople.org/~jwrdegoede/uas/ And put them all in a single directory, named e.g. uas 4) Start a terminal, cd into the uas directory 5) Run the following commands: make sudo rmmod uas sudo insmod ./uas.ko 6) Connect your uas device 7) Wait for the disk to show up (wait circa 1 minute max), then do: dmesg dmesg.log lsusb -v lsusb.log 8) Test the uas disk Once done please send me a mail, in this mail please 1) Describe how the disk worked, did it show up in a reasonable time, and did it work? 2) Attach dmesg.log and lsusb.log Could you give some sort of indication of the dd throughput time (on READs) with UAS given a recent SATA SSD that can source data faster than 300 MB/sec (say)? My ASM1051 based dock under W7 got an underwhelming maximum of 42 MB/sec with such a SATA SSD. And I saw enough stupid meta-data from SCSI commands to suggest that product should be binned. 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: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)
On 14-08-30 05:15 PM, Alan Stern wrote: On Fri, 29 Aug 2014, Matthew Dharm wrote: Is there an 'easy' way to override the detected size of a storage device from userspace? If we had that, someone could write a helper application which looked for this particular fubar and try to Do The Right Thing(tm), or at least offer the user some options. You mean, force a Media Change event and override the capacity reported by the hardware? I'm not aware of any API for doing that, although it probably wouldn't be too hard to add one. How would the user know what value to put in for the capacity? Unless the drive had been hooked up to a different computer and the user manually noted the correct capacity and typed it in, it would have to be guesswork. Might another possibility be using the SAT layer to issue the appropriate ATA command via the SCSI ATA PASS-THROUGH (12 or 16) command to find out the disk's size. This might be a possible strategy if READ CAPACITY(10) yields 0x for the last sector's LBA and the follow-up READ CAPACITY(16) fails or yields a truncated value. Doug Gilbert BTW Been looking at a USB-to-SATA adapter that uses the UAS(P) transport. I thought nothing could have worse SCSI compliance than USB mass storage devices. I was wrong ... -- 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: Buffer I/O error after s2ram with usb storage
On 14-08-27 04:40 AM, Matthieu CASTET wrote: Ping I have got also a problem with a usb sdcard reader (without power cut during suspend) [ 1073.606668] PM: Entering mem sleep [ 1073.606742] Suspending console(s) (use no_console_suspend to debug) [ 1073.607146] sd 1:0:0:0: [sda] Synchronizing SCSI cache [ 1073.639076] sd 1:0:0:0: [sda] Stopping disk [ 1074.186688] PM: suspend of devices complete after 580.127 msecs [...] [ 1075.265183] PM: resume of devices complete after 615.990 msecs [ 1075.265627] PM: Finishing wakeup. [ 1075.265630] Restarting tasks ... [...] [ 1203.404593] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 6, 29065 clusters in bitmap, 32768 in gd; block bitmap corrupt. [ 1203.404628] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 5, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt. [ 1203.404648] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 4, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt. [ 1203.404667] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 3, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt. [ 1203.404686] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 2, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt. [ 1203.404705] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 1, 1600 clusters in bitmap, 32321 in gd; block bitmap corrupt. [ 1203.404726] JBD2: Spotted dirty metadata buffer (dev = sdb6, blocknr = 0). There's a risk of filesystem corruption in case of system crash. [ 1204.141482] sd 8:0:0:0: [sdb] Media Changed [ 1204.141490] sd 8:0:0:0: [sdb] [ 1204.141494] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 1204.141497] sd 8:0:0:0: [sdb] [ 1204.141499] Sense Key : Unit Attention [current] [ 1204.141504] Info fld=0x0 [ 1204.141506] sd 8:0:0:0: [sdb] [ 1204.141510] Add. Sense: Not ready to ready change, medium may have changed The unit attention doesn't look like a problem, it looks correct. If the system is unable to detect removable media being changed while the system is suspended, then If the media has a unique identifier, then this unit attention at wakeup should trigger sd to make sure that unique identifier has not changed. Not sure why ext4 starts looking at sdb6 _before_ the sd driver processes that unit attention. Perhaps a TEST UNIT READY should be done earlier in the wake-up sequence to flush out (and process) unit attentions. There is also the case in which the removable media is no longer present; and that should change EXT4-fs processing to a surprise removal. Doug Gilbert [ 1204.141514] sd 8:0:0:0: [sdb] CDB: [ 1204.141516] Read(10): 28 00 00 0a 75 f8 00 00 08 00 [ 1204.141526] end_request: I/O error, dev sdb, sector 685560 Le Mon, 28 Apr 2014 15:01:39 +0200, Matthieu CASTET matthieu.cas...@parrot.com a écrit : Hi, any news on this. Matthieu CASTET Le Tue, 22 Apr 2014 16:01:15 +0200, Matthieu CASTET matthieu.cas...@parrot.com a écrit : Hi, while playing with suspend to ram I found a strange behavior with usb key. This can be easily reproduced by doing : - plug a usb key - start to read the usb key : cat /dev/sdx /dev/null - go to suspend : echo mem /sys/power/state - while in suspend, unplug and replug the usb key (simulate usb power loss for computer that keep power) - exit suspend - there is read error on the usb key Because the power was cut during s2ram, the usb stack reset the device 1. When new data transfer are done, we got a UNIT_ATTENTION from the device 2 and IO error are returned to user space application. After some investigation it seems some (all on the 3 I tested) usb key report as removable, and scsi layer abort the transfer in case of UNIT_ATTENTION 3. The usb storage driver call scsi_report_bus_reset after device reset, but because of commit dfcf7775 4, we don't ignore unit attention if sshdr.asc == 0x28 sshdr.ascq == 0x00 (Not-ready to ready). If dfcf7775 is reverted there is no more Buffer I/O error. Is that possible to find a way to restore the behavior before dfcf7775 commit (no Buffer I/O error after device reset) after a suspend to ram ? Matthieu CASTET PS : the same error happen if sg_reset -b /dev/sdx is used on the device. 1 [ 117.070255] usb 2-1.4: reset high-speed USB device number 3 using ehci-pci [...] [ 117.543922] Restarting tasks ... done. [ 117.548390] video LNXVIDEO:01: Restoring backlight state 2 [ 117.549179] sd 6:0:0:0: [sdb] Media Changed [ 117.549184] sd 6:0:0:0: [sdb] [ 117.549187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 117.549189] sd 6:0:0:0: [sdb] [ 117.549191] Sense Key : Unit Attention [current] [ 117.549195] Info fld=0x0 [ 117.549197] sd 6:0:0:0: [sdb] [ 117.549201] Add. Sense: Not ready to ready change, medium may have changed [ 117.549203] sd 6:0:0:0: [sdb] CDB: [ 117.549205] Read(10): 28 00 00 02 c9 00 00 00 f0 00 [ 117.549212] end_request: I/O error, dev sdb, sector 182528 [ 117.549218] Buffer I/O error on
Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device
On 14-01-17 02:35 AM, Hannes Reinecke wrote: On 01/16/2014 09:48 PM, Alan Stern wrote: It's now clear that this is _not_ an XHCI issue, contrary to what $SUBJECT says. On Thu, 16 Jan 2014, Peter Palúch wrote: Alan, I am attaching the usbmon trace after the drive has been plugged into the USB-2 port. Record of the drive in stall should occur around the file offset 87808 (decimal). The log was done on the 3.12.7 kernel without CONFIG_PM. Should I do a usbmon trace on my regular kernel with CONFIG_PM as well? No need. dmesg transcript: root@bach:/tmp# dmesg usb 4-1.2: new high-speed USB device number 5 using ehci-pci usb 4-1.2: New USB device found, idVendor=1058, idProduct=1230 usb 4-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1 usb 4-1.2: Product: My Book 1230 usb 4-1.2: Manufacturer: Western Digital usb 4-1.2: SerialNumber: 574D43344E30323438393836 usb-storage 4-1.2:1.0: USB Mass Storage device detected scsi6 : usb-storage 4-1.2:1.0 usbcore: registered new interface driver usb-storage scsi 6:0:0:0: Direct-Access WD My Book 1230 1050 PQ: 0 ANSI: 6 scsi 6:0:0:1: Enclosure WD SES Device 1050 PQ: 0 ANSI: 6 sd 6:0:0:0: Attached scsi generic sg2 type 0 scsi 6:0:0:1: Attached scsi generic sg3 type 13 sd 6:0:0:0: [sdb] Spinning up disk... .ready sd 6:0:0:0: [sdb] 732558336 4096-byte logical blocks: (3.00 TB/2.72 TiB) sd 6:0:0:0: [sdb] Write Protect is off sd 6:0:0:0: [sdb] Mode Sense: 53 00 10 08 sd 6:0:0:0: [sdb] No Caching mode page found sd 6:0:0:0: [sdb] Assuming drive cache: write through sd 6:0:0:0: [sdb] 732558336 4096-byte logical blocks: (3.00 TB/2.72 TiB) sd 6:0:0:0: [sdb] No Caching mode page found sd 6:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 6:0:0:0: [sdb] 732558336 4096-byte logical blocks: (3.00 TB/2.72 TiB) sd 6:0:0:0: [sdb] No Caching mode page found sd 6:0:0:0: [sdb] Assuming drive cache: write through sd 6:0:0:0: [sdb] Attached SCSI disk usb 4-1.2: reset high-speed USB device number 5 using ehci-pci It looks like the reset occurred because the computer sent an ATA-passthru command to the disk, and the disk wasn't prepared to handle it properly. The firmware crashed, requiring a reset. If anyone can explain, the command bytes in question were: 85082e00 ec00 SCSI ATA PASS-THROUGH(16) command issuing the mandatory ATA command 0xec which is IDENTIFY DEVICE. [See SAT-3 drafts for more information on the pass-through command.] and the sense data was: 7201001d 000e 090c 5d00 0100 0050 ATA spec says there should not (normally) be an error issued by that command; but there was: $ sg_decode_sense -n 7201001d 000e 090c 5d00 0100 0050 Descriptor format, current; Sense key: Recovered Error Additional sense: ATA pass through information available Descriptor type: ATA Status Return extend=0 error=0x0 sector_count=0x0 lba=0x00 device=0x0 status=0x50 Looks reasonable at the SCSI level, not sure about the ATA level, perhaps others can comment. I don't know what either of these means, or even what software was responsible for sending this command. It appears to have come from some user program, though, not the kernel. Possibly something run by udev. Probably smartd. The logic there is _less_ than perfect. Guilty as charged. Silly us, fancy smartmontools issuing mandatory ATA commands over a USB transport (MSC ?) and expecting the device to be well-behaved :-) Try to disable smartd and check if the issue remains. Probably will help. Throwing away all your USB storage devices (apart from those that do UAS(P)) would be even more helpful (to us). Perhaps smartmontools could do a better job of identifying USB connected storage devices and avoid them. Doug Gilbert [a smartmontools maintainer] -- 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: [PATCH 3/3] usb: ohci-at91: use device managed clk retrieval
On 13-12-04 04:21 PM, Alan Stern wrote: On Wed, 4 Dec 2013, boris brezillon wrote: The patches look fine to me. But only the 1/3 patch fixes a bug; the others merely change the resource management. Do you want me to split this series ? 1) the 1st patch that should be merged in 3.13 2) patches 2 to 4 that might be applied later That probably would make Greg happier. Putting my initial reporter hat on, USB OHCI is completely broken in lk 3.13.0 rc1 and rc2 for AT91 family members. So it is difficult to make the situation worse. IMO the whole 4 patches should go in, since it only impacts that family. Also the kernel is more than a month away from release. Perhaps the naysayers should be looking around for whatever else the of/irq: Pass trigger type in IRQ resource flags patch has broken. 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: Issue with mini-SaS to eSATA to USB 3.0 setup
On 13-02-21 02:26 PM, Sarah Sharp wrote: Cc-ing the SCSI and USB storage list. Folks, does the attached picture look like a sane setup? I've never used mini-SaS to eSATA adapter before, let alone with four eSATA to USB 3.0 adapters. Well SAS to eSATA is okay (works for me: LSI SAS9212-4i4e HBA via a SATA to eSATA cable to a SATA disk caddy with an eSATA port). eSATA to USB 3.0 adapters sound pretty dodgy, especially when no mention is made of UAS(P). Doug Gilbert On Tue, Jan 29, 2013 at 12:56:02PM -0200, Fabio David wrote: Hi Sarah, My name is Fabio David and I am from Brazil. I've seen your posts on several forums and read articles about you. I really admire your work. Maybe you can help me. I'm trying to connect a PC running Centos 6.3 to a CRU dataport 4-bay storage device. This device only has a miniSaS port. Here is my scenario: - DataCRU device with 4 hot-swapables bays. http://www.cru-inc.com/slideshow.php?dir=//Digital-Cinema//sel=5 - MiniSaS cable connects to the DataCRU device and on the other side there are 4 eSata connectors http://www.elpeus.com/sas-mini-sas/external-mini-sas-cables/sff-8088-to-4-esata/3m-mini-sas-sff-8088-to-4-esata-cable/ - 4 eSata-USB3.0 adaptors connected to each eSata connector - Adaptors connected to a USB3.0 HUB - USB3.0 hub connected to PC Everything works ok, I can mount/read the HDs, but sometimes the system does not detect when a hard drive is inserted/removed from a DataCru bay. No events are generated, nothing appears in /proc/partitions nor udev is called to apply my rules. Do you lose only hard drive insertion events, or do you lose remove events as well? For example, what happens when you do this: 1. Unplug the eSATA to USB adapters from the USB 3.0 hub. 2. Insert a hard drive into the bay. 3. Connect the eSATA to USB adapter to the USB 3.0 hub. 4. Wait for hard drive detection, then hot-remove the drive from the bay. However, everything works fine when connected directly to PC's USB port. Please look at the attached picture. It looks like you're only attaching one eSATA to USB adapter to the roothub. Do you only have one USB 3.0 port on the host, or can you try plugging in multiple eSATA to USB adapters into the roothub? Does the setup work when only one eSATA to USB adapter is plugged into the USB 3.0 hub? Do you have any suggestions? A couple possible root causes come to mind: 1. Perhaps the USB 3.0 hub is interfering with communication to your eSATA to USB 3.0 adapters. 2. Maybe USB device suspend is to blame. Do you have USB device suspend enabled for the eSATA to USB adapters? 3. Perhaps the SATA adapters aren't responding with a Medium Changed status when the USB storage device is plugged in. Can you send me dmesg, starting from just before you insert a hard drive into the drive bays? I need dmesg for both when the SATA adapter is connected directly to the roothub, and when it's connected to the USB 3.0 hub. A usbmon trace might also be useful for the USB storage developers. Documentation on how to take that trace is here: http://lxr.linux.no/#linux/Documentation/usb/usbmon.txt Sarah Sharp === lsusb returns Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 13d3:3323 IMC Networks Bus 001 Device 009: ID 2109:3431 HUB 3.0 Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 007 Device 040: ID 2109:0810 HUB 3.0 Bus 007 Device 041: ID 1234:5678 Brain Actuated Technologies Bus 007 Device 042: ID 1234:5678 Brain Actuated Technologies Bus 007 Device 043: ID 1234:5678 Brain Actuated Technologies Bus 007 Device 044: ID 1234:5678 Brain Actuated Technologies /var/log/messages Jan 27 18:00:28 localhost kernel: usb 7-1: New USB device found, idVendor=2109, idProduct=0810 Jan 27 18:00:28 localhost kernel: usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Jan 27 18:00:28 localhost kernel: usb 7-1: Product: 4-Port USB 3.0 Hub Jan 27 18:00:28 localhost kernel: usb 7-1: Manufacturer: VIA Labs, Inc. Jan 27 18:00:28 localhost kernel: usb 7-1: configuration #1 chosen from 1 choice Jan 27 18:00:28 localhost kernel: hub 7-1:1.0: USB hub found Jan 27 18:00:28 localhost kernel: hub 7-1:1.0: 4 ports detected Jan 28 21:32:02 localhost kernel: usb 7-1.1: new SuperSpeed USB device number 9 using xhci_hcd Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: xHCI Host Controller Jan 28 21:32:56 localhost kernel: xhci_hcd
