linux-kernel - Re: ehci-hcd affects hda speed

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]

Message-Id: <200804151617.23012.david-b@pacbell.net>
Date:	Tue, 15 Apr 2008 16:17:22 -0700
From:	David Brownell <david-b@...bell.net>
To:	"Lev A. Melnikovsky" <melnikovsky@...l.ru>
Cc:	Rene Herman <rene.herman@...access.nl>,
	Alessandro Suardi <alessandro.suardi@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: ehci-hcd affects hda speed

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

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