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

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

[Alexander Graf]

While trying current svn, it looks like AIO support compiles on
Mac OS X finally. Unfortunately it is broken and as soon as I want
to run any image, it endless loops in block.c:1446 which is:

    while (async_ret == NOT_DONE) {
        qemu_aio_wait();
    }

So for the time being, let's simply disable aio for Mac OS X.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 configure |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index c3fbbbe..3e701b9 100755
--- a/configure
+++ b/configure
@@ -259,6 +259,7 @@ cocoa="yes"
 audio_drv_list="coreaudio"
 audio_possible_drivers="coreaudio sdl fmod"
 OS_LDFLAGS="-framework CoreFoundation -framework IOKit"
+aio="no"
 ;;
 SunOS)
     solaris="yes"
-- 
1.6.0.2

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

[Anthony Liguori]

Alexander Graf wrote:
> While trying current svn, it looks like AIO support compiles on
> Mac OS X finally. Unfortunately it is broken and as soon as I want
> to run any image, it endless loops in block.c:1446 which is:
>
>     while (async_ret == NOT_DONE) {
>         qemu_aio_wait();
>     }
>   

Are you using cocoa?

I don't think the AIO code is broken here.  I think something else is 
broken and disabling AIO hides the symptom.  Can you dig more into this?

Regards,

Anthony Liguori

> So for the time being, let's simply disable aio for Mac OS X.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  configure |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/configure b/configure
> index c3fbbbe..3e701b9 100755
> --- a/configure
> +++ b/configure
> @@ -259,6 +259,7 @@ cocoa="yes"
>  audio_drv_list="coreaudio"
>  audio_possible_drivers="coreaudio sdl fmod"
>  OS_LDFLAGS="-framework CoreFoundation -framework IOKit"
> +aio="no"
>  ;;
>  SunOS)
>      solaris="yes"
>   

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

[Alexander Graf]

On 24.01.2009, at 21:28, Anthony Liguori wrote:

> Alexander Graf wrote:
>> While trying current svn, it looks like AIO support compiles on
>> Mac OS X finally. Unfortunately it is broken and as soon as I want
>> to run any image, it endless loops in block.c:1446 which is:
>>
>>    while (async_ret == NOT_DONE) {
>>        qemu_aio_wait();
>>    }
>>
>
> Are you using cocoa?

Yep. Nothing else works for x86_64 on Mac OS X ;-). Well - except for  
vnc.

> I don't think the AIO code is broken here.  I think something else  
> is broken and disabling AIO hides the symptom.  Can you dig more  
> into this?

Hum - sounds like an idea. I'm open for hints on how to dig in here. I  
can disable cocoa for starters of course.


Alex

>
>
> Regards,
>
> Anthony Liguori
>
>> So for the time being, let's simply disable aio for Mac OS X.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>> configure |    1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/configure b/configure
>> index c3fbbbe..3e701b9 100755
>> --- a/configure
>> +++ b/configure
>> @@ -259,6 +259,7 @@ cocoa="yes"
>> audio_drv_list="coreaudio"
>> audio_possible_drivers="coreaudio sdl fmod"
>> OS_LDFLAGS="-framework CoreFoundation -framework IOKit"
>> +aio="no"
>> ;;
>> SunOS)
>>     solaris="yes"
>>
>
>
>

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

[Anthony Liguori]

Alexander Graf wrote:
>
> On 24.01.2009, at 21:28, Anthony Liguori wrote:
>
>> Alexander Graf wrote:
>>> While trying current svn, it looks like AIO support compiles on
>>> Mac OS X finally. Unfortunately it is broken and as soon as I want
>>> to run any image, it endless loops in block.c:1446 which is:
>>>
>>>    while (async_ret == NOT_DONE) {
>>>        qemu_aio_wait();
>>>    }
>>>
>>
>> Are you using cocoa?
>
> Yep. Nothing else works for x86_64 on Mac OS X ;-). Well - except for 
> vnc.
>
>> I don't think the AIO code is broken here.  I think something else is 
>> broken and disabling AIO hides the symptom.  Can you dig more into this?
>
> Hum - sounds like an idea. I'm open for hints on how to dig in here. I 
> can disable cocoa for starters of course.

My guess would be that the completion signal isn't being delivered.  I'd 
start by disabling cocoa and then annotate things to see if the 
completion signal every makes it to the aio system.

Regards,

Anthony Liguori

>
> Alex
>
>>
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>> So for the time being, let's simply disable aio for Mac OS X.
>>>
>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>> ---
>>> configure |    1 +
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/configure b/configure
>>> index c3fbbbe..3e701b9 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -259,6 +259,7 @@ cocoa="yes"
>>> audio_drv_list="coreaudio"
>>> audio_possible_drivers="coreaudio sdl fmod"
>>> OS_LDFLAGS="-framework CoreFoundation -framework IOKit"
>>> +aio="no"
>>> ;;
>>> SunOS)
>>>     solaris="yes"
>>>
>>
>>
>>
>
>
>

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

[Alexander Graf]

On 24.01.2009, at 21:53, Anthony Liguori wrote:

> Alexander Graf wrote:
>>
>> On 24.01.2009, at 21:28, Anthony Liguori wrote:
>>
>>> Alexander Graf wrote:
>>>> While trying current svn, it looks like AIO support compiles on
>>>> Mac OS X finally. Unfortunately it is broken and as soon as I want
>>>> to run any image, it endless loops in block.c:1446 which is:
>>>>
>>>>   while (async_ret == NOT_DONE) {
>>>>       qemu_aio_wait();
>>>>   }
>>>>
>>>
>>> Are you using cocoa?
>>
>> Yep. Nothing else works for x86_64 on Mac OS X ;-). Well - except  
>> for vnc.
>>
>>> I don't think the AIO code is broken here.  I think something else  
>>> is broken and disabling AIO hides the symptom.  Can you dig more  
>>> into this?
>>
>> Hum - sounds like an idea. I'm open for hints on how to dig in  
>> here. I can disable cocoa for starters of course.
>
> My guess would be that the completion signal isn't being delivered.   
> I'd start by disabling cocoa and then annotate things to see if the  
> completion signal every makes it to the aio system.

So disabling cocoa doesn't really help. I recompiled with cocoa=no and  
still have the same issue:

(gdb) thread apply all bt

Thread 1 (process 38766 thread 0x10b):
#0  0x91b846f2 in select$DARWIN_EXTSN ()
#1  0x00081526 in qemu_aio_wait () at aio.c:158
#2  0x00081055 in bdrv_read_em (bs=0x4, sector_num=0, buf=0x4 <Address  
0x4 out of bounds>, nb_sectors=4) at block.c:1447
#3  0x0007fb29 in bdrv_guess_geometry (bs=0x806a00, pcyls=0xbfffdfcc,  
pheads=0xbfffdfc8, psecs=0xbfffdfc4) at block.c:773
#4  0x0002a398 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  0x0002b08d 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  0x000442f9 in pc_init1 (ram_size=<value temporarily unavailable,  
due to optimizations>, vga_ram_size=8388608, boot_device=0x11da16  
"cad", kernel_filename=0x0, kernel_cmdline=0x11d40c "",  
initrd_filename=0x0, pci_enabled=1, cpu_model=0x0) at /Users/alex/work/ 
qemu-osx/qemu/hw/pc.c:1027
#7  0x000068d1 in main (argc=5, argv=0xbffff360, envp=0xbffff378) at / 
Users/alex/work/qemu-osx/qemu/vl.c:5520

It's actually hanging in its first select() call.

Alex

>
>
> Regards,
>
> Anthony Liguori
>
>>
>> Alex
>>
>>>
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>> So for the time being, let's simply disable aio for Mac OS X.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>> ---
>>>> configure |    1 +
>>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/configure b/configure
>>>> index c3fbbbe..3e701b9 100755
>>>> --- a/configure
>>>> +++ b/configure
>>>> @@ -259,6 +259,7 @@ cocoa="yes"
>>>> audio_drv_list="coreaudio"
>>>> audio_possible_drivers="coreaudio sdl fmod"
>>>> OS_LDFLAGS="-framework CoreFoundation -framework IOKit"
>>>> +aio="no"
>>>> ;;
>>>> SunOS)
>>>>    solaris="yes"
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

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

[Anthony Liguori]

Alexander Graf wrote:
>
> On 24.01.2009, at 21:53, Anthony Liguori wrote:
>
>> Alexander Graf wrote:
>>>
>>> On 24.01.2009, at 21:28, Anthony Liguori wrote:
>>>
>>>> Alexander Graf wrote:
>>>>> While trying current svn, it looks like AIO support compiles on
>>>>> Mac OS X finally. Unfortunately it is broken and as soon as I want
>>>>> to run any image, it endless loops in block.c:1446 which is:
>>>>>
>>>>>   while (async_ret == NOT_DONE) {
>>>>>       qemu_aio_wait();
>>>>>   }
>>>>>
>>>>
>>>> Are you using cocoa?
>>>
>>> Yep. Nothing else works for x86_64 on Mac OS X ;-). Well - except 
>>> for vnc.
>>>
>>>> I don't think the AIO code is broken here.  I think something else 
>>>> is broken and disabling AIO hides the symptom.  Can you dig more 
>>>> into this?
>>>
>>> Hum - sounds like an idea. I'm open for hints on how to dig in here. 
>>> I can disable cocoa for starters of course.
>>
>> My guess would be that the completion signal isn't being delivered.  
>> I'd start by disabling cocoa and then annotate things to see if the 
>> completion signal every makes it to the aio system.
>
> So disabling cocoa doesn't really help. I recompiled with cocoa=no and 
> still have the same issue:
>
> (gdb) thread apply all bt
>
> Thread 1 (process 38766 thread 0x10b):
> #0  0x91b846f2 in select$DARWIN_EXTSN ()
> #1  0x00081526 in qemu_aio_wait () at aio.c:158
> #2  0x00081055 in bdrv_read_em (bs=0x4, sector_num=0, buf=0x4 <Address 
> 0x4 out of bounds>, nb_sectors=4) at block.c:1447
> #3  0x0007fb29 in bdrv_guess_geometry (bs=0x806a00, pcyls=0xbfffdfcc, 
> pheads=0xbfffdfc8, psecs=0xbfffdfc4) at block.c:773
> #4  0x0002a398 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  0x0002b08d 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  0x000442f9 in pc_init1 (ram_size=<value temporarily unavailable, 
> due to optimizations>, vga_ram_size=8388608, boot_device=0x11da16 
> "cad", kernel_filename=0x0, kernel_cmdline=0x11d40c "", 
> initrd_filename=0x0, pci_enabled=1, cpu_model=0x0) at 
> /Users/alex/work/qemu-osx/qemu/hw/pc.c:1027
> #7  0x000068d1 in main (argc=5, argv=0xbffff360, envp=0xbffff378) at 
> /Users/alex/work/qemu-osx/qemu/vl.c:5520
>
> It's actually hanging in its first select() call.

Is posix-aio init getting called?  What is being passed to select?  It's 
waiting for the signalfd to become readable and it's never becoming 
readable.  That could be because you never get the completion signal.

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.

Regards,

Anthony Liguori

> Alex
>
>>
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>>
>>> Alex
>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Anthony Liguori
>>>>
>>>>> So for the time being, let's simply disable aio for Mac OS X.
>>>>>
>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>> ---
>>>>> configure |    1 +
>>>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/configure b/configure
>>>>> index c3fbbbe..3e701b9 100755
>>>>> --- a/configure
>>>>> +++ b/configure
>>>>> @@ -259,6 +259,7 @@ cocoa="yes"
>>>>> audio_drv_list="coreaudio"
>>>>> audio_possible_drivers="coreaudio sdl fmod"
>>>>> OS_LDFLAGS="-framework CoreFoundation -framework IOKit"
>>>>> +aio="no"
>>>>> ;;
>>>>> SunOS)
>>>>>    solaris="yes"
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>

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

[Alexander Graf]

On 24.01.2009, at 22:25, Anthony Liguori wrote:

> Alexander Graf wrote:
>>
>> On 24.01.2009, at 21:53, Anthony Liguori wrote:
>>
>>> Alexander Graf wrote:
>>>>
>>>> On 24.01.2009, at 21:28, Anthony Liguori wrote:
>>>>
>>>>> Alexander Graf wrote:
>>>>>> While trying current svn, it looks like AIO support compiles on
>>>>>> Mac OS X finally. Unfortunately it is broken and as soon as I  
>>>>>> want
>>>>>> to run any image, it endless loops in block.c:1446 which is:
>>>>>>
>>>>>>  while (async_ret == NOT_DONE) {
>>>>>>      qemu_aio_wait();
>>>>>>  }
>>>>>>
>>>>>
>>>>> Are you using cocoa?
>>>>
>>>> Yep. Nothing else works for x86_64 on Mac OS X ;-). Well - except  
>>>> for vnc.
>>>>
>>>>> I don't think the AIO code is broken here.  I think something  
>>>>> else is broken and disabling AIO hides the symptom.  Can you dig  
>>>>> more into this?
>>>>
>>>> Hum - sounds like an idea. I'm open for hints on how to dig in  
>>>> here. I can disable cocoa for starters of course.
>>>
>>> My guess would be that the completion signal isn't being  
>>> delivered.  I'd start by disabling cocoa and then annotate things  
>>> to see if the completion signal every makes it to the aio system.
>>
>> So disabling cocoa doesn't really help. I recompiled with cocoa=no  
>> and still have the same issue:
>>
>> (gdb) thread apply all bt
>>
>> Thread 1 (process 38766 thread 0x10b):
>> #0  0x91b846f2 in select$DARWIN_EXTSN ()
>> #1  0x00081526 in qemu_aio_wait () at aio.c:158
>> #2  0x00081055 in bdrv_read_em (bs=0x4, sector_num=0, buf=0x4  
>> <Address 0x4 out of bounds>, nb_sectors=4) at block.c:1447
>> #3  0x0007fb29 in bdrv_guess_geometry (bs=0x806a00,  
>> pcyls=0xbfffdfcc, pheads=0xbfffdfc8, psecs=0xbfffdfc4) at block.c:773
>> #4  0x0002a398 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  0x0002b08d 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  0x000442f9 in pc_init1 (ram_size=<value temporarily  
>> unavailable, due to optimizations>, vga_ram_size=8388608,  
>> boot_device=0x11da16 "cad", kernel_filename=0x0,  
>> kernel_cmdline=0x11d40c "", initrd_filename=0x0, pci_enabled=1,  
>> cpu_model=0x0) at /Users/alex/work/qemu-osx/qemu/hw/pc.c:1027
>> #7  0x000068d1 in main (argc=5, argv=0xbffff360, envp=0xbffff378)  
>> at /Users/alex/work/qemu-osx/qemu/vl.c:5520
>>
>> It's actually hanging in its first select() call.
>
> Is posix-aio init getting called?

Yes, several times:

haruka:qemu alex$ ./i386-softmmu/qemu -vnc :0 -snapshot ~/Downloads/ 
worms/worms-united.qcow2
posix_aio_init
AIO rd = 5
AIO wr= 6
posix_aio_init
posix_aio_init
posix_aio_init
posix_aio_init
posix_aio_init
add rd(5)...
selecting...


>  What is being passed to select?

The AIO rd fd.

>  It's waiting for the signalfd to become readable and it's never  
> becoming readable.  That could be because you never get the  
> completion signal.

So who sends the signal?

> 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 ;-).

Alex

>
>
> Regards,
>
> Anthony Liguori
>
>> Alex
>>
>>>
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>>
>>>> Alex
>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Anthony Liguori
>>>>>
>>>>>> So for the time being, let's simply disable aio for Mac OS X.
>>>>>>
>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>> ---
>>>>>> configure |    1 +
>>>>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/configure b/configure
>>>>>> index c3fbbbe..3e701b9 100755
>>>>>> --- a/configure
>>>>>> +++ b/configure
>>>>>> @@ -259,6 +259,7 @@ cocoa="yes"
>>>>>> audio_drv_list="coreaudio"
>>>>>> audio_possible_drivers="coreaudio sdl fmod"
>>>>>> OS_LDFLAGS="-framework CoreFoundation -framework IOKit"
>>>>>> +aio="no"
>>>>>> ;;
>>>>>> SunOS)
>>>>>>   solaris="yes"
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>

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

[Anthony Liguori]

Alexander Graf wrote:
>
> On 24.01.2009, at 22:25, Anthony Liguori wrote:
>
>> Alexander Graf wrote:
>>>
>>> On 24.01.2009, at 21:53, Anthony Liguori wrote:
>>>
>>>> Alexander Graf wrote:
>>>>>
>>>>> On 24.01.2009, at 21:28, Anthony Liguori wrote:
>>>>>
>>>>>> Alexander Graf wrote:
>>>>>>> While trying current svn, it looks like AIO support compiles on
>>>>>>> Mac OS X finally. Unfortunately it is broken and as soon as I want
>>>>>>> to run any image, it endless loops in block.c:1446 which is:
>>>>>>>
>>>>>>>  while (async_ret == NOT_DONE) {
>>>>>>>      qemu_aio_wait();
>>>>>>>  }
>>>>>>>
>>>>>>
>>>>>> Are you using cocoa?
>>>>>
>>>>> Yep. Nothing else works for x86_64 on Mac OS X ;-). Well - except 
>>>>> for vnc.
>>>>>
>>>>>> I don't think the AIO code is broken here.  I think something 
>>>>>> else is broken and disabling AIO hides the symptom.  Can you dig 
>>>>>> more into this?
>>>>>
>>>>> Hum - sounds like an idea. I'm open for hints on how to dig in 
>>>>> here. I can disable cocoa for starters of course.
>>>>
>>>> My guess would be that the completion signal isn't being 
>>>> delivered.  I'd start by disabling cocoa and then annotate things 
>>>> to see if the completion signal every makes it to the aio system.
>>>
>>> So disabling cocoa doesn't really help. I recompiled with cocoa=no 
>>> and still have the same issue:
>>>
>>> (gdb) thread apply all bt
>>>
>>> Thread 1 (process 38766 thread 0x10b):
>>> #0  0x91b846f2 in select$DARWIN_EXTSN ()
>>> #1  0x00081526 in qemu_aio_wait () at aio.c:158
>>> #2  0x00081055 in bdrv_read_em (bs=0x4, sector_num=0, buf=0x4 
>>> <Address 0x4 out of bounds>, nb_sectors=4) at block.c:1447
>>> #3  0x0007fb29 in bdrv_guess_geometry (bs=0x806a00, 
>>> pcyls=0xbfffdfcc, pheads=0xbfffdfc8, psecs=0xbfffdfc4) at block.c:773
>>> #4  0x0002a398 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  0x0002b08d 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  0x000442f9 in pc_init1 (ram_size=<value temporarily unavailable, 
>>> due to optimizations>, vga_ram_size=8388608, boot_device=0x11da16 
>>> "cad", kernel_filename=0x0, kernel_cmdline=0x11d40c "", 
>>> initrd_filename=0x0, pci_enabled=1, cpu_model=0x0) at 
>>> /Users/alex/work/qemu-osx/qemu/hw/pc.c:1027
>>> #7  0x000068d1 in main (argc=5, argv=0xbffff360, envp=0xbffff378) at 
>>> /Users/alex/work/qemu-osx/qemu/vl.c:5520
>>>
>>> It's actually hanging in its first select() call.
>>
>> Is posix-aio init getting called?
>
> Yes, several times:
>
> haruka:qemu alex$ ./i386-softmmu/qemu -vnc :0 -snapshot 
> ~/Downloads/worms/worms-united.qcow2
> posix_aio_init
> AIO rd = 5
> AIO wr= 6
> posix_aio_init
> posix_aio_init
> posix_aio_init
> posix_aio_init
> posix_aio_init
> add rd(5)...
> selecting...
>
>
>>  What is being passed to select?
>
> The AIO rd fd.
>
>>  It's waiting for the signalfd to become readable and it's never 
>> becoming readable.  That could be because you never get the 
>> completion signal.
>
> So who sends the signal?

posix-aio-compat.c:aio_thread() ... kill(getpid(), )

I'd add a printf to see if the signal is getting sent (means op has 
completed) and then another one in 
block-raw-posix.c:aio_signal_handler() to see if we're receiving the signal.

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.

Regards,

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 ;-).

> Alex

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

[Alexander Graf]

Good Morning :)

On 25.01.2009, at 00:27, Anthony Liguori wrote:

> Alexander Graf wrote:
>>
>> On 24.01.2009, at 22:25, Anthony Liguori wrote:
>>
>>> Alexander Graf wrote:
>>>>
>>>> On 24.01.2009, at 21:53, Anthony Liguori wrote:
>>>>
>>>>> Alexander Graf wrote:
>>>>>>
>>>>>> On 24.01.2009, at 21:28, Anthony Liguori wrote:
>>>>>>
>>>>>>> Alexander Graf wrote:
>>>>>>>> While trying current svn, it looks like AIO support compiles on
>>>>>>>> Mac OS X finally. Unfortunately it is broken and as soon as I  
>>>>>>>> want
>>>>>>>> to run any image, it endless loops in block.c:1446 which is:
>>>>>>>>
>>>>>>>> while (async_ret == NOT_DONE) {
>>>>>>>>     qemu_aio_wait();
>>>>>>>> }
>>>>>>>>
>>>>>>>
>>>>>>> Are you using cocoa?
>>>>>>
>>>>>> Yep. Nothing else works for x86_64 on Mac OS X ;-). Well -  
>>>>>> except for vnc.
>>>>>>
>>>>>>> I don't think the AIO code is broken here.  I think something  
>>>>>>> else is broken and disabling AIO hides the symptom.  Can you  
>>>>>>> dig more into this?
>>>>>>
>>>>>> Hum - sounds like an idea. I'm open for hints on how to dig in  
>>>>>> here. I can disable cocoa for starters of course.
>>>>>
>>>>> My guess would be that the completion signal isn't being  
>>>>> delivered.  I'd start by disabling cocoa and then annotate  
>>>>> things to see if the completion signal every makes it to the aio  
>>>>> system.
>>>>
>>>> So disabling cocoa doesn't really help. I recompiled with  
>>>> cocoa=no and still have the same issue:
>>>>
>>>> (gdb) thread apply all bt
>>>>
>>>> Thread 1 (process 38766 thread 0x10b):
>>>> #0  0x91b846f2 in select$DARWIN_EXTSN ()
>>>> #1  0x00081526 in qemu_aio_wait () at aio.c:158
>>>> #2  0x00081055 in bdrv_read_em (bs=0x4, sector_num=0, buf=0x4  
>>>> <Address 0x4 out of bounds>, nb_sectors=4) at block.c:1447
>>>> #3  0x0007fb29 in bdrv_guess_geometry (bs=0x806a00,  
>>>> pcyls=0xbfffdfcc, pheads=0xbfffdfc8, psecs=0xbfffdfc4) at block.c: 
>>>> 773
>>>> #4  0x0002a398 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  0x0002b08d 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  0x000442f9 in pc_init1 (ram_size=<value temporarily  
>>>> unavailable, due to optimizations>, vga_ram_size=8388608,  
>>>> boot_device=0x11da16 "cad", kernel_filename=0x0,  
>>>> kernel_cmdline=0x11d40c "", initrd_filename=0x0, pci_enabled=1,  
>>>> cpu_model=0x0) at /Users/alex/work/qemu-osx/qemu/hw/pc.c:1027
>>>> #7  0x000068d1 in main (argc=5, argv=0xbffff360, envp=0xbffff378)  
>>>> at /Users/alex/work/qemu-osx/qemu/vl.c:5520
>>>>
>>>> It's actually hanging in its first select() call.
>>>
>>> Is posix-aio init getting called?
>>
>> Yes, several times:
>>
>> haruka:qemu alex$ ./i386-softmmu/qemu -vnc :0 -snapshot ~/Downloads/ 
>> worms/worms-united.qcow2
>> posix_aio_init
>> AIO rd = 5
>> AIO wr= 6
>> posix_aio_init
>> posix_aio_init
>> posix_aio_init
>> posix_aio_init
>> posix_aio_init
>> add rd(5)...
>> selecting...
>>
>>
>>> What is being passed to select?
>>
>> The AIO rd fd.
>>
>>> It's waiting for the signalfd to become readable and it's never  
>>> becoming readable.  That could be because you never get the  
>>> completion signal.
>>
>> So who sends the signal?
>
> posix-aio-compat.c:aio_thread() ... kill(getpid(), )
>
> I'd add a printf to see if the signal is getting sent (means op has  
> completed) and then another one in block-raw- 
> posix.c:aio_signal_handler() to see if we're receiving the signal.

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.

> 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

Alex

>
>
> Regards,
>
> 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 ;-).
>
>> Alex
>

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

[Anthony Liguori]

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.

Regards,

Anthony Liguori

> Alex
>
>>
>>
>> Regards,
>>
>> 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 ;-).
>>
>>> Alex
>>
>

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

[Jamie Lokier]

Anthony Liguori wrote:
> 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?

Try pthread_kill()?  That should work on everything.
Btw, a pipe might be faster.

-- Jamie

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

[Anthony Liguori]

On Sun, Jan 25, 2009 at 10:28 AM, Jamie Lokier <jamie@shareable.org> wrote:
> Anthony Liguori wrote:
>> 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?
>
> Try pthread_kill()?  That should work on everything.
> Btw, a pipe might be faster.

Yeah, writing to a pipe is going too be a much better overall solution.

Regards,

Anthony Liguori

> -- Jamie
>
>
>

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

[Alexander Graf]

On 25.01.2009, at 17:28, Jamie Lokier wrote:

> Anthony Liguori wrote:
>> 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?
>
> Try pthread_kill()?  That should work on everything.

pthread_kill doesn't help, neither does SIGUSR1. I'll try out more  
later.

Alex

>
> Btw, a pipe might be faster.
>
> -- Jamie

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

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

Alexander Graf wrote:
>
> On 25.01.2009, at 17:28, Jamie Lokier wrote:
>
>> Anthony Liguori wrote:
>>> 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?
>>
>> Try pthread_kill()?  That should work on everything.
>
> pthread_kill doesn't help, neither does SIGUSR1. I'll try out more later.

Does this help?

Regards,

Anthony Liguori

> Alex
>
>>
>> Btw, a pipe might be faster.
>>
>> -- Jamie
>
>
>


[-- Attachment #2: posix-aio-pipe.patch --]
[-- Type: application/mbox, Size: 3232 bytes --]