The 4.4 kernel is now available and shows no issues.
** Changed in: xen (Ubuntu Xenial)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1538049
Title:
xenst
Hint from upstream. Sounds plausible that this might be the upstream
fix:
9c17d96500f78 "xen/gntdev: Grant maps should not be subject to NUMA
balancing"
I guess 4.3 started to be more aggressive there since I never saw this
before 4.3 and there even on a non-NUMA system. But having a grant-table
Installed a system with Debian testing and the crash does not happen
there. That left two things: the additional security fixes we got or the
kernel. And it was not the security fixes... Should have tried a
different kernel sooner. Neither an old 4.2 based one nor the pending
4.4 are causing this.
Crash also happens if dom0 is restricted to a single, pinned vCPU. So I
guess it isn't an inconsistency. Only vague explanation I can think of
is that the hypervisor for some reason invalidates the mapping without
dom0(and xenstored running there) realizing.
--
You received this bug notification
Not sure this has some meaning or is just a red herring but comparing
the grant-rable debug output with Wily (Xen-4.5) it looks mostly similar
except the entry #8 which has back then the same pin number as the other
two...
(XEN) active shared
(XEN) [
For the recent crashes the pointer seemed always consistent with
previous mappings. Wondering whether the mapping might be invalidated by
the hypervisor side. For additional information, when I start the domU,
grant table debug shows the following at the beginning:
(XEN) grant-table for remote dom
Hm, when repeating with a xenstored that prints additional trace
messages about domain->interface values, I now got a case where the
SIGBUS seems to have happened while the interface pointer looks valid.
(gdb) where
#0 domain_can_read (conn=conn@entry=0x8eb890) at xenstored_domain.c:261
#1 0x000
