Reopening/Assigning to TImo for eoan since there is a patch which can we
dropped once qemu is fixed
** Changed in: mesa (Ubuntu Eoan)
Status: Fix Released => Triaged
** Changed in: mesa (Ubuntu Eoan)
Assignee: (unassigned) => Timo Aaltonen (tjaalton)
--
You received this bug notific
** Changed in: mesa (Ubuntu Eoan)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815889
Title:
qemu-system-x86_64 crashed with signal 31 in
__pthread_setaff
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815889
Title:
qemu-system-x86_64 crashed with signal 31 in
__pthread_setaffinity_ne
This problem was solved by qemu [1], so this mesa bug can be closed.
[1]
https://git.qemu.org/git/qemu.git/?a=commitdiff;h=9a1565a03b79d80b236bc7cc2dbce52a2ef3a1b8
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpa
** Changed in: mesa
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815889
Title:
qemu-system-x86_64 crashed with signal 31 in
__pthread_setaffinity_new()
St
Thank you Daniel,
we will most likely keep Disco as-is for now and merge this in 19.10 where then
mesa can drop the revert. I tagged it for 19.10 to be revisited.
** Tags added: qemu-19.10
** Also affects: mesa (Ubuntu Ee-series)
Importance: Undecided
Status: New
** Also affects: qemu
FYI the QEMU change merged in the following pull request changed to
return an EPERM errno for the thread affinity syscalls:
commit 12f067cc14b90aef60b2b7d03e1df74cc50a0459
Merge: 84bdc58c06 035121d23a
Author: Peter Maydell
Date: Thu Mar 28 12:04:52 2019 +
Merge remote-tracking branch '
(In reply to Michel Dänzer from comment #8)
> Mesa doesn't really need explicit thread affinity at all. All it wants is
> that certain sets of threads run on the same CPU module; it doesn't care
> which particular CPU module that is. What's really needed is an API to
> express this affinity between
This bug was fixed in the package mesa - 19.0.0-1ubuntu1
---
mesa (19.0.0-1ubuntu1) disco; urgency=medium
* Merge from Debian. (LP: #1818516)
* revert-set-full-thread-affinity.diff: Fix qemu crash. (LP: #1815889)
-- Timo Aaltonen Thu, 14 Mar 2019 18:48:18 +0200
** Changed in:
I'm removing this from the 19.0 blocking tracker. Generally we don't add
bugs to block a release if they were present in the previous release,
additionally there doesn't seem to be any consensus on a solution, at
this moment. If there is a fix implemented I'd be happy to pull that
into a later 19.0
We're getting down to just a few bugs blocking 19.0, so I'm pinging
those bugs to see what the progress is?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815889
Title:
qemu-system-x86_64 crashed w
The PPA was built against -proposed so I had to enable that to install all libs.
That done the 19.0.0~rc6-1ubuntu0.1 with the set affinity change reverted works
quite nicely.
It would be great to get that into Ubuntu 19.04 until the involved
upstreams agreed how to proceed with it and we can then
I don't have that issue on a chroot, so you should at least tell me why
it would refuse to upgrade them all.. apt should show an error
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815889
Title:
q
Hi Timo,
I tried to test with the mesa from ppa:canonical-x/x-staging
But there is a dependency issue in that PPA - I can't install all packages from
there.
It seems most of the X* packages will need a transition for the new mesa and
those are not in this ppa right now.
Installing all that I can
You can test 19.0~rc6 with this reverted on a ppa:
ppa:canonical-x/x-staging
should be built in 30min
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815889
Title:
qemu-system-x86_64 crashed with
** Also affects: mesa (Ubuntu Disco)
Importance: Medium
Status: Confirmed
** Also affects: qemu (Ubuntu Disco)
Importance: Undecided
Status: Triaged
** No longer affects: qemu (Ubuntu Disco)
** Changed in: mesa (Ubuntu Disco)
Status: Confirmed => Triaged
** Changed in
** Changed in: mesa (Ubuntu)
Importance: Undecided => Medium
** Changed in: mesa (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815889
Title:
qemu-syste
(In reply to Daniel P. Berrange from comment #3)
> (In reply to Ahzo from comment #2)
> > To check for the availability of the syscall, one can try it in a child
> > process and see if the child is terminated by a signal, e.g. like this:
>
> Afraid not, QEMU's seccomp filter blocks use of fork() t
Launchpad has imported 9 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=109695.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://hel
Adding Timo who maintainers mesa.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815889
Title:
qemu-system-x86_64 crashed with signal 31 in
__pthread_setaffinity_new()
Status in Mesa:
Unknown
Thanks Daniel and MarcAndre for chiming in here.
Atfer thinking more about it I agree to Daniel that actually mesa should honor
and stick with its affinity assignment.
For documentation purpose: the solution proposed on the ML is at
https://lists.freedesktop.org/archives/mesa-dev/2019-February/2
@Ubuntu-Desktop Team (now subscribed) - is there a chance we can revert [1] in
mesa before it will be released with Disco for now. That would be needed until
an accepted solution throughout the stack of libvirt/qemu/mesa is found?
Otherwise using GL backed qemu graphics will fail as outlined in t
See also mesa bug:
https://bugs.freedesktop.org/show_bug.cgi?id=109695
** Bug watch added: freedesktop.org Bugzilla #109695
https://bugs.freedesktop.org/show_bug.cgi?id=109695
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https:
I did wonder if we could set the action for some syscalls to be "errno"
instead of "kill process", but I worry that could then result in silent
mis-behaviour as processes fail to check return value as they blindly
assume the call cannot fail.
We should probably talk with mesa developers about prov
As & when libvirt & QEMU supports the external vhost processes for this
I expect it will still restrict the CPU affinity and apply seccomp
filters that likely to be as strict as they are today at minimum.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is s
(I reported that issue a few days ago too:
https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg06066.html)
Perhaps we can teach mesa to not change CPU affinity (some option, or
environment variable, or seccomp check).
Daniel, when virgl/mesa will be running in a separate process (thanks to
v
IMHO that mesa change is not valid. It is settings its affinity to run
on all threads which is definitely *NOT* something we want to be
allowed. Management applications want to control which CPUs QEMU runs
on, and as such Mesa should honour the CPU placement that the QEMU
process has.
This is a g
Summary:
- qemu crash when using GL
- "sched_setaffinity" is the syscall that is seccomp blocked and kills qemu
- the mesa i915 drivers (and your radeon as well) will do that call
- it is blocked by the current qemu -sanbox on,...,resourcecontrol=deny which
is libvirts default
- Implemented by qem
>From Ubuntu's POV this is rather new as the code in Mesa came in with the
>fresh 18.3.0_rc4-1
It is possible that no one else saw it so far ...
It is in mesa upstream since
https://github.com/mesa3d/mesa/commit/d877451b48a59ab0f9a4210fc736f51da5851c9a
But opinions might differ ...
I'll subscri
29 matches
Mail list logo
