DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=pacbell.net;
  h=Received:X-YMail-OSG:Received:Date:From:To:Subject:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id;
  b=WzfK5YvXZLLrsZxZ0cmrTXPjOEALikJ+MenT1qigZLxeqZ7I6DPdd1ILRcx8173pcxLvV0uleENB/XLGdHdzFs5xhW2yChzrA0wrFFyegnvaAP3l3hwylohG4/hMdyqfRMSOHWCzrLEaFVayzoFYZ8lMdAM/2GcwXEvodOyJ1tU=  ;
Date: Tue, 14 Aug 2007 08:49:42 -0700
From: David Brownell <david-b@pacbell.net>
To: webmaster@dragonslave.de, Stuart_Hayes@Dell.com
Subject: Re: EHCI Regression in 2.6.23-rc2
Cc: linux-usb-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
       jikos@jikos.cz, greg@kroah.com
References: <200708101045.57166.dex@dragonslave.de>
 <200708140843.42196.webmaster@dragonslave.de>
 <200708140101.19651.david-b@pacbell.net>
 <200708141146.43215.webmaster@dragonslave.de>
 <DFEF91B22ED07447AB6AA4B237F913F9B18E53@ausx3mpc125.aus.amer.dell.com>
In-Reply-To: <DFEF91B22ED07447AB6AA4B237F913F9B18E53@ausx3mpc125.aus.amer.dell.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20070814154942.A544A2350CA@adsl-69-226-248-13.dsl.pltn13.pacbell.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2259
Lines: 49

> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/