> case, if convenient, could you help to do some bisect to see
> which cset cause this bug?
I can do this, but because it is often no longer easy to
bisect Xen because of interdependencies with other
components, I was hoping that Keir or you or someone might
have some idea of what changeset might have caused the regression.
But I'll give bisecting a try.
> max_cstate=2), when dom0 hangs, is xen still alive, E.g. can
> Xen response to three Ctrl-'A' in serial?
Unfortunately, I can't seem to get a Xen console working on
the Merom machine, and the problem can't be reproduced on
my other machine where the Xen console is working (because
Conroe doesn't support deep C).
> -----Original Message-----
> From: Yu, Ke [mailto:ke.yu@xxxxxxxxx]
> Sent: Tuesday, December 08, 2009 12:08 AM
> To: Dan Magenheimer; Xen-Devel (E-mail)
> Subject: RE: latest xen-unstable fails to boot on Dell D630 (likely
> hpet/Cstate problem)
>
>
> >-----Original Message-----
> >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.
> >
> >http://lists.xensource.com/archives/html/xen-devel/2009-10/ms
> g01027.html
> >
> >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.
>
> Let's firstly figure out which component the issue resides.
>
> Firstly, in the default boot (i.e. without specifying
> max_cstate=2), when dom0 hangs, is xen still alive, E.g. can
> Xen response to three Ctrl-'A' in serial?
>
> If only dom0 hangs, it is probably that RTC malfunction make
> incorrect dom0 time and lead dom0 fail to boot. Then RTC
> emulation in hypervisor should fix this issue.
>
> If Xen also hangs, it should be another bug, i.e. hpet
> broadcast does not wake up CPU in deep C states. in this
> case, if convenient, could you help to do some bisect to see
> which cset cause this bug?
>
> Best Regards
> Ke
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home