On 2011-06-15 07:20, Alexandre Raymond wrote: > Both the signal thread (via sigwait()) and the cpu thread (via > a normal signal handler) were attempting to catch SIG_IPI.
Why? Ahh, because of qemu_cpu_kick_self: raise(SIG_IPI)! That should generate a per-process SIG_IPI. And that may not only affect Darwin. Looks good. Acked-by: Jan Kiszka <jan.kis...@siemens.com> > > This resulted in random freezes under Darwin. > > This patch separates SIG_IPI from the rest of the signals handled > by the signal thread, because it is independently caught by the cpu > thread. > > Signed-off-by: Alexandre Raymond <cerb...@gmail.com> > --- > cpus.c | 10 +++++++++- > 1 files changed, 9 insertions(+), 1 deletions(-) > > diff --git a/cpus.c b/cpus.c > index 18a1522..84ffd1c 100644 > --- a/cpus.c > +++ b/cpus.c > @@ -394,10 +394,18 @@ static int qemu_signal_init(void) > sigaddset(&set, SIGUSR2); > pthread_sigmask(SIG_UNBLOCK, &set, NULL); > > + /* > + * SIG_IPI must be blocked in the main thread and must not be caught > + * by sigwait() in the signal thread. Otherwise, the cpu thread will > + * not catch it reliably. > + */ > + sigemptyset(&set); > + sigaddset(&set, SIG_IPI); > + pthread_sigmask(SIG_BLOCK, &set, NULL); > + > sigemptyset(&set); > sigaddset(&set, SIGIO); > sigaddset(&set, SIGALRM); > - sigaddset(&set, SIG_IPI); > sigaddset(&set, SIGBUS); > #else > sigemptyset(&set); -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
