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]

Date:	Tue, 15 Apr 2008 23:56:24 +0400 (MSD)
From:	"Lev A. Melnikovsky" <melnikovsky@...l.ru>
To:	Rene Herman <rene.herman@...access.nl>
cc:	Alessandro Suardi <alessandro.suardi@...il.com>,
	David Brownell <david-b@...bell.net>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: ehci-hcd affects hda speed

hi,

Sorry, I had virtually no time to answer earlier. If (hopefully) someone 
is still interested, here's my feedback

  On Thu, 20 Mar 2008 at 3:50am, Rene Herman wrote:

RH> I do wonder -- is your hda throughput also the same before _ever_ 
RH> attaching anything to the EHCI controller and after? In my case, the 
RH> slow down only happened after switching on my external USB drive once, 
RH> and would persist from that time until reboot (or unloading ehci-hcd, 
RH> which I kept modular for exactly that reason).
I have repeated experiments with P3B-F and VT6212L combination (to 
improve visibility the AsyncSchedSleepTime is set to 1us):

#0. Nothing is connected to USB, no ehci-hcd loaded
      hda throughput 28+-1MB/s

#1. ehci-hcd loaded, still no USB peripherals
      hda throughput 28+-1 MB/s

#2. Something (USB hub and FLASH drive tested) is attached
      hda throughput 15+-1 MB/s

#3. All USB peripherals are removed
      hda throughput 15+-1 MB/s

#4. ehci-hcd is rmmod'ed
      hda throughput 28+-1MB/s

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

RH> The sleep time wasn't the core problem, so I wonder of later VIA chips do
RH> still have the active async schedule problem...
I don't think this is purely VIA problem. I did not _try_ to install that 
VT6212L card into newer motherboard, but my _feeling_ is that we see an 
"incompatibility" between older PCI mobo chipsets and VIA USB controller. 
Actually, taking into account superior PCI bandwidth of modern PCs (if 
compared with my old P3B-F motherboard) I am not sure we can perform a 
clean reliable test without PCI bus analyzer.

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