From: Atom2 <ariel.atom2@web2web.at>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Roger Pau Monne <roger.pau@citrix.com>,
xen-users@lists.xenproject.org
Subject: Re: [Xen-users] substantial shutdown delay for PV guests with PCI -passthrough
Date: Wed, 19 Mar 2014 01:25:39 +0100 [thread overview]
Message-ID: <5328E403.8010506@web2web.at> (raw)
In-Reply-To: <1395155249.12847.66.camel@kazak.uk.xensource.com>
Am 18.03.14 16:07, schrieb Ian Campbell:
> On Tue, 2014-03-18 at 14:01 +0100, Atom2 wrote:
> [...]
>> So I guess probably not too much of value ...
>
> Unfortunately not, but thanks anyway, it's good to check.
>
>>> While the domain is happily running can you provide the output of
>>> "xenstore-ls -fp" -- I'm curious what state pciback is in. It should be
>>> 4, if not then that would be the problem.
>> Full output of xenstore-ls -fp (from dom0) is attached as it is 627
>> lines long and I am not quiet sure what you are actually after): There's
>> nothing in it that reads pciback; there are however a few entries named
>> /local/domain/0/backend/pci
>> and for one of the subentries named 3/0/state (3 is the domain-id)
>> the value seems to be 4:
>> /local/domain/0/backend/pci/3/0/state = "4" (n0,r3)
>
> Yes, this is the one which libxl appears to be looking for and it is set
> to "4" which is what libxl is looking for.
>
> Please can you try this again but take the dump while the destruction is
> going on, i.e. in among the 10s delays somewhere (I don't think where
> exactly will matter. I don't see it in the logs but I'm wondering if the
> pciback directory is getting torn down too soon.
>
O.K. - that's what I have done: I created a loop at the shell prompt in
dom0 that executes 'xenstore-ls -fp' for a total of 16 times with a
delay of one second between invocations and stores each output in a
separate file with an extension that counts up from 0. I have started
that "script" just before the "reboot: System halted" message appeared
in the domU, so at least the first file must still contain the info
prior to the 10s delay when the domU is still sort of up and running.
The output below is the result of
grep -E '/local/domain/(0|8)/(backend|device)/pci/.*/state' xenstore.n
where the domain id this time was 8 and n is the counter of my loop.
Please find the output below:
.0 and .1 file:
/local/domain/0/backend/pci/8/0/state = "4" (n0,r8)
/local/domain/0/backend/pci/8/0/state-0 = "3" (n0,r8)
/local/domain/0/backend/pci/8/0/state-1 = "3" (n0,r8)
/local/domain/0/backend/pci/8/0/state-2 = "3" (n0,r8)
/local/domain/0/backend/pci/8/0/state-3 = "3" (n0,r8)
/local/domain/8/device/pci/0/state = "4" (n8,r0)
.2 upto .15 file:
/local/domain/0/backend/pci/8/0/state = "6" (n0,r8)
/local/domain/0/backend/pci/8/0/state-0 = "3" (n0,r8)
/local/domain/0/backend/pci/8/0/state-1 = "3" (n0,r8)
/local/domain/0/backend/pci/8/0/state-2 = "3" (n0,r8)
/local/domain/0/backend/pci/8/0/state-3 = "3" (n0,r8)
/local/domain/8/device/pci/0/state = "6" (n8,r0)
So it seems that pretty much at the start of the 10s delay the state
changed from 4 to 6 and stays at that value even after the first 10s
delay is over - whatever that means.
And for the sake of being complete:
Below is the output from starting the domain prior to the grub menu
showing on screen. There is one device with which xl seems to have an
issue (for which I still have to find and compile a driver anyway), but
I think that's unrelated because if I drop that one device from being
passed through, the delay of 10s per remaining device nevertheless remains.
===========================
Parsing config from 5:voip.9
libxl: error: libxl_pci.c:990:libxl__device_pci_reset: The kernel
doesn't support reset from sysfs for PCI device 0000:09:02.0
Daemon running with PID 4759
Xen Minimal OS!
start_info: 0xbab000(VA)
nr_pages: 0x40000
shared_inf: 0xdb4f9000(MA)
pt_base: 0xbae000(VA)
nr_pt_frames: 0xb
mfn_list: 0x9ab000(VA)
mod_start: 0x9aa000(VA)
mod_len: 4096
flags: 0x0
cmd_line:
stack: 0x9690e0-0x9890e0
MM: Init
_text: 0x0(VA)
_etext: 0x7b4c5(VA)
_erodata: 0x96000(VA)
_edata: 0x9bd20(VA)
stack start: 0x9690e0(VA)
_end: 0x9a96e0(VA)
start_pfn: bbc
max_pfn: 40000
Mapping memory range 0x1000000 - 0x40000000
setting 0x0-0x96000 readonly
skipped 0x1000
MM: Initialise page allocator for db4000(db4000)-40000000(40000000) MM: done
Demand map pfns at 40001000-2040001000.
Heap resides at 2040002000-4040002000.
Initialising timer interface
Initialising console ... done.
gnttab_table mapped at 0x40001000.
Initialising scheduler
Thread "Idle": pointer: 0x2040002050, stack: 0xfd0000
Thread "xenstore": pointer: 0x2040002800, stack: 0xfe0000
xenbus initialised on irq 1 mfn 0x7a512a
Thread "shutdown": pointer: 0x2040002fb0, stack: 0xff0000
Dummy main: start_info=0x9891e0
Thread "main": pointer: 0x2040003760, stack: 0x1000000
"main"
vbd 51713 is hd0
******************* BLKFRONT for device/vbd/51713 **********
Shutting down ()
Shutdown requested: 3
Thread "shutdown" exited.
backend at /local/domain/0/backend/vbd/8/51713
16777216 sectors of 512 bytes
**************************
vbd 51714 is hd1
******************* BLKFRONT for device/vbd/51714 **********
backend at /local/domain/0/backend/vbd/8/51714
2097152 sectors of 512 bytes
**************************
vbd 51715 is hd2
******************* BLKFRONT for device/vbd/51715 **********
backend at /local/domain/0/backend/vbd/8/51715
2097152 sectors of 512 bytes
**************************
===========================
Thanks Atom2
next prev parent reply other threads:[~2014-03-19 0:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5325B828.1060303@web2web.at>
[not found] ` <1395050430.4122.29.camel@kazak.uk.xensource.com>
[not found] ` <53273B3C.40707@web2web.at>
2014-03-18 10:15 ` [Xen-users] substantial shutdown delay for PV guests with PCI -passthrough Ian Campbell
2014-03-18 13:01 ` Atom2
2014-03-18 15:07 ` Ian Campbell
2014-03-19 0:25 ` Atom2 [this message]
2014-03-19 11:26 ` Ian Campbell
2014-03-19 13:00 ` Konrad Rzeszutek Wilk
2014-03-19 14:03 ` Atom2
2014-03-19 15:45 ` Ian Jackson
2014-03-20 2:31 ` Atom2
2014-03-20 11:52 ` Ian Jackson
2014-03-20 13:53 ` Pasi Kärkkäinen
2014-03-20 15:28 ` Ian Jackson
2014-03-20 19:34 ` Atom2
2014-03-20 19:32 ` Atom2
2014-03-21 18:11 ` Ian Jackson
2014-03-21 19:39 ` Atom2
2014-04-02 14:44 ` Ian Jackson
2014-04-02 15:17 ` Atom2
2014-04-18 21:47 ` Atom2
2014-04-19 0:12 ` Konrad Rzeszutek Wilk
2014-04-19 18:59 ` Atom2
2014-04-22 10:44 ` George Dunlap
2014-04-22 12:02 ` Atom2
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5328E403.8010506@web2web.at \
--to=ariel.atom2@web2web.at \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xen.org \
--cc=xen-users@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).