14:00:34 <jskarvad> #startmeeting PowerManagement 14:00:34 <zodbot> Meeting started Wed Feb 9 14:00:34 2011 UTC. The chair is jskarvad. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:42 <jskarvad> Hi all 14:00:47 <jskarvad> news: 14:01:04 <jskarvad> The Developer conferece is approaching - http://fedoraproject.org/wiki/DeveloperConference2011 14:01:20 <jskarvad> It will start this Friday. 14:01:30 <jskarvad> We will have presentation there. 14:01:50 <jskarvad> I will post slides after the conf. 14:02:14 <jskarvad> I requested F15 Power Management testing day on 2011-03-24 - http://fedoraproject.org/wiki/QA/Fedora_15_test_days. 14:02:42 <jskarvad> I will prepare detailed instructions (after DevConf). 14:04:01 <jskarvad> Currently we are receiving feedback from users about the PM in Fedora. 14:04:10 <jskarvad> That's great. 14:05:17 <jskarvad> That's why we started Todos page (http://fedoraproject.org/wiki/SIGs/PowerManagement/Todos) where we would like to share our short and long term goals, ideas, users requests, worth to have PM features and so on... 14:06:51 <jskarvad> Next, does anybody know what is the current status of xhci (usb 3) suspend? 14:07:03 <jskarvad> I know that the code was removed from 2.6.37 as it was not yet ready. 14:10:14 <jskarvad> OK, I will try to search more. If anybody would know, please write me. 14:10:29 <jskarvad> I would like to see this feature in F15 14:11:34 <jskarvad> Next tuned. 14:11:49 <jskarvad> I played with the code and maybe I spot some possible problems. 14:12:06 <jskarvad> It seems that the PM-QoS cpu_dma_latency settings in dynamic cpu tuning plugin is not in effect. 14:12:34 <jskarvad> The code: 14:12:34 <jskarvad> open("/dev/cpu_dma_latency", "w").write(SETTINGS) 14:12:46 <jskarvad> in F14 Python interpreter writes the settings but immediately closes the handle. 14:13:12 <jskarvad> This behaviour seems not to be compatible with the PM-QoS specification as it states (the pm_qos_interface.txt): 14:13:27 <jskarvad> ...As long as the device node is held open that process has a registered request on the parameter.... 14:13:37 <jskarvad> ...To remove the user mode request for a target value simply close the device node... 14:13:44 <jskarvad> Thus this handle should be probably hold open. 14:14:33 <jvcelak> jskarvad: send a patch, file a bug or add it onto the todo list and i will take care of it :) 14:15:16 <jvcelak> jskarvad: how can we verify, that it is working correctly? 14:16:43 <jskarvad> currently this settings should be counted by cpuidle, thus we could monitor if the CPU enters the C6 by setting this latency lower than C6 latency is 14:17:04 <jskarvad> than the CPU shouldn't enter the C6 14:17:41 <jvcelak> ok 14:18:51 <jskarvad> I also looked on the PS-Poll wifi settings 14:19:09 <jskarvad> I think I got it (the iwpriv vs sys) 14:21:01 <jskarvad> The iwpriv interface seems to work at least for Intel ipw2100 and ipw2200 cards. 14:21:56 <jskarvad> The /sys/power_level interface seems to work on some newer cards (iwl3945, iwl4965). 14:22:21 <jskarvad> It can be used to force the settings. 14:22:55 <jskarvad> But the mac80211 stack also counts with the PM-QoS and the PM-QoS should be used instead (AFAIK). 14:24:00 <jskarvad> Thus we could open the /dev/network_latency, write there the PS-Poll latency (max from the spec) and holding it open. 14:25:39 <jskarvad> Probably good to incorporate it into network dynamic tuning plugin 14:27:27 <jskarvad> Currently one BP candidate will experiment with such modifications. 14:27:57 <jvcelak> that's great. 14:28:55 <jskarvad> So we will see, but it seems promising. 14:30:30 <jskarvad> that's all from my agenda 14:31:10 <jskarvad> anything else? 14:31:28 <jvcelak> I don't have anything. 14:33:25 <jskarvad> ok, jvcelak: thanks for feedback ;) and lets meet again next week 14:33:35 <jvcelak> np ;) 14:34:31 <jskarvad> #endmeeting