From: Andiry Xu <andiry.xu@amd.com>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>,
USB list <linux-usb@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>, v4mp <gaigo88@hotmail.it>
Subject: Re: Question about error from xhci-hcd
Date: Mon, 14 Nov 2011 17:18:13 +0800 [thread overview]
Message-ID: <4EC0DCD5.2010509@amd.com> (raw)
In-Reply-To: <4EB01904.10605@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 3508 bytes --]
On 11/02/2011 12:06 AM, Larry Finger wrote:
> On 10/30/2011 12:04 AM, Sarah Sharp wrote:
>
>> The xHCI driver allocates a fixed-size endpoint ring, and only so much
>> data can fit on it. If the driver is allocating many URBs or many URBs
>> with a lot of data, then you will see these messages and the URBs will
>> fail to be submitted. Now if neither of those conditions are true, then
>> it's possible we just have a bug in the xHCI driver.
>>
>> There is a patchset in the works to dynamically expand the endpoint
>> rings, but it's still going through revisions:
>>
>> http://marc.info/?l=linux-usb&m=131918645424329&w=2
>
> I have a bit more to report. Applying the above patch set did not help.
>
> I modified the xHCI driver from 3.1-rc10 to provide a stack dump
> whenever the messages appeared. The "short transfer on control ep"
> occurs before the rtl8192cu device has been plugged and has the
> following dump, which is probably not informative:
>
> [ 3.988197] xhci_hcd 0000:05:00.0: WARN: short transfer on control ep
> [ 3.988208] Pid: 0, comm: kworker/0:0 Not tainted
> 3.1.0-0301rc9-generic #201110050905
> [ 3.988213] Call Trace:
> [ 3.988225] [<c135788d>] ? dev_warn+0x2d/0x30
> [ 3.988238] [<f80852d5>] xhci_irq+0x1035/0x1050 [xhci_hcd]
> [ 3.988249] [<c1079827>] ? tick_program_event+0x27/0x40
> [ 3.988261] [<f808531c>] xhci_msi_irq+0x2c/0x30 [xhci_hcd]
> [ 3.988270] [<c10ac5b8>] handle_irq_event_percpu+0x48/0x190
> [ 3.988279] [<c10aee40>] ? irq_set_chip_and_handler_name+0x40/0x40
> [ 3.988286] [<c10ac73f>] handle_irq_event+0x3f/0x60
> [ 3.988294] [<c10aee40>] ? irq_set_chip_and_handler_name+0x40/0x40
> [ 3.988301] [<c10aee9b>] handle_edge_irq+0x5b/0xf0
> [ 3.988305] <IRQ> [<c1546a31>] ? do_IRQ+0x41/0xb0
> [ 3.988320] [<c1542950>] ? notifier_call_chain+0x30/0x60
> [ 3.988328] [<c1546970>] ? common_interrupt+0x30/0x38
> [ 3.988337] [<c104007b>] ? sched_debug_show+0x11b/0x5f0
> [ 3.988345] [<c12e5524>] ? intel_idle+0xa4/0x100
> [ 3.988355] [<c142833c>] ? cpuidle_idle_call+0xac/0x160
> [ 3.988364] [<c1001c27>] ? cpu_idle+0x97/0xd0
> [ 3.988368] [<c1537e16>] ? start_secondary+0xf6/0x110
>
> Just in case it is needed, the full dmesg output is attached.
>
> Due to wrapping of the dmesg buffer, the first few of stack dumps for
> the "ERROR no room on ep ring" messages were lost, but the one I got
> came from the following code fragment in
> drivers/net/wireless/rtlwifi/usb.c at line 87:
>
> usb_fill_control_urb(urb, udev, pipe,
> (unsigned char *)dr, buf, len,
> usbctrl_async_callback, buf);
> rc = usb_submit_urb(urb, GFP_ATOMIC);
>
> The value of len for this call is 4. The driver only uses 1, 2, or 4 as
> the lengths of writes, at least those that go through usb_submit_urb().
> Even the firmware download is done one dword at a time.
>
> We also tested with the xHCI code from the current mainline kernel, i.e.
> 3.1-git, but I don't have the dmesg output for that version. If you have
> any patches in the pipeline, or anything to test, please send those to me.
>
A control transfer ring should not be full. Only isoc and bulk transfer
will cause ring full with a lot of TDs submitted simultaneously. I
suspect the ring is mangled.
Please apply the patch attached, enable CONFIG_USB_DEBUG and
CONFIG_USB_XHCI_HCD_DEBUGGING and post the dmesg with the "no room on ep
ring" error.
Thanks,
Andiry
[-- Attachment #2: ringfull.patch --]
[-- Type: text/x-patch, Size: 580 bytes --]
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index e4b7f00..d949871 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2443,6 +2443,10 @@ static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
if (!room_on_ring(xhci, ep_ring, num_trbs)) {
/* FIXME allocate more room */
xhci_err(xhci, "ERROR no room on ep ring\n");
+ xhci_err(xhci, "Event ring:\n");
+ xhci_debug_ring(xhci, xhci->event_ring);
+ xhci_err(xhci, "Endpoint ring:\n");
+ xhci_debug_ring(xhci, ep_ring);
return -ENOMEM;
}
next prev parent reply other threads:[~2011-11-14 9:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-29 17:48 Question about error from xhci-hcd Larry Finger
2011-10-30 5:04 ` Sarah Sharp
2011-10-30 15:30 ` Larry Finger
2011-11-01 16:06 ` Larry Finger
2011-11-14 9:18 ` Andiry Xu [this message]
2011-11-28 18:14 ` Sarah Sharp
2011-11-28 21:53 ` Larry Finger
2011-12-28 16:30 ` Larry Finger
2011-12-29 3:32 ` Andiry Xu
2011-12-29 3:55 ` Larry Finger
2011-12-29 4:30 ` Andiry Xu
2011-12-29 16:49 ` Larry Finger
-- strict thread matches above, loose matches on Subject: below --
2012-02-07 5:47 Richard Farina
2012-02-07 9:52 ` Andiry Xu
2012-02-07 13:30 ` Larry Finger
2012-02-07 14:55 ` Sarah Sharp
2012-02-07 19:28 ` Larry Finger
2012-02-07 14:59 ` Richard Farina
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=4EC0DCD5.2010509@amd.com \
--to=andiry.xu@amd.com \
--cc=Larry.Finger@lwfinger.net \
--cc=gaigo88@hotmail.it \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sarah.a.sharp@linux.intel.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox