linux-kernel - RE: EHCI Regression in 2.6.23-rc2

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]

Message-ID: <DFEF91B22ED07447AB6AA4B237F913F9B18E9B@ausx3mpc125.aus.amer.dell.com>
Date:	Wed, 15 Aug 2007 13:38:09 -0500
From:	<Stuart_Hayes@...l.com>
To:	<david-b@...bell.net>, <webmaster@...gonslave.de>
Cc:	<linux-usb-devel@...ts.sourceforge.net>,
	<linux-kernel@...r.kernel.org>, <jikos@...os.cz>, <greg@...ah.com>
Subject: RE: EHCI Regression in 2.6.23-rc2

Hayes, Stuart wrote:
> David Brownell wrote:
>>> 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.
>> 
>> Yeah, for some reason way too many of the add-on PCI cards with VIA
>> chips use that pretty-broken VT6202 chip.  Ones with VT6212 are also
>> available, and work a lot better.
>> 
>> 
>>>> 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.
>> 
>> Yes, IFF we know that the bug shows up in EHCI 1.00 chips rather than
>> just the already-known-to-be-buggy VT6202 chips.  (I think part of
>> the deal was that until the parts went through some conformance
>> testing, nobody could use the "1.0" label.  There were also a few
>> small feature updates and spec clarifications.  If anyone else
>> shipped silicon in volume that was as buggy as a VT6202, I didn't see
>> any.)
>> 
>> I'd be happy to see a warning come out whenever a VT6202 is found,
>> since its problems are NOT limited to this I-bit bug.
>> 
> 
> OK, I've got a VIA VT6212, and it's definitely not the same as the
> 6202--it's locking up my system, too, with my patch, and it is
> definitely not just ignoring the inactivate bit.  I'm still trying to
> figure out what's going on.   
> 
> The NEC controller (EHCI 1.00) seems to work fine, though.

OK... I see what's happening.  When the VIA VT6212 sees the "inactivate"
bit set, it will START the split transaction, but it doesn't finish it.
When I set the "I" bit--even if I set it like 50 uframes before the
transaction should start--the controller will set bit 1
(splitXstate--this means it's started the transaction) and clear bit 7
(active bit) in the token, when it comes time for the transaction to be
run.

This is a violation of EHCI 1.0 spec section 4.12.2.5, second bullet:

"If the Active bit is a one and the SplitXState is DoStart (regardless
of the value of S-mask), the host
controller will simply set Active bit to a zero... the host controller
must not issue the start-split bus transaction."

With an analyzer, I've observed that the controller is indeed issuing
"start split" without issuing "complete split", and I'm losing
keystrokes if I type when this is happening, as expected.

So... I still think blacklisting the VIA controllers from this CPU
frequency stuff is the best option.  It is unlikely that any real issues
will be seen during CPU frequency transitions with these controllers
anyway, because they claim to cache 8 uframes of the periodic schedule.

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