Bug 335086

It's probably not entering the sleep states correctly.
Can you provide cat /proc/acpi/processor/*/power
output when processor module is loaded.

You should see how many C-states are supported by your system.
If you have the processor module loaded, try to restrict the use of C-states, e.g. if you have C3, then try:
echo 2 >/sys/module/processor/parameters/max_cstate
Does it work normal then?
If still not, try:
echo 1 >/sys/module/processor/parameters/max_cstate

What kind of CPU/machine is that?

# cat /proc/acpi/processor/*/power
active state:            C2
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 8000 usec
states:
    C1:                  type[C1] promotion[C2] demotion[--] latency[001] usage[00000010] duration[00000000000000000000]
   *C2:                  type[C2] promotion[C3] demotion[C1] latency[001] usage[01185035] duration[00000000000033151654]
    C3:                  type[C3] promotion[--] demotion[C2] latency[057] usage[00301205] duration[00000000000010402063]


# echo 2 >/sys/module/processor/parameters/max_cstate
# Does it work normal then?

Nope.  In fact, it appears to double to wakeup count to nearly 60000/s.

# echo 1 >/sys/module/processor/parameters/max_cstate

That seems to work -- in the sense, that the wakeup count is not insane.
According to topertop, the machine stays in C0 all the time.

> What kind of CPU/machine is that?

Toshiba Satellite M105-S3041

# cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 14
model name      : Genuine Intel(R) CPU           T1350  @ 1.86GHz
stepping        : 8
cpu MHz         : 797.903
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe constant_tsc up pni monitor est tm2 xtpr
bogomips        : 3728.19
clflush size    : 64

This probably has to do with the latest nohz patches.
Venkatesh, do you know this already, maybe you have by chance already heard about a mainline solution?

Morton: Has there already been a linux/kernel running on the system not showing this behaviour? E.g. 10.2? Maybe you can try the latest 2.6.23 kernel from:
ftp://ftp.suse.com/pub/projects/kernel/kotd/HEAD/{i386,x86_64}/kernel-default...rpm

This bug is probably related, but there it only seems to happen after s2ram:
bug #334170

Only way I could imagine we come further here is described in bug #334170 comment #20.
As your problem is related (I don't want to make these duplicates, one seems to break in resume, the other one already at boot-up) maybe you want to contact the reporter of the bug, report this problem mainline and share some testing work...

I do not know whether my comment will help in this case but I had the same problem of the wake-up rate increasing dramatically after some arbitrary amount of time. In my case this was independent of the use s2ram, in contrast to Bug #334170.

For me, "yenta_socket" triggers the problem, see also https://bugs.launchpad.net/ubuntu/+bug/145377
Since I do not use PCMCIA at all, I created the following blacklist as /etc/modprobe.d/blacklist.pcmcia:
blacklist pcmcia
blacklist yenta_socket
blacklist rsrc_nonstatic
blacklist pcmcia_core

Blacklisting just yenta_socket seems to do the trick for me.

Can you please try with OpenSUSE 11.0 Alpha (Version Alpha 1 is the latest currently).
Now we can:
  - easier add code, as the risk to break other machines is not that sever
    -> Alpha is for testing
  - get support from mainline. If this problem is still in latest Alpha, this
    means mainline kernel is affected and we migth get additional help here.

Closing NOREPSONSE, due to missing information for more than 21 days. Please 
feel free to reopen and provide the requested information.

Eventually, I did a 11.0 Beta2 installation today. The "too many wakeups" is still there. After about an hour, there are more than 10,000 wakeups from idle per second. However, I have to verify that blacklisting the modules above (Comment #7) helps.

After an hour with the workaround of Comment #7, the wakeup rate is still normal (~100 per second).

Intel has done a lot in this area.
I hope they can help, possibly someone could point to a list where to ask for yenta driver problems?

You might want to try latest 11.1 Alpha/Beta, best wait some more days.
There should come out a new version which should be kernel 2.6.27 based.

This won't be fixed for 10.3 -> closing.
If you still see this you may want to reopen the bug and adjust the product.
If you still see this with 2.6.27 kernel, better open a bug on bugzilla.kernel.org. This is a very specific issue. But Intel might be interested in fixing this up.

Still valid for 11.0.

> Still valid for 11.0.

Hence reopening.

https://bugs.launchpad.net/ubuntu/+bug/145377/comments/112 seems promising.
Is there a SuSE build that includes that?

Yes this indeed could be it.
You may want to wait for next 11.1 test release and give it a try.
It should be 2.6.27 based and have the fix included.

Next 11.1 will still be 2.6.26 based because there are some well known problems in 2.6.27-rc1, the next one then, sorry.

Will you please try the boot option of "idle=nomwait" on the kernel of 2.6.27-rc1 and see whether the problem still exists?
Thanks.

You may want to wait a two weeks or so, then we should have a 2.6.27-rc2 kernel rpm here:
ftp://ftp.suse.com/pub/projects/kernel/kotd/HEAD/i386/kernel-default.rpm
You can double check with:
rpm -qpi kernel-default.rpm

We do not use 2.6.27-rc1 for our next Alpha releases due to known stability problems.

Any news here?

I'd like to close this one for 11.0.
This looks like a very HW specific thing.
You might want to reopen the bug if 11.1 is still affected.
But then still Intel must have a look at this.