Julius, I have done the testing; sorry for one day delay. I bought
some new hardware and was busy assembling test rigs; the end result is
that I was able to test four USB 3.0 controllers : Intel (Z97
chipset), NEC uPD720200 and two Asmedia. I tested two kernel versions:
3.2.61 and 3.16.0-rc5, both
Hi Maciej,
On Tue, Jul 15, 2014 at 11:29 AM, Maciej Puzio wrote:
> Julius, I tested the patch on kernel 3.2.61, on two USB 3.0 host
> controllers (Asmedia and NEC), and four USB 3.0 devices (three of
> which were previously triggering the issue, and one worked fine). On
> the Asmedia controller,
Julius, I tested the patch on kernel 3.2.61, on two USB 3.0 host
controllers (Asmedia and NEC), and four USB 3.0 devices (three of
which were previously triggering the issue, and one worked fine). On
the Asmedia controller, the patch fixes the regression, but with one
of the devices (Areca ARC-5040
Hi Maciej,
The patch is up here, I think you should've been CCed on it:
https://lkml.org/lkml/2014/7/8/571
I've only been able to test it on 3.8 with a normal controller, so
please test it on both 3.2 and later-than-3.2 with both your quirky
and a normal host controller (if you can), and add your
Julius, I am back from vacation and ready to do further tests, or to
test your patch if it is available. Apologies for the delay, I have
been away from the hardware for a week.
Thanks
Maciej Puzio
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to
From: David Laight
> From: Julius Werner
> ...
> > Also, really the only reason later kernels work for that controller is
> > because we don't handle the case where a TD wraps all the way around a
> > whole multi-segment ring back to the same segment.
>
> That is allowed because it would then be i
From: Julius Werner
...
> Also, really the only reason later kernels work for that controller is
> because we don't handle the case where a TD wraps all the way around a
> whole multi-segment ring back to the same segment.
That is allowed because it would then be impossible to add another
ring seg
Thanks Maciej, that was exactly what I needed! Looks like the problem
in your situation is that last_trb is actually (chronologically)
before hw_dequeue, which the code doesn't expect. You enqueue a
single-TRB-TD at 2f45e080 (so last_trb points there as well), which
encounters a Stall Error. I woul
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
w
Thanks for the report, this sounds very troubling. 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 expla
Hi, I am writing about commit 1f81b6d22a5980955b01e08cf27fb745dc9b686f
"usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb".
This commit has been introduced in kernel 3.15-rc3, and subsequently
backported to older kernels. In kernel 3.2.59 (used by Ubuntu 12.04 LTS),
and newer kern
11 matches
Mail list logo
