OK - I see. thanks a lot.
On Thu, Nov 20, 2014 at 6:15 PM, Stefano Stabellini <
stefano.stabell...@eu.citrix.com> wrote:
> Already posted:
>
> http://marc.info/?l=xen-devel&m=141648092100568
>
> Ian hasn't provided any feedback yet.
>
> On Thu, 20 Nov 2014, Andrii Tseglytskyi wrote:
> > I think I
Already posted:
http://marc.info/?l=xen-devel&m=141648092100568
Ian hasn't provided any feedback yet.
On Thu, 20 Nov 2014, Andrii Tseglytskyi wrote:
> I think I'll debug this a bit later - unfortunately, now don't have
> time for this. But I want to get rid of spurious interrupt here.
>
> BTW -
I think I'll debug this a bit later - unfortunately, now don't have
time for this. But I want to get rid of spurious interrupt here.
BTW - Stefano are you going to post the patch that we created
yesterday ? Will Ian accept it?
Regards,
Andrii
On Thu, Nov 20, 2014 at 1:15 PM, Julien Grall wrote:
On 11/20/2014 10:28 AM, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> 19 лист. 2014 20:32, користувач "Stefano Stabellini"
>> написав:
>>>
>>> On Wed, 19 Nov 2014, Julien Grall wrote:
On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> That's right, the ma
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> 19 лист. 2014 20:32, користувач "Stefano Stabellini"
> написав:
> >
> > On Wed, 19 Nov 2014, Julien Grall wrote:
> > > On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > > > That's right, the maintenance interrupt handler is not called, but it
>
19 лист. 2014 20:32, користувач "Stefano Stabellini" <
stefano.stabell...@eu.citrix.com> написав:
>
> On Wed, 19 Nov 2014, Julien Grall wrote:
> > On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > > That's right, the maintenance interrupt handler is not called, but it
> > > doesn't do anything
On Wed, 19 Nov 2014, Julien Grall wrote:
> On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > That's right, the maintenance interrupt handler is not called, but it
> > doesn't do anything so we are fine. The important thing is that an
> > interrupt is sent and git_clear_lrs gets called on hyperv
On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> That's right, the maintenance interrupt handler is not called, but it
> doesn't do anything so we are fine. The important thing is that an
> interrupt is sent and git_clear_lrs gets called on hypervisor entry.
It would be worth to write down this
That's right, the maintenance interrupt handler is not called, but it
doesn't do anything so we are fine. The important thing is that an
interrupt is sent and git_clear_lrs gets called on hypervisor entry.
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> The only ambiguity left - maintenance inter
The only ambiguity left - maintenance interrupt handler is not called.
It was requested for specific IRQ number, retrieved from device tree.
But when we trigger GICH_HCR_UIE - we got maintenance interrupt for
spurious number 1023.
Regards,
Andrii
On Wed, Nov 19, 2014 at 7:47 PM, Andrii Tseglytsky
On Wed, Nov 19, 2014 at 7:42 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
>> wrote:
>> > I think that's OK: it looks like that on your board for some reasons
>> > when UIE is set you get irq
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
>
> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
> wrote:
> > I think that's OK: it looks like that on your board for some reasons
> > when UIE is set you get irq 1023 (spurious interrupt) instead of your
> > normal maintenance i
No, it just means "spurious interrupt".
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Does number 1023 mean that maintenance interrupt is global?
>
> On Wed, Nov 19, 2014 at 7:03 PM, Andrii Tseglytskyi
> wrote:
> > I got this strange log:
> >
> > (XEN) received maintenance interrupt irq=1023
Hi Stefano,
On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
wrote:
> I think that's OK: it looks like that on your board for some reasons
> when UIE is set you get irq 1023 (spurious interrupt) instead of your
> normal maintenance interrupt.
OK, but I think this should be investigated too. W
I think that's OK: it looks like that on your board for some reasons
when UIE is set you get irq 1023 (spurious interrupt) instead of your
normal maintenance interrupt.
But everything should work anyway without issues.
This is the same patch as before but on top of the lastest xen-unstable
tree.
Does number 1023 mean that maintenance interrupt is global?
On Wed, Nov 19, 2014 at 7:03 PM, Andrii Tseglytskyi
wrote:
> I got this strange log:
>
> (XEN) received maintenance interrupt irq=1023
>
> And platform does not hang due to this:
> +hcr = GICH[GICH_HCR];
> +if ( hcr & GICH_HCR_UI
I got this strange log:
(XEN) received maintenance interrupt irq=1023
And platform does not hang due to this:
+hcr = GICH[GICH_HCR];
+if ( hcr & GICH_HCR_UIE )
+{
+GICH[GICH_HCR] &= ~GICH_HCR_UIE;
+uie_on = 1;
+}
On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
No, that's for requesting a maintenance interrupt for a specific irq
when it is EOI'ed by the guest.
In our case we are requesting maintenance interrupts via UIE: a single
global maintenance interrupt when most LRs become free.
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> BTW - shouldn't this
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >> wrote:
> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >> >
BTW - shouldn't this flag GICH_LR_MAINTENANCE_IRQ be set after
maintenance interrupt requesting ?
On Wed, Nov 19, 2014 at 6:32 PM, Andrii Tseglytskyi
wrote:
> Gic dump during interrupt requesting:
>
> (XEN) GICH_LRs (vcpu 0) mask=f
> (XEN)HW_LR[0]=3a1f
> (XEN)HW_LR[1]=9a015856
> (XEN)
Gic dump during interrupt requesting:
(XEN) GICH_LRs (vcpu 0) mask=f
(XEN)HW_LR[0]=3a1f
(XEN)HW_LR[1]=9a015856
(XEN)HW_LR[2]=1a1b
(XEN)HW_LR[3]=9a00e439
(XEN) Inflight irq=31 lr=0
(XEN) Inflight irq=86 lr=1
(XEN) Inflight irq=27 lr=2
(XEN) Inflight irq=57 lr=3
(XEN) Infligh
On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>> wrote:
>> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>> > wrote:
>> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> wrote:
> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> > wrote:
> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> Hi Stefano,
> >>>
> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefa
On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
wrote:
> On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> wrote:
>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> Hi Stefano,
>>>
>>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>>> wrote:
>>> > On Wed, 19 Nov 2014, Andrii Tse
On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>> wrote:
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi Stefano,
>> >>
>> >> > > if ( !list_empt
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
>
> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi Stefano,
> >>
> >> > > if ( !list_empty(¤t->arch.vgic.lr_pending) && lr_all_full()
> >> > > )
> >> > > -
Hi Stefano,
On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> > > if ( !list_empty(¤t->arch.vgic.lr_pending) && lr_all_full() )
>> > > -GICH[GICH_HCR] |= GICH_HCR_UIE;
>> > > +GICH[GICH_HCR] |= G
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
>
> > > if ( !list_empty(¤t->arch.vgic.lr_pending) && lr_all_full() )
> > > -GICH[GICH_HCR] |= GICH_HCR_UIE;
> > > +GICH[GICH_HCR] |= GICH_HCR_NPIE;
> > > else
> > > -GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >
On 11/19/2014 01:30 PM, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 3:26 PM, Julien Grall wrote:
>> On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
>>> Hi Julien,
>>>
>>> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall
>>> wrote:
On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>>>
On Wed, Nov 19, 2014 at 3:26 PM, Julien Grall wrote:
> On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
>> Hi Julien,
>>
>> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall
>> wrote:
>>> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
On Wed, 19 Nov 2014, Ian Campbell wrote:
> On Wed, 2
On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
> Hi Julien,
>
> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall wrote:
>> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>>> On Wed, 19 Nov 2014, Ian Campbell wrote:
On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
> So it l
Hi Julien,
On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall wrote:
> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>> On Wed, 19 Nov 2014, Ian Campbell wrote:
>>> On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
So it looks like there is not actually anything wrong, is just that
Hi Stefano,
> > if ( !list_empty(¤t->arch.vgic.lr_pending) && lr_all_full() )
> > -GICH[GICH_HCR] |= GICH_HCR_UIE;
> > +GICH[GICH_HCR] |= GICH_HCR_NPIE;
> > else
> > -GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> > +GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >
> > }
>
> Ye
On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Ian Campbell wrote:
>> On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
>>> So it looks like there is not actually anything wrong, is just that you
>>> have too much inflight irqs? It should cause problems because
On Wed, 19 Nov 2014, Ian Campbell wrote:
> On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
> > So it looks like there is not actually anything wrong, is just that you
> > have too much inflight irqs? It should cause problems because in that
> > case GICH_HCR_UIE should be set and you s
On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
> So it looks like there is not actually anything wrong, is just that you
> have too much inflight irqs? It should cause problems because in that
> case GICH_HCR_UIE should be set and you should get a maintenance
> interrupt when LRs beco
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 1:42 PM, Stefano Stabellini
> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
> >> wrote:
> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> Hi St
On Wed, Nov 19, 2014 at 1:42 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
>> wrote:
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi Stefano,
>> >>
>> >> Thank you for your support.
>> >>
>> >> Yo
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi Stefano,
> >>
> >> Thank you for your support.
> >>
> >> You are right - with latest change you've proposed I got a continuous
>
On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> Thank you for your support.
>>
>> You are right - with latest change you've proposed I got a continuous
>> prints during platform hang:
>>
>> (XEN) gic.c:725:d0v0 LRs fu
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
>
> Thank you for your support.
>
> You are right - with latest change you've proposed I got a continuous
> prints during platform hang:
>
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full,
Hi Stefano,
Thank you for your support.
You are right - with latest change you've proposed I got a continuous
prints during platform hang:
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not
Hello Andrii,
we are getting closer :-)
It would help if you post the output with GIC_DEBUG defined but without
the other change that "fixes" the issue.
I think the problem is probably due to software irqs.
You are getting too many
gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is stil
Hi Stefano,
No hangs with this change.
Complete log is the following:
U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
DRA752 ES1.0
not set. Validating first E-fuse MAC
cpsw
- UART enabled -
- CPU booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registe
OK got it. Give me a few mins
On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
wrote:
> It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
> for non-hardware irqs (desc == NULL) and keep avoiding
> GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
>
> Al
It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
for non-hardware irqs (desc == NULL) and keep avoiding
GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.
Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
other potential bugs introduced l
What if I try on top of current master branch the following code:
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 31fb81a..6764ab7 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -36,6 +36,8 @@
#include
#include
+#define GIC_DEBUG 1
+
/*
* LR register def
On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
> OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
> everything works fine
> The following 2 patches fixes xen/master for my platform.
>
> Stefano, could you please take a look to these changes?
>
> commit 3628a0aa35706a8f532af865ed78
OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
everything works fine
The following 2 patches fixes xen/master for my platform.
Stefano, could you please take a look to these changes?
commit 3628a0aa35706a8f532af865ed784536ce514eca
Author: Andrii Tseglytskyi
Date: Tue Nov 18 1
Strange - looks like baseline code already does the same, that you
sent me yesterday. The only what is needed - is to set
PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI.
But baseline contains an issue. And in the same time changes on top of
5495a512b63bad868c147198f7f049c2617d468c work fine.
Regards,
Andrii
Hi Stefano,
On Mon, Nov 17, 2014 at 8:02 PM, Stefano Stabellini
wrote:
> On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> Thank you for your answer.
>>
>> On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
>> wrote:
>> > Although it is possible that that patch is the cause of
On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
>
> Thank you for your answer.
>
> On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
> wrote:
> > Although it is possible that that patch is the cause of your problem,
> > unfortunately it is part of a significant rework of the GIC d
Hi Stefano,
Thank you for your answer.
On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
wrote:
> Although it is possible that that patch is the cause of your problem,
> unfortunately it is part of a significant rework of the GIC driver in
> Xen and I am afraid that testing with only a portion
Although it is possible that that patch is the cause of your problem,
unfortunately it is part of a significant rework of the GIC driver in
Xen and I am afraid that testing with only a portion of that patch
series might introduce other subtle bugs. For your reference the series
starts at commit 6f
Hi,
Issue occurs after the following commit:
commit 5495a512b63bad868c147198f7f049c2617d468c
Author: Stefano Stabellini
Date: Tue Jun 10 15:07:12 2014 +0100
xen/arm: support HW interrupts, do not request maintenance_interrupts
If the irq to be injected is an hardware irq (p->desc !=
Hi Julien,
> I would be surprised that the next GIC series impact this code as the
> next driver is only compiled for arm64 (GICv3 doesn't exist on arm32).
> Though, there was some refactoring.
I meant that code was divided for generic GIC and GICv2 together with
refactoring. Also in mails I saw
On 11/14/2014 04:22 PM, Andrii Tseglytskyi wrote:
> On Fri, Nov 14, 2014 at 6:15 PM, Stefano Stabellini
> wrote:
>> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>>> On Fri, Nov 14, 2014 at 5:22 PM, Stefano Stabellini
>>> wrote:
On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> On Fri, N
On Fri, Nov 14, 2014 at 6:15 PM, Stefano Stabellini
wrote:
> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> On Fri, Nov 14, 2014 at 5:22 PM, Stefano Stabellini
>> wrote:
>> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> >> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
>> >> wrote:
On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> On Fri, Nov 14, 2014 at 5:22 PM, Stefano Stabellini
> wrote:
> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
> >> wrote:
> >> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> Hi,
>
Hi Julien,
On Fri, Nov 14, 2014 at 5:49 PM, Julien Grall wrote:
> Hi Andrii,
>
> On 11/14/2014 03:39 PM, Andrii Tseglytskyi wrote:
>> Also note - freeze depends on system load. It reproduces more
>> frequently if I start Android + QNX + all frontends/backends drivers.
>> Starting Android only wit
Hi Andrii,
On 11/14/2014 03:39 PM, Andrii Tseglytskyi wrote:
> Also note - freeze depends on system load. It reproduces more
> frequently if I start Android + QNX + all frontends/backends drivers.
> Starting Android only without any addition drivers works more less
> stable. It looks like issue is
On Fri, Nov 14, 2014 at 5:22 PM, Stefano Stabellini
wrote:
> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
>> wrote:
>> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi,
>> >>
>> >> I observe system freeze on latest xen/master branc
On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
> wrote:
> > On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi,
> >>
> >> I observe system freeze on latest xen/master branch.
> >>
> >> My setup is:
> >>
> >> - Jacinto 6 evm board (OMAP5)
>
On Fri, Nov 14, 2014 at 4:35 PM, Stefano Stabellini
wrote:
> On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi,
>>
>> I observe system freeze on latest xen/master branch.
>>
>> My setup is:
>>
>> - Jacinto 6 evm board (OMAP5)
>> - Latest Xen 4.5.0-rc2 as hypervisor
>> - Linux 3.8 as dom0, runni
On Fri, 14 Nov 2014, Andrii Tseglytskyi wrote:
> Hi,
>
> I observe system freeze on latest xen/master branch.
>
> My setup is:
>
> - Jacinto 6 evm board (OMAP5)
> - Latest Xen 4.5.0-rc2 as hypervisor
> - Linux 3.8 as dom0, running on 2 vcpus
> - Android 4.3 as domU (running on Linux kernel 3.8,
Hi,
I observe system freeze on latest xen/master branch.
My setup is:
- Jacinto 6 evm board (OMAP5)
- Latest Xen 4.5.0-rc2 as hypervisor
- Linux 3.8 as dom0, running on 2 vcpus
- Android 4.3 as domU (running on Linux kernel 3.8, 2 vcpus)
- XSM feature is disabled
- gcc version 4.7.3 20130328 (pr
66 matches
Mail list logo
