Re: Possible bug in xhci-ring.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Julius, I finally managed to generate some sensible (I hope) logs.
The kernel is 3.2.60-rc3 with modifications as you requested.

http://pastebin.com/6as4beZ3
This is an excerpt from syslog, showing messages logged immediately
after a USB3 device (Areca ARC-5040) was plugged in. The OS was booted
without any device plugged to USB3 ports, and booted seemingly normally.
After the device was plugged in, similar messages as in the above file
were logged 38 times, with ~30 second intervals. This was interspersed
with various timeout messages. After ~18 minutes, device was recognized
and filesystem mounted. Unfortunately the size of the full syslog file
(from boot to FS mount) is 6 MB, and greatly exceeds pastebin limits.
However, compressed file is significantly smaller. Can you indicate how
would you like to receive it? (pbput to pastebin.com, email attachment,
any other way?)

http://pastebin.com/B431CEbp
File xhci-ring.c with debug calls for your reference.

One more thing: I have run into difficulty coaxing xhci_dbg to log
anything by setting defines as you suggested. Instead I replaced
definitions of xhci_dbg, xhci_info, xhci_err and xhci_warn in the
following manner:
#define xhci_dbg(xhci, fmt, args...) \
    do { printk(KERN_ALERT "XHCI %s: " fmt, __FUNCTION__, ## args); } while(0)

Some additional thoughts:

> The piece of code you pointed out only affects single-segment
> transfer rings. I think the kernel generally switched to using
> multi-segment transfer rings for everything in commit 2fdcd47b69
> "xHCI: Allocate 2 segments for transfer ring", which explains why
> the problem doesn't affect kernels after 3.2

Does this mean that in kernels after 3.2 the problematic code line
(that toggles new_cycle_state) is never executed, i.e. dead code?

> [...] in the old code, it [state->new_deq_ptr] refers to the
> actual, final "new dequeue pointer" (the TRB that the ring will be
> set to start at with the Set TR Dequeue Pointer command), which
> should be one after cur->last_trb.

Looking at the debug output, this appears to be happening in the new
version as well, at least in this particular case.

I will be on vacation for the rest of this week and the next one.
I will try to answer emails, but unfortunately testing will have to
wait until July 14th, when I am back.

Thanks a lot
Maciej Puzio
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux