Upon disconnecting an USB mouse from a 2.4.22, I get
uhci.c: efe0: host controller halted. very bad
and subsequently, the machine keeps on spinning in ACPI C2 state, never
going into C3, as it should (since the mouse is the only USB device).
If afterwards I do 'rmmod uhci; modprobe uhci', then the machine starts
using the C3 state again.
--J.
On Thu, Sep 18, 2003 at 08:10:48PM -0700, Jan Rychter wrote:
> Upon disconnecting an USB mouse from a 2.4.22, I get
>
> uhci.c: efe0: host controller halted. very bad
>
> and subsequently, the machine keeps on spinning in ACPI C2 state, never
> going into C3, as it should (since the mouse is the only USB device).
>
> If afterwards I do 'rmmod uhci; modprobe uhci', then the machine starts
> using the C3 state again.
If you use the usb-uhci driver, does it also do this?
thanks,
greg k-h
>>>>> "Greg" == Greg KH <[email protected]> writes:
Greg> On Thu, Sep 18, 2003 at 08:10:48PM -0700, Jan Rychter wrote:
>> Upon disconnecting an USB mouse from a 2.4.22, I get
>>
>> uhci.c: efe0: host controller halted. very bad
>>
>> and subsequently, the machine keeps on spinning in ACPI C2 state,
>> never going into C3, as it should (since the mouse is the only USB
>> device).
>>
>> If afterwards I do 'rmmod uhci; modprobe uhci', then the machine
>> starts using the C3 state again.
Greg> If you use the usb-uhci driver, does it also do this?
If you mean strange messages, no, it doesn't. Using usb-uhci it just
says "USB disconnect..." and everything looks fine.
As to C-states, usb-uhci prevents Linux from *ever* entering C3, being
effectively unusable on some laptops -- so there is no way I can see the
same symptoms with it.
--J.
On Fri, Sep 19, 2003 at 12:17:11PM -0700, Jan Rychter wrote:
> >>>>> "Greg" == Greg KH <[email protected]> writes:
> Greg> On Thu, Sep 18, 2003 at 08:10:48PM -0700, Jan Rychter wrote:
> >> Upon disconnecting an USB mouse from a 2.4.22, I get
> >>
> >> uhci.c: efe0: host controller halted. very bad
> >>
> >> and subsequently, the machine keeps on spinning in ACPI C2 state,
> >> never going into C3, as it should (since the mouse is the only USB
> >> device).
> >>
> >> If afterwards I do 'rmmod uhci; modprobe uhci', then the machine
> >> starts using the C3 state again.
>
> Greg> If you use the usb-uhci driver, does it also do this?
>
> If you mean strange messages, no, it doesn't. Using usb-uhci it just
> says "USB disconnect..." and everything looks fine.
>
> As to C-states, usb-uhci prevents Linux from *ever* entering C3, being
> effectively unusable on some laptops -- so there is no way I can see the
> same symptoms with it.
If you want to suspend using 2.4, unload the usb drivers entirely.
That's the only safe way.
thanks,
greg k-h
>>>>> "Greg" == Greg KH <[email protected]> writes:
Greg> On Fri, Sep 19, 2003 at 12:17:11PM -0700, Jan Rychter wrote:
> "Greg" == Greg KH <[email protected]> writes:
Greg> On Thu, Sep 18, 2003 at 08:10:48PM -0700, Jan Rychter wrote:
> Upon disconnecting an USB mouse from a 2.4.22, I get
>
> uhci.c: efe0: host controller halted. very bad
>
> and subsequently, the machine keeps on spinning in ACPI C2 state,
> never going into C3, as it should (since the mouse is the only USB
> device).
>
> If afterwards I do 'rmmod uhci; modprobe uhci', then the machine
> starts using the C3 state again.
>>
Greg> If you use the usb-uhci driver, does it also do this?
>>
>> If you mean strange messages, no, it doesn't. Using usb-uhci it just
>> says "USB disconnect..." and everything looks fine.
>>
>> As to C-states, usb-uhci prevents Linux from *ever* entering C3,
>> being effectively unusable on some laptops -- so there is no way I
>> can see the same symptoms with it.
Greg> If you want to suspend using 2.4, unload the usb drivers
Greg> entirely. 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:
[10:52] tnuctip:/usr/src/linux#cat /proc/acpi/processor/CPU0/power
active state: C3
default state: C1
bus master activity: 00000000
states:
C1: promotion[C2] demotion[--] latency[000] usage[00000520]
C2: promotion[C3] demotion[C1] latency[001] usage[00159073]
*C3: promotion[--] demotion[C2] latency[100] usage[02297764]
[13:28] tnuctip:/usr/src/linux#
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... ?
--J.
On Fri, Sep 19, 2003 at 01:29:55PM -0700, Jan Rychter wrote:
> Greg> If you want to suspend using 2.4, unload the usb drivers
> Greg> entirely. 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:
Ah, sorry. I'm getting D and C states mixed up here.
> [10:52] tnuctip:/usr/src/linux#cat /proc/acpi/processor/CPU0/power
> active state: C3
> default state: C1
> bus master activity: 00000000
> states:
> C1: promotion[C2] demotion[--] latency[000] usage[00000520]
> C2: promotion[C3] demotion[C1] latency[001] usage[00159073]
> *C3: promotion[--] demotion[C2] latency[100] usage[02297764]
> [13:28] tnuctip:/usr/src/linux#
>
> 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... ?
UHCI by design sucks massive PCI bandwidth. There is logic in the uhci
drivers that try to help this out by reducing transactions when not much
is going on, but there's only so much we can do in software, sorry. I'm
guessing that you aren't going to be able to change this.
Unless you go buy a ohci usb cardbus controller card :)
thanks,
greg k-h
>>>>> "Greg" == Greg KH <[email protected]> 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.
On Fri, Sep 19, 2003 at 02:14:49PM -0700, Jan Rychter wrote:
> >>>>> "Greg" == Greg KH <[email protected]> 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.
Ugh, ok, I give up :)
> >> 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.
Ok, sorry for the confusion. No I don't know of a fix for this problem,
but one just went into the 2.6 kernel tree for the uhci-hcd driver that
you might want to take a look at that fixed a problem almost exactly
like this.
thanks,
greg k-h
>>>>> "Greg" == Greg KH <[email protected]> writes:
[...]
>> 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.
Greg> Ok, sorry for the confusion. No I don't know of a fix for this
Greg> problem, but one just went into the 2.6 kernel tree for the
Greg> uhci-hcd driver that you might want to take a look at that fixed
Greg> a problem almost exactly like this.
Greg,
I've looked at uhci.c, the message comes from line 2461, in
uhci_interrupt. But there is no chance I will be able to fix it without
first understanding thoroughly how uhci.c works.
So I guess this goes into my "unfixed Linux bugs" bin.
--J.
>>>>> "Jan" == Jan Rychter <[email protected]>:
>>>>> "Greg" == Greg KH <[email protected]> writes:
Jan> [...]
> 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.
Greg> Ok, sorry for the confusion. No I don't know of a fix for this
Greg> problem, but one just went into the 2.6 kernel tree for the
Greg> uhci-hcd driver that you might want to take a look at that fixed
Greg> a problem almost exactly like this.
Jan> Greg,
Jan> I've looked at uhci.c, the message comes from line 2461, in
Jan> uhci_interrupt. But there is no chance I will be able to fix it
Jan> without first understanding thoroughly how uhci.c works.
Jan> So I guess this goes into my "unfixed Linux bugs" bin.
I've just realized that some people may not know why the above uhci bug
is a problem.
Having done some measurements and calculations, the above uhci bug
translates into a shortened battery life: 20 minutes less for the laptop
I've been testing on. You get 1h30 instead of 1h50 you would normally
get if uhci would work correctly.
That's like having only 84% of your battery available to start with.
--J.