[lkml]   [2008]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.24-rc6-git12: Reported regressions from 2.6.23
On Sun, 6 Jan 2008 10:55:01 +0100
Ingo Molnar <> wrote:

> * Mark Lord <> wrote:
> > Rafael J. Wysocki wrote:
> >> This message contains a list of some regressions from 2.6.23
> >> reported since 2.6.24-rc1 was released, for which there are no
> >> fixes in the mainline I know of. If any of them have been fixed
> >> already, please let me know.
> > ..
> >> Subject : 20000+ wake-ups/second in 2.6.24
> >> Submitter : Mark Lord <>
> >> Date : 2007-12-02 04:23
> >> References :
> >>
> >> Handled-By : Arjan van de Ven <>
> >>
> >
> > I wonder if it's just a babbling IRQ on resume, before the driver
> > has run it's resume code or something ?
> i've read the discussions, and i cannot see it analyzed anywhere
> _what_ causes the wakeups. And how are these wakeups counted? Is this
> based on powertop output:
> Wakeups-from-idle per second : 20.4 interval: 1.8s
> ? Somewhere i saw it mentioned that "the CPU throws out of C mode".
> What does that mean - does it mean we try to idle again and again,
> but we immediately return from C mode - while this all looks like
> "idle" time to the scheduler (so 'top' will show lots of idle time),
> but the ACPI wakeup counters are going up like mad? What
> is /proc/interrupts doing when this happens - is any of the irq
> sources going upwards?

what seems to happen (and this is based on seeing this on my own devel laptop, as well
as several other reports; Mark is by far not the only one) is something hardware
related, it's been seen on lots of different kernel versions.

It seems to mostly (but not 100%) happen with TI cardbus bridges, where for some reason,
once the yenta driver is loaded (unloading it later makes no difference), once in a while
we get into a mode where the CPU always immediately goes out of the C-state again.
On a hardware level, there are only a few things that cause a CPU to exit a C-state,
and one of them is a pending interrupt of some kind, which is the most likely thing going on here;
some device or apic being stuck with interrupt high, but somehow the CPU isn't actually
seeing the interrupt itself (or has it blocked!)

To call this a 2.6.24 regression is a mistake (as I've said before), it's not new to .24
by any means.

If you want to reach me at my work email, use
For development, discussion and tips for power savings,

 \ /
  Last update: 2008-01-06 23:27    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean