From: David Brownell <david-b@pacbell.net>
To: Rene Herman <rene.herman@keyaccess.nl>
Cc: Grant Coady <grant_lkml@dodo.com.au>,
Lennart Sorensen <lsorense@csclub.uwaterloo.ca>,
Pavel Machek <pavel@ucw.cz>,
Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Mark Lord <lkml@rtr.ca>,
David Brownell <dbrownell@users.sourceforge.net>
Subject: Re: External USB2 HDD affects speed hda
Date: Thu, 2 Jun 2005 17:54:04 -0700 [thread overview]
Message-ID: <200506021754.04872.david-b@pacbell.net> (raw)
In-Reply-To: <429F9C90.2000602@keyaccess.nl>
On Thursday 02 June 2005 4:56 pm, Rene Herman wrote:
> Grant Coady wrote:
>
> > root@sempro:~# cat /sys/class/usb_host/usb1/registers
> > bus pci, device 0000:00:10.4 (driver 10 Dec 2004)
> > EHCI 1.00, hcd state 1
> > structural params 0x00004208
> > capability params 0x00006872
> > status a008 Async Recl FLR
> > command 010009 (park)=0 ithresh=1 period=256 RUN
>
> David, did I understand correctly that the Async status bit should not
> be set without the Async command bit, period? Or was that just in my
> case, with everything idle/off/disconnected?
It's like this: turn on the command bit, then after a while the status
bit changes and shows the command took effect. Turn off the command bit,
ditto. And if everything is idle/disconnected, nothing should be
turning the bit on ... both bits should stay off at all times.
The driver needs to avoid doing certain things while the chip is in
the middle of activating or de-activating one of the schedules, so
it checks to see whether the bits agree. If they disagree, the chip
hasn't finished the last enable/disable command.
> If first, then I'm happy that it's not just me ...
>
> > 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
>
> ... although maybe still just VIA.
Maybe. Thing is, normally it should take just no more than a
millisecond or two for the command to take effect. So the fact
that either of you can consistently see something happening there
is pretty strange. Something would seem to be turning the async
schedule on/off a lot. The driver isn't _supposed_ to do that.
But then, neither is the chip (without the driver telling it to
do so) ... something's being annoying there.
>
> > 2.6.12-rc5-mm2a third run
>
> [ snip, no Async or Recl status bit ]
>
> > irq normal 8184 err 0 reclaim 5387 (lost 82)
>
> No idea about those. Not seeing lost interrupts here, even after
> generating quite some traffic.
The "lost" interrupts are cases where the VIA hardware (it's never
been seen by me on any other hardware) is supposed to issue an IRQ
as part of the reclaim process, but doesn't.
- Dave
next prev parent reply other threads:[~2005-06-03 0:54 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-30 23:21 External USB2 HDD affects speed hda Rene Herman
2005-06-01 8:18 ` Pavel Machek
2005-06-01 18:25 ` Rene Herman
2005-06-01 19:40 ` David Brownell
2005-06-01 22:14 ` Rene Herman
2005-06-01 22:33 ` Rene Herman
2005-06-01 23:43 ` David Brownell
2005-06-02 1:23 ` Mikulas Patocka
2005-06-02 2:17 ` David Brownell
2005-06-02 13:19 ` Rene Herman
2005-08-05 22:34 ` Rene Herman
2005-09-17 2:36 ` David Brownell
2005-09-17 14:45 ` Rene Herman
2005-12-12 23:24 ` Rene Herman
2005-06-02 13:57 ` Lennart Sorensen
2005-06-02 13:11 ` Rene Herman
2005-06-02 20:37 ` Lennart Sorensen
2005-06-02 22:49 ` Grant Coady
2005-06-02 23:56 ` Rene Herman
2005-06-03 0:54 ` David Brownell [this message]
2005-06-01 11:48 ` Mark Lord
2005-06-01 18:30 ` Rene Herman
2005-06-01 19:15 ` Petr Vandrovec
2005-06-01 19:45 ` Rene Herman
2005-06-01 20:37 ` David Brownell
2005-06-01 22:24 ` Rene Herman
2005-06-01 23:40 ` David Brownell
-- strict thread matches above, loose matches on Subject: below --
2005-12-21 7:08 Helmut Toplitzer
2005-12-21 8:10 ` Rene Herman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200506021754.04872.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=dbrownell@users.sourceforge.net \
--cc=grant_lkml@dodo.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@rtr.ca \
--cc=lsorense@csclub.uwaterloo.ca \
--cc=pavel@ucw.cz \
--cc=rene.herman@keyaccess.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox