It's certainly plausible. If you can confirm it then I'll revert it.
On 4/2/08 06:38, "You, Yongkang" <yongkang.you@xxxxxxxxx> wrote:
> On Sunday, February 03, 2008 6:30 PM, "Keir Fraser" wrote:
> Hi Keir and Haicheng,
> I found this issue might be caused by 16947.
> After revert 16947 and rebuild the qemu-dm, HVM domains can boot up
>> You'll have to selectively remove changesets. A good starting point
>> would be:
>> hg update 16955
>> hg export 16954 | patch -Rp1
>> hg export 16949 | patch -Rp1
>> hg export 16946 | patch -Rp1
>> ...and see if you can reproduce the problem. If you can, it is one of
>> changesets 16947, 16948, 16950, 16951, 16952, 16953, 16955. Otherwise
>> it is one of 16946, 16949, 16954, 16956, 16957, 16958.
>> -- Keir
>> On 3/2/08 09:08, "Li, Haicheng" <haicheng.li@xxxxxxxxx> wrote:
>>> Thanks for the quick response. I have tried to locate the exact
>>> changeset, but from c/s 16946 to c/s 16957, most of them cannot get
>>> tools compiled successfully. To help us better track this issue, I
>>> filed a bug in bugzilla:
>>> -- haicheng
>>> -----Original Message-----
>>> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>>> Sent: 2008年2月3日 16:54
>>> To: Li, Haicheng; xen-devel
>>> Subject: Re: [Xen-devel] most of qcow images cannot boot since c/s
>>> I'm not sure what causes that. Hanging 'xm destroy' is because
>>> qemu-dm is
>>> now killed by SIGTERM rather than SIGKILL. I think that was a
>>> mistake to change, so I'll probably revert that. But it doesn't
>>> explain why your
>>> qemu-dm went bad in the first place. I think you will have to work
>>> out exactly which changeset caused the problem.
>>> -- Keir
>>> On 3/2/08 07:48, "Li, Haicheng" <haicheng.li@xxxxxxxxx> wrote:
>>>> Hi all,
>>>> We found since c/s 16958, most of our qcow images will hang on
>>>> boot; xm dmesg shows: (XEN) HVM3: int13_harddisk: function 41,
>>>> unmapped device for ELDL=81 (XEN) HVM3: int13_harddisk: function
>>>> 08, unmapped device for ELDL=81 (XEN) HVM3: *** int 15h function
>>>> AX=00C0, BX=0000 not yet supported!
>>>> When this hang happens, "xm destroy" command cannot destroy that
>>>> domain any more; and xend will lose response after running "xm
>>>> destroy" until this qemu process is killed by "kill -9".
>>>> This issue blocks our testing. And c/s 16945 has no such issue.
>>>> Detailed xm dmesg log is attached.
> Best Regards,
> Yongkang You
Xen-devel mailing list