This may sound simple, but have you checked regular old "top"? When I get such high wattage, it's usually because of a runaway process pegging the CPU. Certain versions of gnome-power-manager will occasionally peg the CPU, presumably in response to certain power events. I haven't been able to isolate the problem but I am running Hardy Heron also, on an X61t, and I haven't experienced the problem for a few days after some recent updates were pushed.
If you're getting that many interrupts rescheduled, chances are high that at least one of your CPU cores is maxed out. Right now I'm getting only 186 interrupts per second with Pidgin, Thunderbird, gnome-terminal, and Firefox running, on AC power. Another less likely possibility is that you have a process requesting extremely small nanosleep times or it uses hrtimers and requests to be woken up as often as possible. In this case, CPU usage may not be 100%, but the constant waking up -- especially with the -generic kernel, which uses the fully preemptible kernel I believe -- is going to keep the CPU in C0. But still.... 25 W on my system is only barely attainable on full screen bright, disk grinding as hard as it can, with both cores maxed out. It might be that 25W is more normal for the larger T61. On Hardy Heron, with a default Gnome desktop using default panel applets and no foreground windows or applications, I only get between 12 and 20 wakeups per second with an idle mouse cursor (wireless off, wifi killswitch enabled). You should be getting comparable wakeups. Anything up to 250 wakeups per second is "reasonably normal" under certain system loads. Here are factors I know of which cause a lot of wakeups and are pretty much unavoidable: iwl4965 (or any wireless chipset driver that has detected your wireless hardware) wakes up often to interact with the hw firmware. It could probably be optimized to wake up less often, but seeing about 100 wakeups per second with this driver loaded (as opposed to unloaded) is normal under the current implementation. uhci_hcd (or ehci_hcd) is the USB kernel driver. If you have a fingerprint reader on your Thinkpad (like I do), then as long as these drivers are loaded, a certain amount of waking up is needed to keep the datastream to the chipset active. This incurs about 25 to 50 wakeups per second on my system. Of course, if you are actively using some USB device, this will wake up even more. But the fingerprint reader on ThinkPads is a counterintuitive use of the USB stack, since you don't see its physical plug into a USB port. HDA Intel (or snd_hda_intel or snd_usb_audio) is your ThinkPad's integrated soundcard. Whenever an application has an open ALSA stream, you'll usually see between 150 and 250 wakeups per second on this. This is a required aspect of sound architectures, since they often have a buffer consisting of many small pieces of data which are frequently filled and emptied. This is how software sound mixers are able to mix together two or more sound streams seamlessly and with low latency. PulseAudio (enabled by default) or ALSA-lib's dmix (Direct Stream Mixer), or Jack, or ESD, or any other software mixer, will incur you many wakeups. You _could_ get rid of all software mixing altogether by having programs open the hw:0 device only, but then you would be restricted to one sound application at a time -- there is no hardware mixing on this chipset. Still, if you had PulseAudio playing sound on top of dmix, were swiping your finger over the fingerprint reader, and downloading a file over 802.11g, that'd be (worst case) something like: 250 + 250 + 50 + 100 = 650. So the 2641 wakeups from interrupts alone, and the 38k+ wakeups (absolutely insane), which are not listed, are really an anomaly. If you can get your interrupts under 500 during heavy use with all the features you want, you're doing reasonably well. Beyond that, you can scrimp and save a few interrupts here and there by disabling features and trimming unused processes (especially daemons). HTH, -Sean Barteq wrote: > Hello. > > I've got problem with the newst ubuntu disribution Hardy Heron. It's based > on kernel 2.6.24 (exactly 2.6.24-12-generic - x86). Ubuntu used to be a > good choice for laptop but after seeing powertop result I'm thinking about > distor change.. > > Please look at the results. It's an idle system with xorg running. Machine > is T8300 based lenovo t61 with nvidia NVS 140M graphics card. Wifi is > intel 4965 card with iwl 1.2.0 driver. Power usage was about 16W on older > kernel, but now it is 22 up to 25W in idle. Additional abiility to get > into C3 is closed to 0. Of course sometimes it works quite nice, but after > some minutes it's ALWAYS getting wired. Do you noticed such a problem with > this kernel? I've googled this issue many times but with no success.. It's > also on ubuntu launchpad reported as a bug with 'in progress' state - > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177895 > > PowerTOP 1.9 (C) 2007 Intel Corporation > > Collecting data for 15 seconds > Cn Avg residency > C0 (cpu running) (46,5%) > C1 0,0ms ( 0,0%) > C2 0,0ms (49,7%) > C3 0,0ms ( 3,8%) > P-states (frequencies) > 2,41 Ghz 0,7% > 2,40 Ghz 0,0% > 2,00 Ghz 0,0% > 800 Mhz 99,3% > Wakeups-from-idle per second : 40905,2 interval: 15,0s > Power usage (ACPI estimate): 22,9W (1,6 hours) > Top causes for wakeups: > 92,9% (2641,7) <kernel IPI> : Rescheduling interrupts > 1,9% ( 54,4) <interrupt> : acpi > 1,7% ( 48,3) <interrupt> : extra timer interrupt > 1,4% ( 40,3) opera : schedule_timeout (process_timeout) > 0,7% ( 20,3) <interrupt> : iwl4965 > 0,4% ( 10,6) <interrupt> : ahci > 0,3% ( 8,0) <kernel module> : usb_hcd_poll_rh_status (rh_timer_func) > 0,1% ( 1,9) gnome-terminal : schedule_timeout (process_timeout) > 0,1% ( 1,7) wpa_supplicant : schedule_timeout (process_timeout) > 0,1% ( 1,5) <interrupt> : PS/2 keyboard/mouse/touchpad > 0,0% ( 1,3) kcryptd : blk_plug_device (blk_unplug_timeout) > 0,0% ( 1,1) <kernel IPI> : TLB shootdowns > 0,0% ( 1,0) <interrupt> : uhci_hcd:usb5, yenta, nvidia > 0,0% ( 1,0) Xorg : nv_start_rc_timer (nv_kern_rc_timer) > 0,0% ( 1,0) dhcdbd : schedule_timeout (process_timeout) > 0,0% ( 1,0) cpufreq-applet : schedule_timeout (process_timeout) > 0,0% ( 1,0) nm-applet : schedule_timeout (process_timeout) > 0,0% ( 0,9) NetworkManager : schedule_timeout (process_timeout) > 0,0% ( 0,9) sensors-applet : schedule_timeout (process_timeout) > 0,0% ( 0,6) pulseaudio : schedule_timeout (process_timeout) > 0,0% ( 0,5) iwl4965 : ieee80211_sta_work > (ieee80211_sta_timer) > 0,0% ( 0,5) <interrupt> : eth0 > 0,0% ( 0,5) <kernel module> : neigh_table_init_no_netlink > (neigh_periodic_timer) > 0,0% ( 0,5) NetworkManager : e1000_intr_msi (e1000_watchdog) > 0,0% ( 0,4) gnome-panel : schedule_timeout (process_timeout) > 0,0% ( 0,4) <kernel core> : neigh_table_init_no_netlink > (neigh_periodic_timer) > 0,0% ( 0,3) syslogd : schedule_timeout (process_timeout) > 0,0% ( 0,3) gnome-power-man : schedule_timeout (process_timeout) > 0,0% ( 0,2) update-notifier : schedule_timeout (process_timeout) > 0,0% ( 0,1) Xorg : do_setitimer (it_real_fn) > 0,0% ( 0,1) sm-notify : do_journal_end (delayed_work_timer_fn) > 0,0% ( 0,1) operapluginclea : schedule_timeout (process_timeout) > 0,0% ( 0,1) metacity : schedule_timeout (process_timeout) > 0,0% ( 0,1) Xorg : schedule_timeout (process_timeout) > 0,0% ( 0,1) <kernel core> : page_writeback_init (wb_timer_fn) > 0,0% ( 0,1) gnome-volume-ma : schedule_timeout (process_timeout) > 0,0% ( 0,1) <kernel core> : end_that_request_last (laptop_timer_fn) > 0,0% ( 0,1) iwl4965/0 : sta_info_start (sta_info_cleanup) > 0,0% ( 0,1) <kernel core> : ndisc_dst_alloc (fib6_run_gc) > 0,0% ( 0,1) Xorg : neigh_update (neigh_timer_handler) > > Regards, > barteq > > _______________________________________________ > Power mailing list > [email protected] > http://www.bughost.org/mailman/listinfo/power > _______________________________________________ Power mailing list [email protected] http://www.bughost.org/mailman/listinfo/power
