From: Jan Rychter <jan@rychter.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.22 USB problem (uhci)
Date: Fri, 19 Sep 2003 14:14:49 -0700 [thread overview]
Message-ID: <m2smmspjjq.fsf@tnuctip.rychter.com> (raw)
In-Reply-To: <20030919204419.GB7282@kroah.com> (Greg KH's message of "Fri, 19 Sep 2003 13:44:19 -0700")
>>>>> "Greg" == Greg KH <greg@kroah.com> writes:
Greg> On Fri, Sep 19, 2003 at 01:29:55PM -0700, Jan Rychter wrote: If
Greg> you want to suspend using 2.4, unload the usb drivers entirely.
Greg> That's the only safe way.
>>
>> I wasn't talking about suspending, but about processor
>> C-states. These are power states that the mobile processors enter
>> dynamically, many times a second. In my case:
Greg> Ah, sorry. I'm getting D and C states mixed up here.
[...]
You probably mean S-states, which are for sleep.
>> As you can see, C3 (lowest power) is being used a lot. This makes my
>> laptop run cool. If I use usb-uhci, the processor is never able to
>> go into C3 because of DMA activity. uhci is better, because it at
>> least permits me to use C3 when there are no devices plugged in.
>>
>> And going back to the uhci problem... ?
Greg> UHCI by design sucks massive PCI bandwidth. There is logic in
Greg> the uhci drivers that try to help this out by reducing
Greg> transactions when not much is going on, but there's only so much
Greg> we can do in software, sorry. I'm guessing that you aren't going
Greg> to be able to change this.
Greg> Unless you go buy a ohci usb cardbus controller card :)
Now you've confused me.
Do your comments above apply to "uhci" or "usb-uhci"?
Please allow me to restate the original problem:
-- I usually use uhci instead of usb-uhci, because it is able to go
into "suspend mode" when no devices are plugged, which allows the
CPU to enter C3 states,
-- usb-uhci eats CPU power by keeping it in C2 constantly because of
busmastering DMA activity, therefore being much less useful,
-- uhci generally works for me just fine, but breaks in one particular
case, when removing the device causes a strange message to be
printed and the system being unable to use the C3 states again,
until uhci is unloaded and reloaded back again.
Just as a reminder, this message is:
uhci.c: efe0: host controller halted. very bad
I hope if the message says "very bad", then this is something that can
be fixed. I was therefore reporting a problem with "uhci" and kindly
asking for help.
--J.
next prev parent reply other threads:[~2003-09-19 21:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-19 3:10 2.4.22 USB problem (uhci) Jan Rychter
2003-09-19 19:06 ` Greg KH
2003-09-19 19:17 ` Jan Rychter
2003-09-19 20:17 ` Greg KH
2003-09-19 20:29 ` Jan Rychter
2003-09-19 20:44 ` Greg KH
2003-09-19 21:14 ` Jan Rychter [this message]
2003-09-19 21:22 ` Greg KH
2003-09-19 22:30 ` Jan Rychter
2003-09-21 0:15 ` Jan Rychter
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=m2smmspjjq.fsf@tnuctip.rychter.com \
--to=jan@rychter.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.