On i386, glibc only saves/restores the signal mask via sigprocmask,
excluding RT signal. A Linux bug in the compat version of this syscall
corrupts the RT signal state, which will cause lockups of QEMU's VCPU
threads. Therefore, fall back to gthread coroutines on this host
platform.
On 09.05.2012 23:21, Jan Kiszka wrote:
On i386, glibc only saves/restores the signal mask via sigprocmask,
excluding RT signal. A Linux bug in the compat version of this syscall
corrupts the RT signal state, which will cause lockups of QEMU's VCPU
threads.
This should obviously be fixed in
On 2012-05-09 16:27, Michael Tokarev wrote:
On 09.05.2012 23:21, Jan Kiszka wrote:
On i386, glibc only saves/restores the signal mask via sigprocmask,
excluding RT signal. A Linux bug in the compat version of this syscall
corrupts the RT signal state, which will cause lockups of QEMU's VCPU
On 05/09/2012 02:34 PM, Jan Kiszka wrote:
On 2012-05-09 16:27, Michael Tokarev wrote:
On 09.05.2012 23:21, Jan Kiszka wrote:
On i386, glibc only saves/restores the signal mask via sigprocmask,
excluding RT signal. A Linux bug in the compat version of this syscall
corrupts the RT signal state,
On 2012-05-09 16:48, Anthony Liguori wrote:
On 05/09/2012 02:34 PM, Jan Kiszka wrote:
On 2012-05-09 16:27, Michael Tokarev wrote:
On 09.05.2012 23:21, Jan Kiszka wrote:
On i386, glibc only saves/restores the signal mask via sigprocmask,
excluding RT signal. A Linux bug in the compat version
On 09.05.2012 23:21, Jan Kiszka wrote:
[]
--- a/configure
+++ b/configure
@@ -2777,17 +2777,22 @@ fi
# windows autodetected by make
if test $coroutine = -o $coroutine = ucontext; then
if test $darwin != yes; then
-cat $TMPC EOF
+if test $linux = yes -a $cpu = i386; then
+
On 05/09/2012 02:57 PM, Jan Kiszka wrote:
On 2012-05-09 16:48, Anthony Liguori wrote:
On 05/09/2012 02:34 PM, Jan Kiszka wrote:
Can't we resort to the SIGUSR1 workaround for the time being, while
no RT signals are in actual use, and just have the time to let the
kernel side to fix the things
On 2012-05-09 17:01, Anthony Liguori wrote:
On 05/09/2012 02:57 PM, Jan Kiszka wrote:
On 2012-05-09 16:48, Anthony Liguori wrote:
On 05/09/2012 02:34 PM, Jan Kiszka wrote:
Can't we resort to the SIGUSR1 workaround for the time being, while
no RT signals are in actual use, and just have the
On 9 May 2012 21:11, Jan Kiszka jan.kis...@siemens.com wrote:
OK. Then what about sigaltstack (once fixed)? Is it also slower? If not,
can we converge over it?
sigaltstack is going to be significantly faster than the gthread
implementation (about the same speed as ucontext for coroutine
switch,
On 05/09/2012 03:11 PM, Jan Kiszka wrote:
On 2012-05-09 17:01, Anthony Liguori wrote:
On 05/09/2012 02:57 PM, Jan Kiszka wrote:
On 2012-05-09 16:48, Anthony Liguori wrote:
On 05/09/2012 02:34 PM, Jan Kiszka wrote:
Can't we resort to the SIGUSR1 workaround for the time being, while
no RT
On 05/09/2012 03:46 PM, Peter Maydell wrote:
On 9 May 2012 21:11, Jan Kiszkajan.kis...@siemens.com wrote:
OK. Then what about sigaltstack (once fixed)? Is it also slower? If not,
can we converge over it?
sigaltstack is going to be significantly faster than the gthread
implementation (about
On 9 May 2012 21:59, Anthony Liguori aligu...@us.ibm.com wrote:
On 05/09/2012 03:46 PM, Peter Maydell wrote:
Longer term (ie post 1.1) I'm strongly in favour of kicking
out coroutines, because I think there clearly is no single
solid portable implementation possible. C just isn't designed
to
On 05/09/2012 04:27 PM, Peter Maydell wrote:
On 9 May 2012 21:59, Anthony Liguorialigu...@us.ibm.com wrote:
On 05/09/2012 03:46 PM, Peter Maydell wrote:
Longer term (ie post 1.1) I'm strongly in favour of kicking
out coroutines, because I think there clearly is no single
solid portable
13 matches
Mail list logo
