I'm not sure that unloading them will do the trick. I think that you need to make sure they don't get loaded in the first place. Seems to me that I tried unloading them when I had the problem and it did not make the problem go away. The only other thing that I worked on around the time that I got the problem fixed was the laptop_mode script. You wouldn't happen to be using that would you? The laptop_mode script wasn't quite what I wanted so I rewrote it. Those are the two things that I did when I eliminated my problem.
If you need my laptop_mode script I'll send it to you, I probably should rename it cause it's quite different, much more modular, uses functions a lot. hirakendu das wrote: > Why didn't you mention this earlier when the thread was active :| ? I'm a bad bad boy. Actually I wanted to prove what the solution was, but never got around to it. Later I figured the topic would come up again....and here we are. > > I still have the issue. Are you sure its about pcmcia and > yenta_socket? If so, why does unloading these modules not help ? > > The only workaround for me at this moment are these 2 : > 1) Either disable smp with maxcpus=1 in bootloader kernel commandline, > which probably is not the nicest option > or > 2) Don't enable higher c-states, aka c2 and c3. What I do is use high > res timer patches (also called cpuidle patches/framework, which will > be included in 2.6.23 by default), and compile both the governors > (menu and ladder) as modular and don't load any governor. (The moment > I load any governor, tsc is marked unstable due to possible halt in > c2.) Not enabling higher c-states c2 and c3 causes an extra power > consumption of 2 watts, but prevents the cpu from going into bad state. > > > > > > > > */Kelly Anderson <[EMAIL PROTECTED]>/* wrote: > > I might have good news for you. It's at least something to look at. I > had the same problem a month or so ago and it was making me tear > my hair > out. High wakeup counts and nothing seemed to account for them. In a > nutshell what I did was to blacklist pcmcia and yenta_socket. Since > then I have not had a problem a with the phantom wakeups. This is > great > if you're not using pcmcia, not so great if you need it. Just > create a > pcmcia file in /etc/modprobe.d with the following lines: > > blacklist pcmcia > blacklist yenta_socket > > See if that fixes it. If so maybe the problem should be forwarded to > the kernel devs. > > > Rafał Krypa wrote: > > Hello, > > I have seen this phenomenon several times already and want to > ask you > > about its cause. From time to time I am experiencing my Intel > Core Duo > > T2250 CPU going mad. The average wakeups per second exceeds 22k > (!). > > Here comes the output of powertop -d: > > > > PowerTOP 1.8 (C) 2007 Intel Corporation > > > > Collecting data for 15 seconds > > Cn Avg residency > > C0 (cpu running) (67.3%) > > C1 0.0ms ( 0.0%) > > C2 0.0ms (23.4%) > > C3 0.0ms ( 9.3%) > > P-states (frequencies) > > 1.74 Ghz 0.0% > > 1333 Mhz 0.0% > > 1067 Mhz 0.0% > > 800 Mhz 100.0% > > Wakeups-from-idle per second : 22379.8 interval: 15.0s > > Power usage (ACPI estimate): 14.5W (3.5 hours) > > Top causes for wakeups: > > 24.6% ( 11.5) hald-addon-cpuf : queue_delayed_work_on > > (delayed_work_timer_fn) > > 13.1% ( 6.1) Xorg : do_setitimer (it_real_fn) > > 10.4% ( 4.9) : extra timer interrupt > > 10.3% ( 4.8) : acpi > > 6.4% ( 3.0) multiload-apple : schedule_timeout (process_timeout) > > 6.3% ( 2.9) : queue_delayed_work_on > > (delayed_work_timer_fn) > > 3.7% ( 1.7) gnome-panel : schedule_timeout (process_timeout) > > 2.4% ( 1.1) : eth0 > > 2.3% ( 1.1) Xorg : schedule_timeout (process_timeout) > > 2.1% ( 1.0) dhcdbd : schedule_timeout (process_timeout) > > 2.1% ( 1.0) glunarclock-app : schedule_timeout (process_timeout) > > 2.1% ( 1.0) cpufreq-applet : schedule_timeout (process_timeout) > > 2.1% ( 1.0) nm-applet : schedule_timeout (process_timeout) > > (...) > > > > > > As you see, no process is responsible for these wakeups. And it > is not a > > simple display error of powertop: > > > > tassadar:~# cat /proc/acpi/processor/CPU0/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[1101632640] duration[00000000054670700051] > > C3: type[C3] promotion[--] demotion[C2] > > latency[057] usage[317590412] duration[00000000103865822447] > > > > > > Output for the second core is similar. > > Please notice very high usage counters for C2 and C3 - and this > is only > > with 1 day uptime. > > I am currently running 2.6.22.3 kernel (preparing for an update) > but I > > can remember seeing this with other kernel versions too. > > The problem is unfortunately non-deterministic. This strange > behavior of > > CPU happens from time to time and after reboot everything is back to > > normal. I cannot notice any particular actions leading into this. > > Could you please help me with finding and eliminating cause of this > > problem? > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Power mailing list > > [email protected] > > http://www.bughost.org/mailman/listinfo/power > > > > _______________________________________________ > Power mailing list > [email protected] > http://www.bughost.org/mailman/listinfo/power > > > ------------------------------------------------------------------------ > Looking for a deal? Find great prices on flights and hotels > <http://us.rd.yahoo.com/evt=47094/*http://farechase.yahoo.com/;_ylc=X3oDMTFicDJoNDllBF9TAzk3NDA3NTg5BHBvcwMxMwRzZWMDZ3JvdXBzBHNsawNlbWFpbC1uY20-> > > with Yahoo! FareChase. _______________________________________________ Power mailing list [email protected] http://www.bughost.org/mailman/listinfo/power
