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: billy lau <billylau@xxxxxxxxx>
Subject: Re: [Xen-devel] Disabling cirrus-vga
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Tue, 16 Dec 2008 11:36:26 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Jun Koi <junkoi2004@xxxxxxxxx>
Delivery-date: Tue, 16 Dec 2008 03:36:48 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <6b5ba5140812151748p2138d5das762eae2542d726c5@xxxxxxxxxxxxxx>
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> <6b5ba5140812151748p2138d5das762eae2542d726c5@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.14 (X11/20080505)
billy lau wrote:

> 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?

It means qemu died because it received a SIGBUS signal; the problem
seems to be related to the ioport or memory mapping of passthrough device.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>