Messages in this thread | | | From | David Brownell <> | Subject | Re: ehci-hcd affects hda speed | Date | Tue, 15 Apr 2008 16:17:22 -0700 |
| |
On Tuesday 15 April 2008, Lev A. Melnikovsky wrote:
> I have repeated experiments with P3B-F and VT6212L combination (to > improve visibility the AsyncSchedSleepTime is set to 1us):
Which you *know* is aggravating the problem. What numbers do you observe with a generic 2.6.25-rc9 kernel? (That is, without that abusive 1 usec setting ... that kernel includes the patch switching to a more customary 10 usec value.)
> The oddest peculiarity for me is the hysteretic difference between #1 and > #3 states. I mean experimental data (hda throughput) depends not on the > state (hardware/loaded modules), but on the path we followed. > > Interestingly enough, sampling registers (via /sys) often shows Async bit > set of the status register in the state #3. It is always cleared in #1.
With 2.6.25-rc9's default setting for async sleep time?
> The async file is empty in both states. I wonder, how many degrees of > freedom does an empty schedule have? Does "empty" mean "has no incomplete > requests" or "has no requests at all"? Just guessing...
Means "none at all". So if the "Async" status bit is set while the "Async" command is clear, it means the hardware is clearly misbehaving. That status bit is supposed to turn itself off after the command bit is cleared ... within a couple milliseconds.
> I don't think this is purely VIA problem.
We've certainly seen enough "purely on VIA hardware" issues though; and I don't recall evidence showing this is NOT another one of those. Example, that bogus 1 usec default...
One hopes that when http://linux.via.com.tw finally appears, it will include errata for all relevant chipsets.
- Dave
| |