Il 18/04/2013 14:38, Paolo Bonzini ha scritto:
> Il 18/04/2013 08:14, Gerd Hoffmann ha scritto:
>> Thread 1 (Thread 0x7f9038188980 (LWP 27849)):
>> ---Type to continue, or q to quit---
>> #0 __lll_lock_wait () at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
>> #1 0x7f90366a9
Il 18/04/2013 08:14, Gerd Hoffmann ha scritto:
> Thread 1 (Thread 0x7f9038188980 (LWP 27849)):
> ---Type to continue, or q to quit---
> #0 __lll_lock_wait () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
> #1 0x7f90366a9388 in _L_lock_854 () from /lib64/libpthread.so.0
> #2
Hi,
> Hmm, this seems to be recursive locking. It sounded unlikely, but then
> googling for "glib gsource finalize unlock" led to this:
> https://mail.gnome.org/archives/commits-list/2010-November/msg01816.html
> If this is RHEL6, you or Amit should file
> a bug.
Yes, it's RHEL-6. Filed bug
On 04/17/13 12:17, Paolo Bonzini wrote:
> Il 17/04/2013 09:06, Gerd Hoffmann ha scritto:
cheers,
Gerd
>> Trapped into the next issue. Added qmp monitor to the virtual machine,
>> linked to unix socket. Start playing with the qom-* scrips in QMP.
>> qemu hangs after the first qmp-list
Il 17/04/2013 09:06, Gerd Hoffmann ha scritto:
>> > cheers,
>> > Gerd
> Trapped into the next issue. Added qmp monitor to the virtual machine,
> linked to unix socket. Start playing with the qom-* scrips in QMP.
> qemu hangs after the first qmp-list command (triggered by socket
> disconnect?).
Il 17/04/2013 09:06, Gerd Hoffmann ha scritto:
> Trapped into the next issue. Added qmp monitor to the virtual machine,
> linked to unix socket. Start playing with the qom-* scrips in QMP.
> qemu hangs after the first qmp-list command (triggered by socket
> disconnect?).
Yeah, I was going to tes
On 04/16/13 13:22, Gerd Hoffmann wrote:
> On 04/16/13 13:10, Paolo Bonzini wrote:
>> I'm happy to say that I'm not touching IOWatchPoll (well, almost: only
>> for consistency). Instead, these patches try to make the code consistent
>> (thus avoiding CRITICAL messages from glib) and to fix detectio
On 04/16/13 13:10, Paolo Bonzini wrote:
> I'm happy to say that I'm not touching IOWatchPoll (well, almost: only
> for consistency). Instead, these patches try to make the code consistent
> (thus avoiding CRITICAL messages from glib) and to fix detection of pty
> connections; Gerd reported that it
I'm happy to say that I'm not touching IOWatchPoll (well, almost: only
for consistency). Instead, these patches try to make the code consistent
(thus avoiding CRITICAL messages from glib) and to fix detection of pty
connections; Gerd reported that it went berserk with polling. I think it
is the s