On Tuesday 15 April 2008, Lev A. Melnikovsky wrote:

quoted text
> 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.)


quoted text
> 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?


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


quoted text
> 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

--
unsubscribe notice
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/