> -----Original Message-----
> From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxxxxx]
> Sent: 13 April 2007 17:35
> To: Petersson, Mats
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] A different probklem with
> save/restore on C/S 14823.
>
> Hi,
>
> At 18:24 +0200 on 13 Apr (1176488676), Petersson, Mats wrote:
> > I'm not seeing the problem that Fan Zhao is reporting, instead I get
> > this one. Not sure if ti's the same one or a different
> problem... This
> > happens with my simple-guest [i.e. not using hvmloader, as
> I described
> > before]. This worked fine yesterday.
>
> This looks like the same problem (but caught in Xen instead of
> crashing). The restore path isn't setting the ioreq page's PFN
> properly. Have you reinstalled your tools (in particular
> libxenguest)
> since cset 14830:e3b3800c769a ?
After some more testing, I would agree that it's probably the same
problem - I found that I could reproduce the same problem if I use a
sles93 guest rather than the simple guest - not sure why it's different
(perhaps because the sles guest uses MMIO and my simple guest never uses
MMIO?)
It would perhaps be nice to understand why one type of guest only
crashes the guest (kind of not so bad) and the other crashes the
hypervisor (quite bad) and make BOTH crash the guest only? [Not that it
REALLY fixes a problem, but leaving the hypervisor running if the guest
is broken is a good thing, I think. [perhaps not a priority for 3.0.5,
but I think it should be fixed - I'll have a look to see if I can
understand what's going on and I can cobble together something that
catches both cases].
I'm always a bit wary of using (wholesale) changesets from the staging
tree, under the assumption that if they don't pass the basic testing,
it's quite possible that it won't work for me either. Obviously, if I
understand a particular change, and I think it won't need a whole bunch
of others, I may pick a single (or small subset) of staging for test
purposes. But 14823 is the latest available on unstable. [You must be
mind-reading, as you just apologized for not realizing it's not out of
staging yet].
--
Mats
>
> Cheers,
>
> Tim.
>
> > (XEN) event_channel.c:178:d0 EVTCHNOP failure: domain 0,
> error -22, line
> > 178
> > (XEN) bad shared page: 0
> > (XEN) domain_crash_sync called from platform.c:844
> > (XEN) Domain 20 (vcpu#0) crashed on cpu#1:
>
> --
> Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, XenSource UK Limited
> Registered office c/o EC2Y 5EB, UK; company number 05334508
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home