RE: [Xen-devel] xen cpuidle c states

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

FYI, I tracked this problem down to use of /sbin/hwclock
in /etc/rc.sysinit in any RH-based dom0 boot process.
By disabling /sbin/hwclock (mv /sbin/hwclock /sbin/hwclock.bak)
in dom0, the hpetbroadcast boot option is not required and
C3 will once again work.  BUT some machines (including my
Dell D630 laptop) apparently have broken HPET's and will
then freeze during boot.  Your mileage may vary.

I've reported this offlist to the Intel team.

Note also that some processors do not support C3...
The laptop version of Core 2 Duo (Merom) does, but
the desktop version of Core 2 Duo (Conroe) does not.

It's not that easy being green... ;-)

Dan

> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Thursday, November 05, 2009 2:51 AM
> To: Andrew Lyon; Xen-devel
> Subject: Re: [Xen-devel] xen cpuidle c states
> 
> 
> Oh, another possibility is that deep sleeps get nobbled 
> during dom0 boot, if
> dom0 wants to use the RTC interrupt line. For some boring 
> technical reason,
> this can conflict with hpet broadcast mode and then deep sleeps get
> disabled, rather than falling back to a more sensible mode of 
> operation.
> 
> You might try addign hpetbroadcast as a Xen boot parameter to 
> see if that
> improves matters for you.
> 
>  -- Keir
> 
> On 05/11/2009 09:46, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
> 
> > I suggest add a few more printks to find out what's going 
> on. E.g., what is
> > the value of xen_cpuidle near the end of 
> arch/x86/setup.c:__start_xen().
> > 
> > How do you know only C1 is being used: is that what xenpm 
> tells you? There
> > could be other reasons deeper sleeps are unavailable, such 
> as dom0 not
> > informing Xen about their availability (misconfigured dom0 kernel?).
> > 
> >  -- Keir
> > 
> > On 05/11/2009 09:30, "Andrew Lyon" <andrew.lyon@xxxxxxxxx> wrote:
> > 
> >> Hi,
> >> 
> >> I've been looking into cpuidle c state usage on my Xeon based xen
> >> servers and I've noticed a couple of things I don't understand:
> >> 
> >> The xenpm documentation at 
> http://wiki.xensource.com/xenwiki/xenpm it
> >> states that  "In xen3.4, cpuidle is enabled by default since c/s
> >> 19421.", but just over a month later that change was 
> reversed by c/s
> >> 19545 with  comment "x86: Disable cpuidle by default unless hpet
> >> broadcast is available."
> >> 
> >> So I started looking at the code to see if there would be 
> any messages
> >> indicating whether hpet broadcast/cpuidle was enabled or 
> not, and in
> >> xen/arch/x86/time.c I found the following code which I am 
> struggling
> >> to make sense of:
> >> 
> >>   /*
> >>      * If we do not rely on PIT CH0 then we can use HPET 
> for one-shot timer
> >>      * emulation when entering deep C states.
> >>      * XXX dom0 may rely on RTC interrupt delivery, so only enable
> >>      * hpet_broadcast if FSB mode available or if 
> force_hpet_broadcast.
> >>      */
> >>     if ( xen_cpuidle && !boot_cpu_has(X86_FEATURE_ARAT) )
> >>     {
> >>         hpet_broadcast_init();
> >>         if ( !hpet_broadcast_is_available() )
> >>         {
> >>             if ( xen_cpuidle == -1 )
> >>             {
> >>                 xen_cpuidle = 0;
> >>                 printk("CPUIDLE: disabled due to no HPET. "
> >>                        "Force enable with 'cpuidle'.\n");
> >>             }
> >>             else
> >>             {
> >>                 printk("HPET broadcast init failed, turn to PIT
> >> broadcast.\n");
> >>                 return 0;
> >>             }
> >>         }
> >>     }
> >> 
> >> 
> >> Neither of the messages above appear in the dmesg on my 
> Xeon based xen
> >> servers, and they only enter C1 state, I've tried adding cpuidle to
> >> the xen kernel parameters but it makes no difference.
> >> 
> >> I'm probably just not understanding the code properly but 
> it doesn't
> >> look like it would behave as the documentation or commit comments
> >> suggest it should....
> >> 
> >> Andy
> >> 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@xxxxxxxxxxxxxxxxxxx
> >> http://lists.xensource.com/xen-devel
> > 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel