From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: CONFIG_CPU_FREQ change Date: Tue, 21 Feb 2006 08:31:20 +0100 Message-ID: <43FACFD8.76F0.0078.0@novell.com> References: <43F9F1C2.76F0.0078.0@novell.com> <3d8eece20602201012t2aeea205xd496828f0706ec61@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <3d8eece20602201012t2aeea205xd496828f0706ec61@mail.gmail.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christian.Limpach@cl.cam.ac.uk Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> christian.limpach@gmail.com 20.02.06 19:12:30 >>> >On 2/20/06, Jan Beulich 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. 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