xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Andre Przywara <andre.przywara@calxeda.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [ARM] Bash often segfaults in Dom0 with the latest Xen
Date: Wed, 05 Jun 2013 19:36:00 +0100	[thread overview]
Message-ID: <51AF8510.1090907@linaro.org> (raw)
In-Reply-To: <CAMJs5B_tyJUxy8w1rtw5y5FbJf+tPPoQ=cRmGjbip5_1oXJWaA@mail.gmail.com>

On 06/05/2013 07:17 PM, Christoffer Dall wrote:

> On 5 June 2013 11:01, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Wed, 5 Jun 2013, Christoffer Dall wrote:
>>> On 5 June 2013 10:53, Julien Grall <julien.grall@linaro.org> wrote:
>>>> On 06/05/2013 06:36 PM, Christoffer Dall wrote:
>>>>
>>>>>>
>>>>>> I'm using the linaro's branch ll_20130528.0, I have only few patches for
>>>>>> the dts and not yet in linaro tree patches.
>>>>>>
>>>>>> I have the same issue with linux 3.9-rc4 with multiple CPUs and I can't
>>>>>> really go before without carrying many xen patches to try it.
>>>>>>
>>>>>> I have tried different configuration with the number of CPUs in Xen
>>>>>> (pCPU) and linux (vCPU):
>>>>>>   - 2 pCPU 2 vCPU : segfaulting
>>>>>>   - 2 pCPU 1 vCPU : working
>>>>>>   - 1 pCPU 1 vCPU : working
>>>>>>   - 1 pCPU 2 vCPU : very slow but working
>>>>>>
>>>>> 2 pCPU 1 vCPU are you still compiling your dom0 as an SMP kernel, but
>>>>> only creating 1 vCPU or are you actually compiling the dom0 as UP?
>>>>
>>>>
>>>> Yes. It's same kernel with the same command line (ie without nosmp).
>>>> I have limited the number of dom0 vcpus with dom0_max_vcpus=1 on xen
>>>> command line.
>>>>
>>> It indicates a bug in Xen then. Curious that it only happens for user
>>> space in dom0, but perhaps you just haven't seen it in the kernel yet.
>>> Bash scripts are pretty intensive on page faults so perhaps there's a
>>> synchronization issue with some of your page fault handlers.
>>>
>>> You could try to touch all the memory inside dom0 (dd to a ramfs for
>>> example) and then run your bash script and see if the problem still
>>> occurs, that should point you to whether it's a stage-2 fault handling
>>> issue, but this is not a fool-proof approach. Maybe Xen can
>>> pre-allocate all the stage-2 entries?
>>
>> Xen pre-allocates all the memory for stage-2 entries (no overcommit or
>> populate on demand by default)
> 
> what was the conclusion when pinning the vcpu to dedicated pcpus - did
> the error still show up?


If I have 2 pCPU (CPU 0 and CPU 2) and 1 vCPU which is moving every 2
second between the pCPUs, Linux will freeze each time the vcpu is
running on CPU 1. I'm not sure why, perhaps another issue.

As Stefano advised me, I will setup the debugger on the arndale tomorrow
and see if I can find something.

-- 
Julien

  reply	other threads:[~2013-06-05 18:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-04 22:45 [ARM] Bash often segfaults in Dom0 with the latest Xen Julien Grall
2013-06-05  1:38 ` Christoffer Dall
2013-06-05  9:52   ` Ian Campbell
2013-06-05 11:48   ` Julien Grall
2013-06-05 14:30     ` Christoffer Dall
2013-06-05 15:18       ` Ian Campbell
2013-06-05 16:12       ` Julien Grall
2013-06-05 16:46         ` Stefano Stabellini
2013-06-05 17:36         ` Christoffer Dall
2013-06-05 17:53           ` Julien Grall
2013-06-05 17:57             ` Christoffer Dall
2013-06-05 18:01               ` Stefano Stabellini
2013-06-05 18:17                 ` Christoffer Dall
2013-06-05 18:36                   ` Julien Grall [this message]
2013-06-11 11:48   ` Julien Grall
2013-06-11 14:25     ` Christoffer Dall
2013-06-05  9:38 ` Ian Campbell
2013-06-05 10:39   ` Julien Grall

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=51AF8510.1090907@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=Ian.Campbell@citrix.com \
    --cc=andre.przywara@calxeda.com \
    --cc=christoffer.dall@linaro.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.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).