To my surprise, c/s 8888 enables CPU_FREQ for x86-64 rather than disabling it for i386. Did anyone at your end actually test that if enabled this at least builds properly now? Not to mention that of course this also should work... If I remember right, the main reason for posting a patch to disable it on 32-bits (similar to how it was on 64-bits before) was that there were some missing symbols, and I don''t think I saw any changesets addressing this. Also, from previous discussion I seem to recall that it was generally agreed that there is little point in allowing a single domain (even dom0) to decide whether/what power management actions should be taken without knowing about the requirements of the rest of the system... Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 2/20/06, Jan Beulich <JBeulich@novell.com> wrote:> To my surprise, c/s 8888 enables CPU_FREQ for x86-64 rather than disabling it for i386. Did anyone at your end actually > test that if enabled this at least builds properly now? Not to mention that of course this also should work... If I > remember right, the main reason for posting a patch to disable it on 32-bits (similar to how it was on 64-bits before) > was that there were some missing symbols, and I don''t think I saw any changesets addressing this. Also, from previous > discussion I seem to recall that it was generally agreed that there is little point in allowing a single domain (even > dom0) to decide whether/what power management actions should be taken without knowing about the requirements of the rest > of the system...I went with the final statement in the thread where you posted the patch, from Jeremy Katz stating, that it was working for dom0 and that disabling it would remove functionality. It is disabled for unprivileged guests. I''m happy to disable it entirely, if it doesn''t build or if it doesn''t work. christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 2006-02-20 at 18:12 +0000, Christian Limpach wrote:> On 2/20/06, Jan Beulich <JBeulich@novell.com> wrote: > > To my surprise, c/s 8888 enables CPU_FREQ for x86-64 rather than disabling it for i386. Did anyone at your end actually > > test that if enabled this at least builds properly now? Not to mention that of course this also should work... If I > > remember right, the main reason for posting a patch to disable it on 32-bits (similar to how it was on 64-bits before) > > was that there were some missing symbols, and I don''t think I saw any changesets addressing this. Also, from previous > > discussion I seem to recall that it was generally agreed that there is little point in allowing a single domain (even > > dom0) to decide whether/what power management actions should be taken without knowing about the requirements of the rest > > of the system... > > I went with the final statement in the thread where you posted the > patch, from Jeremy Katz stating, that it was working for dom0 and that > disabling it would remove functionality. It is disabled for > unprivileged guests. I''m happy to disable it entirely, if it doesn''t > build or if it doesn''t work.centrino cpufreq was working on my laptop about a month ago (with the caveat of there''s not a governor that takes into account activity in a domU, but that''s fine for at least manual scaling Jeremy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> christian.limpach@gmail.com 20.02.06 19:12:30 >>> >On 2/20/06, Jan Beulich <JBeulich@novell.com> wrote: >> To my surprise, c/s 8888 enables CPU_FREQ for x86-64 rather than disabling it for i386. Did anyone at your endactually>> test that if enabled this at least builds properly now? Not to mention that of course this also should work... If I >> remember right, the main reason for posting a patch to disable it on 32-bits (similar to how it was on 64-bitsbefore)>> was that there were some missing symbols, and I don''t think I saw any changesets addressing this. Also, fromprevious>> discussion I seem to recall that it was generally agreed that there is little point in allowing a single domain(even>> dom0) to decide whether/what power management actions should be taken without knowing about the requirements of therest>> of the system... > >I went with the final statement in the thread where you posted the >patch, from Jeremy Katz stating, that it was working for dom0 and that >disabling it would remove functionality. It is disabled for >unprivileged guests. I''m happy to disable it entirely, if it doesn''t >build or if it doesn''t work.p4-clockmod.c and speedstep-ich.c reference cpu_sibling_map, which doesn''t exist in Xen kernels. There was one other symbol missing, but I don''t recall which one (nor which module it was referenced from). As far as ''working'' goes, I would assume that any respective statements refer to a dom0-only scenario only. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel