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]

Date:	Tue, 14 Aug 2007 08:49:42 -0700
From:	David Brownell <david-b@...bell.net>
To:	webmaster@...gonslave.de, Stuart_Hayes@...l.com
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

> 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.

>	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.

Right.
-
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/