[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Disable AIO for Mac OS X

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] Disable AIO for Mac OS X
Date: Sun, 25 Jan 2009 09:11:29 -0600
User-agent: Thunderbird (X11/20090105)

Alexander Graf wrote:
The kill() is called, but we're never receiving the signal. Also when I kill -31 manually from the outside, the signal handler isn't invoked.

Anyone know much about signal delivery in Darwin? Is there a way to do thread signaling directly?

If for some crazy reason the OS X port spawns another thread somewhere without masking SIGUSR2 correctly, it could be that the signal is getting lost.

Hm - according to gdb things look pretty normal, no?

(gdb) thread apply all bt

Thread 2 (process 804 thread 0x1003):
#0  0x91b3c3ae in __semwait_signal ()
#1  0x91b67326 in _pthread_cond_wait ()
#2  0x91b8c9f0 in pthread_cond_timedwait$UNIX2003 ()
#3  0x000157b5 in aio_thread (unused=0x0) at posix-aio-compat.c:52
#4  0x91b66095 in _pthread_start ()
#5  0x91b65f52 in thread_start ()

Thread 1 (process 804 thread 0x10b):
#0  0x91b846f2 in select$DARWIN_EXTSN ()
#1  0x00081443 in qemu_aio_wait () at aio.c:173
#2 0x00080ef5 in bdrv_read_em (bs=0x4, sector_num=0, buf=0x4 <Address 0x4 out of bounds>, nb_sectors=4) at block.c:1447 #3 0x0007f9c9 in bdrv_guess_geometry (bs=0x806a00, pcyls=0xbfffdfcc, pheads=0xbfffdfc8, psecs=0xbfffdfc4) at block.c:773 #4 0x0002a238 in ide_init2 (ide_state=<value temporarily unavailable, due to optimizations>, hd0=0x806a00, hd1=0x0, irq=0x402a18) at /Users/alex/work/qemu-osx/qemu/hw/ide.c:2844 #5 0x0002af2d in pci_piix3_ide_init (bus=0x4, hd_table=0xbfffeaf0, devfn=4, pic=0x402930) at /Users/alex/work/qemu-osx/qemu/hw/ide.c:3435 #6 0x00044199 in pc_init1 (ram_size=<value temporarily unavailable, due to optimizations>, vga_ram_size=8388608, boot_device=0x11d946 "cad", kernel_filename=0x0, kernel_cmdline=0x11d33c "", initrd_filename=0x0, pci_enabled=1, cpu_model=0x0) at /Users/alex/work/qemu-osx/qemu/hw/pc.c:1027 #7 0x000066e1 in main (argc=5, argv=0xbffff360, envp=0xbffff378) at /Users/alex/work/qemu-osx/qemu/vl.c:5520

Can you dump the sigmasks of each thread to see if they're blocking them correctly? Perhaps thread 2 is receiving the SIGUSR2 for some weird reason?

Maybe try a different signal. Maybe SIGUSR2 has some significance in Darwin.


Anthony Liguori



Anthony Liguori

FWIW, at this point, we could drop the signal entirely and just use a pipe for communication. Right now we use a signal that we catch and then write to a pipe from the signal handler. We did this because that's how posix-aio worked but since we don't use posix-aio anymore, we're no longer limited by that.

Hum - sounds like more effort and more probable breakage than tracking this down ;-).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]