3.18 regression: Error while assigning device slot ID, USB3 devices not detected
I've got an Intel Haswell-based system with a Gigabyte Z87X-D3H motherboard under Fedora 21. After updating to the 3.18.2-200 Fedora kernel, I noticed some errors in dmesg and at least some of my USB3 ports don't recognize any USB3 devices plugged into them: [0.560838] xhci_hcd :00:14.0: Error while assigning device slot ID [0.560912] xhci_hcd :00:14.0: Max number of devices this xHCI host supports is 32. [0.560990] usb usb2-port2: couldn't allocate usb_device [0.561098] xhci_hcd :00:14.0: Error while assigning device slot ID [0.561163] xhci_hcd :00:14.0: Max number of devices this xHCI host supports is 32. [0.561239] usb usb2-port5: couldn't allocate usb_device [0.561344] xhci_hcd :00:14.0: Error while assigning device slot ID [0.561409] xhci_hcd :00:14.0: Max number of devices this xHCI host supports is 32. [0.561484] usb usb2-port6: couldn't allocate usb_device This worked fine under 3.17. Is this a known problem? -- 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
xHCI regression in stable 3.13.5 with USB3 card reader
I have a USB 3.0 multi-card reader device: Bus 004 Device 002: ID 05e3:0743 Genesys Logic, Inc. which seems to work fine in 3.13.4 (Fedora version kernel-3.13.4-200 specifically) but fails in 3.13.5 (specifically kernel-3.13.5-202). Below is what I get in dmesg. Essentially there's a bunch of input/output errors making the reader mostly unusable. This is on an Intel Haswell machine with this controller: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05) It looks like there were some XHCI commits that went into 3.13.5 so it seems likely one of those is the cause. I can try current git if there's anything in there that's likely to fix it. But it does seem like a regression got into the stable kernel in this respect. [ 25.177926] usb 4-2: Disable of device-initiated U1 failed. [ 26.906531] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 26.918439] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a00 [ 26.918441] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a40 [ 26.921116] sd 6:0:0:0: [sdc] Unhandled error code [ 26.921118] sd 6:0:0:0: [sdc] [ 26.921120] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 26.921120] sd 6:0:0:0: [sdc] CDB: [ 26.921121] Read(10): 28 00 00 00 08 23 00 00 f0 00 [ 26.921126] end_request: I/O error, dev sdc, sector 2083 [ 27.208871] sd 6:0:0:0: [sdc] Media Changed [ 27.208874] sd 6:0:0:0: [sdc] [ 27.208875] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 27.208876] sd 6:0:0:0: [sdc] [ 27.208877] Sense Key : Unit Attention [current] [ 27.208878] sd 6:0:0:0: [sdc] [ 27.208880] Add. Sense: Not ready to ready change, medium may have changed [ 27.208880] sd 6:0:0:0: [sdc] CDB: [ 27.208881] Read(10): 28 00 00 00 08 24 00 00 ef 00 [ 27.208886] end_request: I/O error, dev sdc, sector 2084 [ 27.210467] FAT-fs (sdc1): FAT read failed (blocknr 35) [ 49.420334] usb 4-2: Disable of device-initiated U1 failed. [ 51.139080] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 51.150979] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a00 [ 51.150981] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a40 [ 51.153663] sd 6:0:0:0: [sdc] Unhandled error code [ 51.153665] sd 6:0:0:0: [sdc] [ 51.153666] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 51.153667] sd 6:0:0:0: [sdc] CDB: [ 51.153668] Read(10): 28 00 00 00 08 25 00 00 ee 00 [ 51.153672] end_request: I/O error, dev sdc, sector 2085 [ 51.441377] sd 6:0:0:0: [sdc] Media Changed [ 51.441379] sd 6:0:0:0: [sdc] [ 51.441380] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 51.441381] sd 6:0:0:0: [sdc] [ 51.441382] Sense Key : Unit Attention [current] [ 51.441384] sd 6:0:0:0: [sdc] [ 51.441385] Add. Sense: Not ready to ready change, medium may have changed [ 51.441386] sd 6:0:0:0: [sdc] CDB: [ 51.441386] Read(10): 28 00 00 00 08 26 00 00 ed 00 [ 51.441391] end_request: I/O error, dev sdc, sector 2086 [ 51.441454] FAT-fs (sdc1): FAT read failed (blocknr 37) [ 51.442083] FAT-fs (sdc1): FAT read failed (blocknr 37) [ 51.442570] FAT-fs (sdc1): FAT read failed (blocknr 235) [ 164.219227] usb 4-2: Disable of device-initiated U1 failed. [ 165.938731] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 165.950669] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a00 [ 165.950672] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a40 [ 165.953366] sd 6:0:0:0: [sdc] Unhandled error code [ 165.953368] sd 6:0:0:0: [sdc] [ 165.953369] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 165.953370] sd 6:0:0:0: [sdc] CDB: [ 165.953371] Read(10): 28 00 00 00 08 27 00 00 ec 00 [ 165.953375] end_request: I/O error, dev sdc, sector 2087 [ 166.240995] sd 6:0:0:0: [sdc] Media Changed [ 166.240997] sd 6:0:0:0: [sdc] [ 166.240999] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 166.241000] sd 6:0:0:0: [sdc] [ 166.241000] Sense Key : Unit Attention [current] [ 166.241002] sd 6:0:0:0: [sdc] [ 166.241003] Add. Sense: Not ready to ready change, medium may have changed [ 166.241004] sd 6:0:0:0: [sdc] CDB: [ 166.241005] Read(10): 28 00 00 00 08 28 00 00 eb 00 [ 166.241010] end_request: I/O error, dev sdc, sector 2088 [ 166.241055] FAT-fs (sdc1): FAT read failed (blocknr 39) -- 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: xHCI regression in stable 3.13.5 with USB3 card reader (Bisected)
On 05/03/14 11:17 PM, Robert Hancock wrote: I have a USB 3.0 multi-card reader device: Bus 004 Device 002: ID 05e3:0743 Genesys Logic, Inc. which seems to work fine in 3.13.4 (Fedora version kernel-3.13.4-200 specifically) but fails in 3.13.5 (specifically kernel-3.13.5-202). Below is what I get in dmesg. Essentially there's a bunch of input/output errors making the reader mostly unusable. This is on an Intel Haswell machine with this controller: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05) It looks like there were some XHCI commits that went into 3.13.5 so it seems likely one of those is the cause. I can try current git if there's anything in there that's likely to fix it. But it does seem like a regression got into the stable kernel in this respect. Bisecting between 3.13.4 and 3.13.5 gives me this: c8f44f98901994832ccecb87c3dd7900274b699a is the first bad commit commit c8f44f98901994832ccecb87c3dd7900274b699a Author: Sarah Sharp sarah.a.sh...@linux.intel.com Date: Fri Jan 31 11:26:25 2014 -0800 xhci 1.0: Limit arbitrarily-aligned scatter gather. commit 247bf557273dd775505fb9240d2d152f4f20d304 upstream. xHCI 1.0 hosts have a set of requirements on how to align transfer buffers on the endpoint rings called TD fragment rules. When the ax88179_178a driver added support for scatter gather in 3.12, with commit 804fad45411b48233b48003e33a78f290d227c8 USBNET: ax88179_178a: enable tso if usb host supports sg dma, it broke the device under xHCI 1.0 hosts. Under certain network loads, the device would see an unexpected short packet from the host, which would cause the device to stop sending ethernet packets, even through USB packets would still be sent. Commit 35773dac5f86 usb: xhci: Link TRB must not occur within a USB payload burst attempted to fix this. It was a quick hack to partially implement the TD fragment rules. However, it caused regressions in the usb-storage layer and userspace USB drivers using libusb. The patches to attempt to fix this are too far reaching into the USB core, and we really need to implement the TD fragment rules correctly in the xHCI driver, instead of continuing to wallpaper over the issues. Disable arbitrarily-aligned scatter-gather in the xHCI driver for 1.0 hosts. Only the ax88179_178a driver checks the no_sg_constraint flag, so don't set it for 1.0 hosts. This should not impact usb-storage or usbfs behavior, since they pass down max packet sized aligned sg-list entries (512 for USB 2.0 and 1024 for USB 3.0). Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Tested-by: Mark Lord ml...@pobox.com Cc: David Laight david.lai...@aculab.com Cc: Bjørn Mork bj...@mork.no Cc: Freddy Xin fre...@asix.com.tw Cc: Ming Lei ming@canonical.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- 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: [BUGREPORT] Linux USB 3.0
On 08/02/14 03:00 AM, Markus Rechberger wrote: On Tue, Feb 4, 2014 at 10:31 AM, David Laight david.lai...@aculab.com wrote: From: Markus Rechberger Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr These messages might be harmless. The 3.0 kernel contains a fix for Intel Panther Point xHCI hosts that suppresses those messages, commit ad808333d8201d53075a11bc8dd83b81f3d68f0b Intel xhci: Ignore spurious successful event. A later commit extends that to all xHCI 1.0 hosts, commit 07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0 That was queued for 3.11 and marked to be backported into stable kernels as old as 3.0. I see the same error message on the 0.96 ASMedia controller when the rx buffers for the ax88179_178a driver cross 64k boundaries. So this isn't confined to 1.0 controllers. Sarah, since there is no response yet, is there anyone at Intel dedicated at working on USB 3.0? We are also getting more and more negative USB 3.0 feedback with Linux Still nobody appears to have provided the requested debugging information that was requested. So there is not much that can be done upstream to debug things based only on vague reports, especially when not using current kernel versions. -- 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: USB Device 2232:1029 - Whassat?
On 12/16/2012 02:13 PM, Business Kid wrote: This is, I think, a webcam built into the Samsung 350V model NP350E7C-A05UK. I can't see it in windoze 8's pathetic excuse for a 'control panel' or the latest usb.ids. I Imagine 2232 is registered somewhere as a manufacturer but I've no hint who made it. If it's not the webcam, it's probably an sd card reader. The box is supposed to have both, but I only see the webcam. The spec just says 1.3 MP Camera. More to the point, I imagine there are fewer webcam chips than web camera makers in the world, so a driver may indeed already exist for it, or something similar. I will have linux installed on this by the end of the week. I'm limited by the UEFI under the windows 8 implementation as Samsung have it is an absolute disaster area for dual boot, so I'm buying an ssd and will install with secure boot disabled asap. I already have linux-3.6.10 compiled for the box(with every webcam module), and can try a few things then. In the meantime, any hints welcome. Not sure how to track down the manufacturer, but these days I think webcams need to use a UVC interface in order to get Windows logo certification, so it's likely to already be supported by the kernel. How do I even find who manufacturer 2232 is? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majordomo-u79uwxl29ty76z2rm5m...@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Fwd: Safely remove option shows with Micro SD Card connected to Linux through an Android phone
On 12/11/2012 02:37 PM, Alan Stern wrote: On Tue, 11 Dec 2012, prasannatsmkumar wrote: Hi All, I connected an Android phone using USB cable to my machine running Linux (Linux 3.0, 3.2, 3.5). Mounted the SD card in phone in system (phone is just a pass through I guess). When I choose Safely Remove option in nautilus file manager (gnome's default file manager) I got an error saying Error detaching: helper exited with exit code 1: Detaching device /dev/sdb USB device: /sys/devices/pci:00/:00:1d.7/usb1/1-5) SYNCHRONIZE CACHE: OK STOP UNIT: FAILED: No such file or directory STOP UNIT means spin down the disk or eject the disc. Since your phone doesn't have a disk drive or an optical disc, no wonder this step failed. The reason it's likely doing a STOP UNIT on USB storage devices is that this is preferable for at least USB-connected HDs (at least where the USB to SATA, etc. converter bothers to implement the translation). For many drives, it's better for the disk's lifespan to power it down normally (as it would be if it was in a machine that was being shut down) so it can unload its heads in a controlled fashion, rather than just cutting the power on the running disk and causing an emergency head retract. Some types of devices may not support that command or may not do anything useful with it, but No such file or directory seems a strange error to run into. and it goes to unmounted state (yes it should go to and this is not a problem). But I am not able to find the reason for the above error message pop-up. If I choose Eject option then things are fine (I think Eject does more than un-mounting the file system). I think safely remove tries to cut the power supply to the device but eject does not do that. Is that correct? No, neither option cuts power. The main difference is that safely remove disables the USB connection, so that if the device has an okay to unplug now light, the light will turn on. If the device cannot be powered down (due to battery charging) why this option is shown? Is kernel exposing such capability to the user space? I am not sure whether this is the correct place to ask this question. If this is not the correct place please direct me to correct place. You probably should get in touch with the people who maintain the Nautilus program if you want to know why it does something. Alan Stern -- 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: JMicron 20337 (152d:2338) and 3TB
On 05/08/2012 06:12 PM, Norman Diamond wrote: On Wed, 2012/5/9, Alan Stern wrote: On Tue, 8 May 2012, Norman Diamond wrote: Alan Stern wrote: On Tue, 8 May 2012, Norman Diamond wrote: In my case there is no other way that a host (PC or other, any OS or driver) could obtain a reported capacity past the 2.2TB mark. Sometimes I guess a USB-to-[S]ATA bridge might obey ATA passthru of an ATA Identify command though I haven't seen one. There definitely are some bridges which handle ATA passthru correctly. Oh, please can you suggest some. I search occasionally but have never found one that was described as obeying ATA passthru. Of course I can't command my users to use such bridges, but I would like to use one or two. The only ones I'm aware of are the entries marked with the SANE_SENSE quirk in unusual_devs.h: the HP Personal Media Drive (03f0:070c), the Genesys Logic bridge (05e3:0723), the Seagate FreeAgent Pro (0bc2:3010), the Maxtor bridge (0d49:7310), the Western Digital bridge (1058:0704), and a different JMicron bridge (152d:2329). Of course, the fact that the flag is set doesn't necessarily mean the device really does have SAT support. Among those, the Genesys and JMicron ones look like they have a chance of being used in adapters sold separately from Seagate and Western Digital external drives. By any chance do you know of cables or docking stations that use them? I have a Vantex NexStar TX 2.5 SATA enclosure that uses: Bus 001 Device 006: ID 152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp. JM20329 SATA Bridge and ATA pass-through seems to work (at least as far as commands like hdparm -I and smartctl). Except that READ CAPACITY(16) might cause some buggy devices to crash. Instead of rejecting the command as not handled? Exactly. For example, it wouldn't be surprising if quite a few flash drives crashed upon receiving that command. Considering that READ CAPACITY(16) has additional reasons for existing besides increased capacity, I hoped every manufacturer would be prepared to expect it, even if they reject it. Sigh. CAPACITY_10_AND_16: Issue both READ CAPACITY and READ CAPACITY(16), and if READ CAPACITY(16) gives a result 2 TB and READ CAPACITY doesn't give 0x, truncate the size to 2 TB; CAPACITY_HEURISTICS_63: Don't decrement the capacity if the reported capacity is a multiple of 63, but otherwise behave like CAPACITY_HEURISTICS; TEST_CAPACITY: Try to do a single-block read of the last reported block. What I'm wondering is whether it's appropriate to have three separate flags for these things, or whether some subset of them should be controlled by the same flag -- maybe a flag that would be set only for devices that are known to be bridges. They are three separate operations, and you've pointed out there's a chance that some devices might crash on some of them and not others, so it would be a good idea to make three separate flags. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majordomo-u79uwxl29ty76z2rm5m...@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [RFT] xhci: Switch PPT ports to EHCI on shutdown.
On 08/07/2012 11:39 AM, Sarah Sharp wrote:
The Intel desktop boards DH77EB and DH77DF have a hardware issue that
can be worked around by BIOS. If the USB ports are switched to xHCI on
shutdown, the xHCI host will send a spurious interrupt, which will wake
the system. Some BIOS will work around this, but not all.
The bug can be avoided if the USB ports are switched back to EHCI on
shutdown. The Intel Windows driver switches the ports back to EHCI, so
change the Linux xHCI driver to do the same.
Unfortunately, we can't tell the two effected boards apart from other
working motherboards, because the vendors will change the DMI strings
for the DH77EB and DH77DF boards to their own custom names. One example
is Compulab's mini-desktop, the Intense-PC. Instead, key off the
Panther Point xHCI host PCI vendor and device ID, and switch the ports
over for all PPT xHCI hosts.
The only impact this will have on non-effected boards is to add a couple
hundred milliseconds delay on boot when the BIOS has to switch the ports
over from EHCI to xHCI.
This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c2090aebba5698a1620604c7dccb448684 Intel xhci: Support
EHCI/xHCI port switching.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reported-by: Denis Turischev de...@compulab.co.il
Cc: sta...@vger.kernel.org
---
drivers/usb/host/pci-quirks.c |7 +++
drivers/usb/host/pci-quirks.h |1 +
drivers/usb/host/xhci-pci.c |9 +
drivers/usb/host/xhci.c |3 +++
drivers/usb/host/xhci.h |1 +
5 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index df0828c..c5e9e4a 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -800,6 +800,13 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
}
EXPORT_SYMBOL_GPL(usb_enable_xhci_ports);
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
+{
+ pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN, 0x0);
+ pci_write_config_dword(xhci_pdev, USB_INTEL_XUSB2PR, 0x0);
+}
+EXPORT_SYMBOL_GPL(usb_disable_xhci_ports);
+
/**
* PCI Quirks for xHCI.
*
diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
index b1002a8..ef004a5 100644
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -10,6 +10,7 @@ void usb_amd_quirk_pll_disable(void);
void usb_amd_quirk_pll_enable(void);
bool usb_is_intel_switchable_xhci(struct pci_dev *pdev);
void usb_enable_xhci_ports(struct pci_dev *xhci_pdev);
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
#else
static inline void usb_amd_quirk_pll_disable(void) {}
static inline void usb_amd_quirk_pll_enable(void) {}
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 92eaff6..9bfd4ca11 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -94,6 +94,15 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
xhci-quirks |= XHCI_EP_LIMIT_QUIRK;
xhci-limit_active_eps = 64;
xhci-quirks |= XHCI_SW_BW_CHECKING;
+ /*
+* PPT desktop boards DH77EB and DH77DF will power back on after
+* a few seconds of being shutdown. The fix for this is to
+* switch the ports from xHCI to EHCI on shutdown. We can't use
+* DMI information to find those particular boards (since each
+* vendor will change the board name), so we have to key off all
+* PPT chipsets.
+*/
+ xhci-quirks |= XHCI_SPURIOUS_REBOOT;
}
if (pdev-vendor == PCI_VENDOR_ID_ETRON
pdev-device == PCI_DEVICE_ID_ASROCK_P67) {
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 95394e5..81aa10c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -659,6 +659,9 @@ void xhci_shutdown(struct usb_hcd *hcd)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ if (xhci-quirks XHCI_SPURIOUS_REBOOT)
+ usb_disable_xhci_ports(to_pci_dev(hcd-self.controller));
This looks like a typo, think it should be not . With this code, it
appears the quirk will always be triggered since XHCI_SPURIOUS_REBOOT is
non-zero.
+
spin_lock_irq(xhci-lock);
xhci_halt(xhci);
spin_unlock_irq(xhci-lock);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 96f49db..c713256 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1494,6 +1494,7 @@ struct xhci_hcd {
#define XHCI_TRUST_TX_LENGTH (1 10)
#define XHCI_LPM_SUPPORT (1 11)
#define XHCI_INTEL_HOST (1 12)
+#define XHCI_SPURIOUS_REBOOT (1 13)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of
