WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Disabling cirrus-vga

To: "Stefano Stabellini" <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Disabling cirrus-vga
From: "billy lau" <billylau@xxxxxxxxx>
Date: Mon, 15 Dec 2008 20:48:22 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Jun Koi <junkoi2004@xxxxxxxxx>
Delivery-date: Mon, 15 Dec 2008 17:48:56 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=YxpwurC1cPsH881IN7G9Gs+HhU5xGXzgRMrCDGA/7DU=; b=A+wRph9LNQUVTZoswEmk878pEDRlZJCU7dOOoaZFNjyrJxYQ1VqDOQjeIgRdkvBzf/ QK+vcDT2o6mVRgbLZjnSoMefJ8XxQlSvEU6NMpK3vxFV1EK/L8mLP4pDAeE+hUVthAHv JBfbBH1DymeaqyTByifl+hvhUM6SlNNsaGUTg=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=S5I39pvS2R7jakjgwt2+Jk2T4+8He5wYccpYi7RpQ5Yu3BBLIGe2DaoqmmqzQSuzRE F58l0c3+QzAiLJPV2v27ImxfuZCHzsN4288NKbsbcx3C4jqaf4RDI02bLfeQgcNJXhaP UYa11BjjzfsDif+noFVHqIWB38jMSTFU6hkWE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49464844.6000107@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <6b5ba5140812111649r4275a3cu3ece54d56965a733@xxxxxxxxxxxxxx> <6b5ba5140812112130xcb532e8r5256651d2b37be86@xxxxxxxxxxxxxx> <49423DF4.4060709@xxxxxxxxxxxxx> <6b5ba5140812120446q7afb3244of5e705a1e6e7b274@xxxxxxxxxxxxxx> <6b5ba5140812121658u630657f0i232b6971d46d26f1@xxxxxxxxxxxxxx> <fdaac4d50812121858t6565c195y6779a38a8cf2940d@xxxxxxxxxxxxxx> <6b5ba5140812150136j7b421feeq5656478c122663de@xxxxxxxxxxxxxx> <4946357C.6090206@xxxxxxxxxxxxx> <6b5ba5140812150258v524eac52rd62ebc1278f498c9@xxxxxxxxxxxxxx> <49464844.6000107@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Okay, I have rechecked my codes, it is similar to what is done with your patch. This time, I tried a linux hvm guest as well. And it happens that this is in my xen log when i do a xm log:

[2008-12-15 20:25:47 2588] DEBUG (__init__:1072) Waiting for devices vif.
[2008-12-15 20:25:47 2588] DEBUG (__init__:1072) XendDomainInfo.handleShutdownWatch
[2008-12-15 20:25:47 2588] DEBUG (__init__:1072) Waiting for 0.
[2008-12-15 20:25:47 2588] DEBUG (__init__:1072) hotplugStatusCallback /local/domain/0/backend/vif/1/0/hotplug-status.
[2008-12-15 20:25:47 2588] DEBUG (__init__:1072) hotplugStatusCallback 1.
[2008-12-15 20:25:47 2588] DEBUG (__init__:1072) Waiting for devices vscsi.
[2008-12-15 20:25:47 2588] DEBUG (__init__:1072) Waiting for devices vbd.
[2008-12-15 20:25:47 2588] DEBUG (__init__:1072) Waiting for 768.
[2008-12-15 20:25:47 2588] DEBUG (__init__:1072) hotplugStatusCallback /local/domain/0/backend/vbd/1/768/hotplug-status.
[2008-12-15 20:25:47 2588] DEBUG (__init__:1072) hotplugStatusCallback 1.
[2008-12-15 20:25:47 2588] DEBUG (__init__:1072) Waiting for 5632.
[2008-12-15 20:25:47 2588] DEBUG (__init__:1072) hotplugStatusCallback /local/domain/0/backend/vbd/1/5632/hotplug-status.
[2008-12-15 20:25:48 2588] DEBUG (__init__:1072) hotplugStatusCallback /local/domain/0/backend/vbd/1/5632/hotplug-status.
[2008-12-15 20:25:48 2588] DEBUG (__init__:1072) hotplugStatusCallback 1.
[2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices irq.
[2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices vkbd.
[2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices vfb.
[2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices console.
[2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for 0.
[2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices pci.
[2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for 0.
[2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices ioports.
[2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices tap.
[2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices vtpm.
[2008-12-15 20:25:48 2588] INFO (__init__:1072) Domain linux-test (1) unpaused.
[2008-12-15 20:25:55 2588] WARNING (__init__:1072) domain linux-test: device model failure: pid 2999: died due to signal 7; see /var/log/xen/qemu-dm-linux-test.log


But, again, looking at qemu-dm-linux-test.log, there is no error message:
domid: 1
qemu: the number of cpus is 1
config qemu network with xen bridge for  tap1.0 xenbr0
Watching /local/domain/0/device-model/1/logdirty/next-active
Watching /local/domain/0/device-model/1/command
xs_read(): vncpasswd get error. /vm/e9ccff9f-dc55-89e3-612f-5c4cad69cd87/vncpasswd.
qemu_map_cache_init nr_buckets = 10000 size 3145728
shared page at pfn 3fffe
buffered io page at pfn 3fffc
Time offset set 0
register_real_device: Assigning real physical device 02:00.0 ...
pt_register_regions: IO region registered (size=0x01000000 base_addr=0xfa000000)
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xd0000000)
pt_register_regions: IO region registered (size=0x02000000 base_addr=0xf8000000)
pt_register_regions: IO region registered (size=0x00000080 base_addr=0x0000dc80)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xfbd00000)
register_real_device: Real physical device 02:00.0 registered successfuly!
Register xen platform.
Done register platform.
xs_read(/local/domain/0/device-model/1/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): /home/billy/Desktop/debian-40r5-i386-netinst.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
pt_iomem_map: e_phys=f0000000 maddr=f8000000 type=0 len=33554432 index=3 first_map=1
pt_iomem_map: e_phys=f3000000 maddr=fa000000 type=0 len=16777216 index=0 first_map=1
pt_iomem_map: e_phys=f4000000 maddr=fbd00000 type=8 len=131072 index=6 first_map=1
pt_ioport_map: e_phys=c200 pio_base=dc80 len=128 index=5 first_map=1

and it just ends there. xm list shows me this, which is the same as before, without state status:
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                    0  2951     4     r-----     15.9
linux-test                                     1  1024     1     ------      5.5

So, I guess the question is, what does it mean by device model failure due to signal 7?

thanks,
- billy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>