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