[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] DomU crashes with device_model_stubdomain_override=1 under Xen 4.5.0
On Fri, Feb 20, 2015 at 09:21:51PM +0100, Kuba wrote: > W dniu 2015-02-18 o 14:43, Paul Durrant pisze: > >>-----Original Message----- > >>From: Ian Campbell > >>Sent: 18 February 2015 13:38 > >>To: Kuba; Wei Liu; Paul Durrant > >>Cc: xen-users@xxxxxxxxxxxxx > >>Subject: Re: [Xen-users] DomU crashes with > >>device_model_stubdomain_override=1 under Xen 4.5.0 > >> > >>On Mon, 2015-02-16 at 22:33 +0100, Kuba wrote: > >> > >>Wei/Paul, I suppose this is the ioreq server related regression which > >>was discovered and discussed on xen-devel recently? > >> > > > >Certainly sounds like it. The symptom was hvmloader() bailing because PCi > >enumeration got screwed up. > > > >>I'm still catching up on my email backlog from being away -- what's the > >>status of the fix? > > > >I posted a fix (in Xen) to the list a couple of weeks back and Jan committed > >it on Feb 10th: > > > >http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=dd748d128d86996592afafea02e578cc7d4e6d42 > > > >I don't see it in the stable-4.5 branch yet though. > > > > Paul > > > >> > >>>Dear List, > >>> > >>>I'm trying to bring up an HVM domain with > >>> > >>>device_model_stubdomain_override=1 > >>> > >>>under Xen 4.5.0, but the domain always crashes just after creation. > >>>Everything works flawlessly in Xen 4.4.x. Under 4.5.0 the domain starts > >>>just fine if I change that line to "device_model_stubdomain_override=0". > >>> > >>>I'm using stub domains because they allow me to use storage driver > >>domains. > >>> > >>># xl -vvv create consumer.conf &> create.log > >>># xl list > >>>Name ID Mem VCPUs State Time(s) > >>>Domain-0 0 6144 4 r----- 36.1 > >>>consumer 10 255 1 ---sc- 0.0 > >>>consumer-dm 11 32 1 -b---- 0.1 > >>> > >>>There is no output in the VNC console. > >>> > >>>The logs are from Xen compiled with debug ?= y, verbose ?= y and > >>>crash_debug ?= y, but the same happens with non-debug build. > >>> > >>>My consumer.conf: > >>> > >>>name='consumer' > >>>device_model_stubdomain_override=1 > >>>builder='hvm' > >>>vcpus=1 > >>>memory=256 > >>>disk=[ > >>>#'file:/root/fbsd.iso,xvda,r,devtype=cdrom' > >>>] > >>>boot='d' > >>>pae=1 > >>>nx=1 > >>>videoram=16 > >>>stdvga=1 > >>>sdl=0 > >>>vnc=1 > >>>vnclisten="0.0.0.0" > >>>vncdisplay=31 > >>>localtime=1 > >>>xen_platform_pci=1 > >>>on_crash="preserve" > >>> > >>>I've ran out of ideas and I'd be very grateful for any advice on how to > >>>find the cause of this issue. > >>> > >>>Best regards, > >>>Kuba > > I have applied Paul's patch to Xen 4.5.0 and it seems to resolve the issue:) > Thank you! > > Now, unfortunately, adding a vif crashes the stub domain: > > # xl list > Name ID Mem VCPUs State Time(s) > Domain-0 0 6144 4 r----- 12.2 > consumer 3 239 1 ------ 0.0 > consumer-dm 4 32 1 ---sc- 0.0 > > This happens with both standard Linux bridge and Open vSwitch using: > vif=['bridge=xenbr0'] I have the same setting here. It works for me. Keep in mind though I have my own patch series applied that fixes stubdom startup issues. I.e. I'm not using Paul's workaround. If you're interested, search for "Fix QEMU startup protocol" on xen-devel. Note that that series is *not* going to be backported to 4.5 since it changes stubdom's startup protocol. > or > vif=['script=vif-openvswitch,bridge=xenbr0'] > > Similar errors come up in both cases in qemu-dm-consumer.log: > > ************************ NETFRONT for device/vif/0 ********** > > > net TX ring size 256 > net RX ring size 256 > backend at /local/domain/0/backend/vif/4/0 > mac is 00:16:3e:4f:92:50 > backend not avalable, state=5 > TAP open failed This doesn't look right. Unfortunately this is too little information to make any judgement. Could you paste in the whole log file? Wei. > Could not initialize device 'tap' > close(0) > close(1) > close(2) > main returned 1 > Do_exit called! > base is 0x5efa00 caller is 0x101c52 > base is 0x5efa10 caller is 0xe4fe8 > base is 0x5efa30 caller is 0xe5b09 > base is 0x5efa60 caller is 0x102acb > base is 0x5efa80 caller is 0x8744 > base is 0x5efe10 caller is 0xe5a7d > base is 0x5effe0 caller is 0x343b > > I'd be very grateful for further assistance. Everything works fine with > device_model_stubdomain_override=0 using both linux bridge and ovs. > > Any help will be much appreciated. > > Best regards, > Kuba _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxx http://lists.xen.org/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |