linux-kernel - Re: Question about error from xhci-hcd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 01 Nov 2011 11:06:28 -0500
From:	Larry Finger <Larry.Finger@...inger.net>
To:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
CC:	USB list <linux-usb@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, v4mp <gaigo88@...mail.it>
Subject: Re: Question about error from xhci-hcd

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.

Thanks,

Larry


View attachment "dmesg1.log" of type "text/x-log" (81810 bytes)