I''m trying to get deep C states to work on my Dell D630 running a Core 2 Duo (Merom) T7300. The output of "xm debug-key c" implies that the processor supports C3, but max_cstate is set to 1. Digging through the code and adding some debug printk''s, I see that max_cstate is being changed from 7 to 1 by cpuidle_disable_deep_cstate(), which was added at c/s 19549. Am I reading correctly from: http://lists.xensource.com/archives/html/xen-devel/2009-04/msg00490.html that if a platform has no HPET (or it is disabled), no deep C power states are permitted? My D630 has no HPET... or at least there is no indication in the BIOS menu that there is an HPET. I tried setting "hpetbroadcast" and dom0 boot fails. Is there any way to get C3 working on my box or am I out of luck? Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 19/10/2009 18:03, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote:> My D630 has no HPET... or at least there is no indication > in the BIOS menu that there is an HPET.I think you do, since cpuidle_disable_deep_cstate() is called from handle_rtc_once(), which gets set up as a hook by hpet_broadcast_init(), which only gets that far If it has managed to initialise an HPET.> I tried setting "hpetbroadcast" and dom0 boot fails.Err.. What happens?> Is there any way to get C3 working on my box or am > I out of luck?You could try commenting out function disable_pit_irq() and its __initcall() invocation. This should cause fallback to pit_broadcast mode. It''s a completely different non-HPET-related approach that you could try. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > My D630 has no HPET... or at least there is no indication > > in the BIOS menu that there is an HPET. > > I think you do, since cpuidle_disable_deep_cstate() is called from > handle_rtc_once(), which gets set up as a hook by > hpet_broadcast_init(), > which only gets that far If it has managed to initialise an HPET. > > > I tried setting "hpetbroadcast" and dom0 boot fails. > > Err.. What happens?Transcribing from the console... INIT: version 2.86 booting Welcome to .... Press ''I'' to enter ... Real Time Clock Driver v1.12ac select() to /dev/rtc to wait for clock tick timed out Setting clock (utc): xxx [OK] Starting udev: [OK] Loading default keymap (us) [OK] Setting hostname localhost.localdomain [OK] Setting up Logical Volume Management.... [DOM0 FREEZES HERE] I suspect some timeout is being ignored? The boot continues fine if I do not specify hpetbroadcast.> > Is there any way to get C3 working on my box or am > > I out of luck? > > You could try commenting out function disable_pit_irq() and > its __initcall() > invocation. This should cause fallback to pit_broadcast mode. It''s a > completely different non-HPET-related approach that you could try.I tried this and got the same dom0 boot failure as above EXCEPT no line beginning with "select() to /dev/rtc..." (Same failure with and without hpetbroadcast option.) Dan P.S. This is with tip (c/s 20341) but NOT latest dom0. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 19/10/2009 19:55, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote:>> You could try commenting out function disable_pit_irq() and >> its __initcall() >> invocation. This should cause fallback to pit_broadcast mode. It''s a >> completely different non-HPET-related approach that you could try. > > I tried this and got the same dom0 boot failure as above > EXCEPT no line beginning with "select() to /dev/rtc..." > (Same failure with and without hpetbroadcast option.)Maybe the deep sleeps aren''t working so well. :-) Seriously, that''s really the sole common difference between your two failing cases and your one working case. A deterministic freeze like that during boot must mean something''s seriously confused that''s specific to your test machine, since we do know that ACPI deep sleeps are working much better than that on at least the small range of systems we tested on. Usually deep-sleep bugs have symptoms more like non-deterministic hangs after hours of uptime. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
(Sorry I thought I had sent this Monday!)> > My D630 has no HPET... or at least there is no indication > > in the BIOS menu that there is an HPET. > > I think you do, since cpuidle_disable_deep_cstate() is called from > handle_rtc_once(), which gets set up as a hook by > hpet_broadcast_init(), > which only gets that far If it has managed to initialise an HPET.You are correct as xm dmesg clearly says: Platform timer is 14.318MHz HPET.> Maybe the deep sleeps aren''t working so well. :-) Seriously, > that''s really > the sole common difference between your two failing cases and your one > working case. A deterministic freeze like that during boot must mean > something''s seriously confused that''s specific to your test > machine, since > we do know that ACPI deep sleeps are working much better than > that on at > least the small range of systems we tested on. Usually > deep-sleep bugs have > symptoms more like non-deterministic hangs after hours of uptime.Well I tried another box, this one a Nehalem box. Again, I am seeing no usage of C3 and max_cstate is set to 1. BUT with hpetbroadcast set, it IS using C3 extensively. (Unfortunately, it doesn''t help me as I need to test C3 on a machine without invariant TSC.) But is this a bug (that C3 only works if booted with hpetbroadcast)? Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 21/10/2009 16:16, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote:>> we do know that ACPI deep sleeps are working much better than >> that on at >> least the small range of systems we tested on. Usually >> deep-sleep bugs have >> symptoms more like non-deterministic hangs after hours of uptime. > > Well I tried another box, this one a Nehalem box. > > Again, I am seeing no usage of C3 and max_cstate is set to 1. > BUT with hpetbroadcast set, it IS using C3 extensively. > (Unfortunately, it doesn''t help me as I need to test C3 > on a machine without invariant TSC.) > > But is this a bug (that C3 only works if booted with hpetbroadcast)?I don''t think it''s a bug, but maybe a poor implementation choice. Possibly hpetbroadcast should be default, or we should fall back to PIT broadcast. Or you could just not build the RTC driver into your dom0 kernel, or not load the module, as it is that which is triggering disable of C3. And the driver is probably not really being of much use. Also, on newer platforms the HPET will continue to be used okay because the HPET will support MSI and so avoid conflicts over the legacy RTC interrupt line. Plenty of options... -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel