On 28/12/2017 23:49, Bruno Alvisio wrote:
>
> Hello Andrew,
>
>
>
> Thanks. Yup, you were right. I did an objdump of the kernel and found
> the offending instruction 0x5cfcb to be callq *%r15 in the
> console_print function (see below):
>
Answering out of order...
> I am not familiar with the X
Hello Andrew,
Thanks. Yup, you were right. I did an objdump of the kernel and found the
offending instruction 0x5cfcb to be callq *%r15 in the console_print
function (see below):
00056ee9 :
56ee9: 55 push %rbp
56eea: 48 89 e5mov%r
Hi Mike,
Thanks for the confirmation on that. Since the last crash I was having them
daily until I downgraded back to kernel 4.4 and Xen 4.6 where stability
resumed. Zero crashes since 24th December.
@Paul, Wei,
Can we get this investigated? It appears that this is a stability blocker for
Xen
On 28/12/17 18:33, Bruno Alvisio wrote:
> (d360) Bootstrapping...
>
> (XEN) Dom360 callback via changed to Direct Vector 0x20
>
> (d360) Xen Minimal OS (hvm)!
>
> (XEN) d360v0 Triple fault - invoking HVM shutdown action 1
>
> (XEN) *** Dumping Dom360 vcpu#0 state: ***
>
> (XEN) [ Xen-4.10.0-rc
Hello all,
I am trying to build PVH mini-os with libc support. These are the steps I
have followed so far:
1. Xen repo (master: commit id: d2f86bf604698806d311cc251c1b66fbb752673c)
2. mini-os repo (master: commit id:
0b4b7897e08b967a09bed2028a79fabff82342dd)
3. Made the following modifications i
Alex,
I saw this same issue when running a kernel 4.13+, switched
back to 4.11 and the problem has not resurfaced. I would like to
understand the root cause of this issue.
Mike
On 12/22/2017 3:35 PM, Alex Braunegg wrote:
Hi all,
Another crash this morning:
vif vif-2-0 vif2.0: T
On x86 cpu_possible_map is not defined, so trying to use
num_possible_cpus will generate link time errors.
This patch defines and fills cpu_possible_map with the current CPUs
plus the hotpluggable ones.
Note that this is already implemented on ARM.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beu
On Thu, Dec 28, 2017 at 02:41:57PM +, Andrew Cooper wrote:
> On 28/12/17 14:33, Roger Pau Monne wrote:
> > On x86 cpu_possible_map is not defined, so trying to use
> > num_possible_cpus will generate link time errors.
> >
> > This patch defines and fills cpu_possible_map with the current CPUs
>
On 28/12/17 14:33, Roger Pau Monne wrote:
> On x86 cpu_possible_map is not defined, so trying to use
> num_possible_cpus will generate link time errors.
>
> This patch defines and fills cpu_possible_map with the current CPUs
> plus the hotpluggable ones.
>
> Note that this is already implemented on
On x86 cpu_possible_map is not defined, so trying to use
num_possible_cpus will generate link time errors.
This patch defines and fills cpu_possible_map with the current CPUs
plus the hotpluggable ones.
Note that this is already implemented on ARM.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beu
In case the vCPU has pending events to inject. This fixes a bug that
happened if the guest mapped the vcpu info area using
VCPUOP_register_vcpu_info without having setup the event channel
upcall, and then setup the upcall vector.
In this scenario the guest would not receive any upcalls, because th
flight 73516 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/73516/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i38
12 matches
Mail list logo
