In this thread, I observed that I was unable to
provoke deep C state (C3) on my Dell D630, which has
a Intel Merom (dual-core laptop) processor. At that
time, when I tried enabling hpetbroadcast, dom0 boot failed.
As it turned out, all RHEL5-based (maybe RHEL4- also) dom0
default installation run /sbin/hwclock, which IIRC takes
the RTC away from Xen and gives it to dom0. Since the
Xen hpet emulation does not do RTC emulation, bad things
then happen when a deep Cstate is entered (dom0 apparently
never wakes up). I think Ke Yu has also reproduced this problem.
Sometime in the last few weeks, some patch in xen-unstable
apparently changed some defaults and xen-unstable will
no longer boot with this processor/dom0, with or without
hpetbroadcast on the Xen command line. However, specifying
max_cstate=2 on the Xen command line allows a successful
dom0 boot, so I suspect the problem is the same (or at
least very similar).
I did a quick scan for hpet changes and found c/s 20497,
but backing it out made no difference.
I have a workaround for now, but since it is likely that
many customers (including all of Oracle's OVS customers)
use a RHEL5-based dom0 boot sequence, and Merom processors
work fine otherwise, it would be nice to get this identified
and fixed before 4.0.
Xen-devel mailing list