[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] why are deep cstates disabled?


  • To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Mon, 19 Oct 2009 21:06:08 +0100
  • Cc:
  • Delivery-date: Mon, 19 Oct 2009 13:06:43 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcpQ7coN8j1VoK1xQQaCshx7j2otnAACc59w
  • Thread-topic: [Xen-devel] why are deep cstates disabled?

On 19/10/2009 19:55, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.