From: Mark Lord
> >> Which means that the controller is obeying the rules, and the software is wrong.
> ..
> > In this case, the bug has been worked around (not perfectly), but we've
> > had no customer reports that this is an issue. There is no user-visible
> > impact as far as we know. So fixing this race condition is a really low
> > priority for me, and the fix would have to very minimally touch the
> > driver.
I'm seeing the problem with the ASMedia controller (rev 0.96).
Your fix is only active for rev 1.00 controllers.
You are assuming that all the changes between the 0.96 and 1.00 versions
of the specification are changes in behaviour between controllers that
report the relevant versions numbers.
Some of the changes will be new features, some will just be documenting
the way things have always been.
> There are a gazillion reports out there (google) that using any XHCI
> controller other than the NEC chip (and some Intel chips) causes instability,
> in particular when using the AMD and VIA chips.
>
> Right now, Linux USB3 has a very bad reputation -- buggy and unstable.
> If there's a bug we/you know about, then let's get it fixed.
> It could help some of those anonymous reports.
The reason I've been looking at the xhci driver is because we (as a company)
tried to use it and found it didn't work reliably.
Firstly with the intel panther point controller at USB2 speeds certain types
of line noise would cause the controller to stop processing requests.
(This is connected to the smsc95xx silicon, which is a USB hub with ethernet
and I2C (or similar) - we use all of those external ports.)
I've not really got anywhere near looking at those code paths, unfortunately
even the systems that failed 'often' would only fail about once a day - and
I rather failed to do anything that changed that.
The corporate solution was to connect to one of the USB2 headers.
The other thing I've been doing is an evaluation of the ASIX USB3 Ge silicon.
My initial tests showed that it sort of worked, but there were some lost
packets. With my patched kernel the lost packets disappeared.
I suspect you've just reverted the patch that fixed them.
Over the last few weeks I've spent a lot of man-hours investigating what
is actually happening with the controller and device driver to see WHY
it is misbehaving.
AFAICT everyone else is just randomly reverting patches assuming that
the old behaviour was better, rather than that the patch fixes something
but shows up another bug that has always been present - and then doing
a proper investigation to find out which circumstances cause the new failure.
Reverting patches can be a tool in finding out what has had an effect,
but it doesn't mean that reverting the patch is the actual fix.
I've been writing hardware device drivers and comms protocol stacks
(along with a few bare-board systems, and a bit of hardware design)
for most of the last 30 years.
I do know what I'm talking about.
David
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
