RE: EHCI Regression in 2.6.23-rc2

[Stuart_Hayes]

Daniel Exner wrote:
> David Brownell wrote:
>> On Monday 13 August 2007, Daniel Exner wrote:
> [..]
>>> Where exactly should I search for this? Neither lspci nor lsusb
>>> showed any hint on the EHCI rev. the chip conforms to..
>> 
>> The driver logs that information as it starts; on this sytem:
>> 
>>  ehci_hcd 0000:00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec
>> 2004 
>> 
>> vs "EHCI 0.95".
> ehci_hcd 0000:00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
> 
> Build into:
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge
> [K8T800/K8T890 South] 
> 

Hm... I've got a 0.95.  I'll try to get a Via EHCI 1.00 controller and
make sure it's the same problem.

>>>>> I've also acquired a card with an NEC EHCI controller on it,
>>>>> which I'm going to look at while I'm into it...
>>>> 
>>>> Another case where there are a lot of add-on "EHCI 0.95" cards;
>>>> but in this case the quirks were less significant.
>>> 
>>> Some guy donated me a PCMCIA card with one of those, cause it'll
>>> wont work in his Windows only Notebook :)
>> 
>> A NEC 0.95 ??  Should be fine with Linux.  Assuming no bugs have
>> crept in.
> Didn't test it yet with 2.6.23-rc2 or rc3, but up to 2.6.22 it was
> fine :) 
> 
> Regarding the option to blacklist VIA in the module:
> I would prefer blacklisting VIA by default but giving the module some
> parameter like "honours inactive bit" to override this. 
> 
> Perhaps there are newer VIA Chips out there, that indeed do this and
> some users trigger happy enough to test this. :) 

That kernel parameter sounds like a reasonable idea to me.  The problem
that the patch is trying to work around is that, while the CPUs are
changing frequency, the EHCI controller gets delayed trying to read main
memory (because CPU cache snoops have to wait until the CPU is
finished)... if this happens in the middle of a split transaction to a
low/full speed device, the transaction won't complete in time, and you
get an error and possible data loss.

If the EHCI controller caches ahead enough, it shouldn't need to read
main memory to be able to complete the split transaction... but, while
the controller does say how much ahead it may cache, it isn't clear to
me that it will always be able to cache that much, so I thought it would
be safe to go ahead and inactivate split transactions during CPU
frequency transitions regardless.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/