[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.