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: <5a4c581d0803170915r73a9c6e5nbba264936af583ff@mail.gmail.com>
Date:	Mon, 17 Mar 2008 17:15:33 +0100
From:	"Alessandro Suardi" <alessandro.suardi@...il.com>
To:	"Lev A. Melnikovsky" <melnikovsky@...l.ru>
Cc:	"David Brownell" <david-b@...bell.net>,
	"Rene Herman" <rene.herman@...access.nl>,
	linux-kernel@...r.kernel.org
Subject: Re: ehci-hcd affects hda speed

On Sat, Mar 15, 2008 at 11:46 PM, Lev A. Melnikovsky
<melnikovsky@...l.ru> wrote:
>
>  LAM> Also, does anyone have a VT6212L datasheet? Unfortunately, Google
>  I have eventually found it. An enlightening reading, really. If I
>  understood all words, I mean :-). Particularly, what does "MAC turn around
>  time" stand for with respect to EHCI? I would appreciate some reference,
>  thanks.
>
>   On Wed, 5 Mar 2008 at 5:19pm, Rene Herman wrote:
>
>  RH> It was diagnosed to the VT6212L doing decidedly weird things with
>  RH> toggling the Async bit and tying up the bus.
>  Yes, it really looks like the chip owns the bus when it shouldn't. Suppose
>  VT6212L has damaged its brains somehow. Can we fix this by ignoring its
>  requests unless they are legitimate? I mean make the driver enable bus
>  mastering only for short periods when the controller is expected to do
>  something useful. It is easy (I have already done myself) to implement for
>  asynchronous schedule, but there's still periodic schedule. Is it
>  possible? How? Please advise.
>
>  Being positive, I didn't have much time to play with it yet, but changing
>  the bit 5 (EHCI sleep time select:  0=1us 1=10us) of register 0x4B seems
>  to resolve my own problem. I wonder if this is going to help others
>  (Alessandro?):
>
>  setpci -s 00:09.2 4b.b=29
>
>  [don't forget to adjust the device address].

00:09.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63)

heh, I don't even have to...

[root@...key ~]# hdparm -t /dev/hda

/dev/hda:
 Timing buffered disk reads:   54 MB in  3.03 seconds =  17.83 MB/sec
[root@...key ~]# setpci -s 00:09.2 4b.b=29
[root@...key ~]# hdparm -t /dev/hda

/dev/hda:
 Timing buffered disk reads:   78 MB in  3.06 seconds =  25.53 MB/sec

Well, that does look much better. Not on par with the non-EHCI case,
 but way better ! Thanks a lot !

Of course if you wish me to run anything else, just say so :)

--alessandro

 "We act as though comfort and luxury were the chief requirements
 of life, when all that we need to make us really happy is
 something to be enthusiastic about."

 (Charles Kingsley)
--
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/