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: <alpine.LFD.1.10.0804170224590.8464@nev.ubzr>
Date:	Thu, 17 Apr 2008 02:44:33 +0400 (MSD)
From:	"Lev A. Melnikovsky" <melnikovsky@...l.ru>
To:	David Brownell <david-b@...bell.net>
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 Wed, 16 Apr 2008 at 3:17am, David Brownell wrote:

DB> Which you *know* is aggravating the problem.  What numbers
DB> do you observe with a generic 2.6.25-rc9 kernel?  (That is,
DB> without that abusive 1 usec setting ... that kernel includes
DB> the patch switching to a more customary 10 usec value.)
~29.5 MB/s with ehci_hcd unloaded,
~26.0 MB/s with ehci_hcd loaded + USB hub is connected

The machine is mostly idle.

LM> #0. Nothing is connected to USB, no ehci-hcd loaded
LM>       hda throughput 28+-1MB/s
LM> #1. ehci-hcd loaded, still no USB peripherals
LM>       hda throughput 28+-1 MB/s
LM> #2. Something (USB hub and FLASH drive tested) is attached
LM>       hda throughput 15+-1 MB/s
LM> #3. All USB peripherals are removed
LM>       hda throughput 15+-1 MB/s
LM> #4. ehci-hcd is rmmod'ed
LM>       hda throughput 28+-1MB/s
DB> > The oddest peculiarity for me is the hysteretic difference between #1 and 
DB> > #3 states. I mean experimental data (hda throughput) depends not on the 
DB> > state (hardware/loaded modules), but on the path we followed.
DB> > 
DB> > Interestingly enough, sampling registers (via /sys) often shows Async bit 
DB> > set of the status register in the state #3. It is always cleared in #1.
DB> 
DB> With 2.6.25-rc9's default setting for async sleep time?
Yes. Async bit is oscillating and the frequency I see it set is much lower 
than that with 1us sleep time, but it is possible to catch the bit set 
high anyway. Here's one sample:

$ cat /sys/class/usb_host/usb_host4/registers 

bus pci, device 0000:00:09.2 (driver 10 Dec 2004)
EHCI Host Controller
EHCI 1.00, hcd state 1
ownership 00000001
SMI sts/enable 0xc0080000
structural params 0x00002204
capability params 0x00006872
status a008 Async Recl FLR
command 010009 (park)=0 ithresh=1 period=256 RUN
intrenable 37 IAA FATAL PCD ERR INT
uframe 28e0
port 1 status 001000 POWER sig=se0
port 2 status 001000 POWER sig=se0
port 3 status 001000 POWER sig=se0
port 4 status 001000 POWER sig=se0
irq normal 18 err 0 reclaim 4 (lost 0)
complete 18 unlink 1

DB> Means "none at all".  So if the "Async" status bit is set
DB> while the "Async" command is clear, it means the hardware
DB> is clearly misbehaving.  That status bit is supposed to
DB> turn itself off after the command bit is cleared ... within
DB> a couple milliseconds.
Yes, I understand that, but... I am not going to defend VIA, the chip does 
misbehave. I just wonder what is the difference between the states #1 and 
#3? Command register is the same, hardware is the same. If we know the 
difference, can we benefit from our understanding?

Namely: is it possible that an (empty) schedule is different?

DB> One hopes that when http://linux.via.com.tw finally appears,
OK, two hope :-)

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