qemu-system-arm hangs on SIGUSR1 on OS X 10.8.2

[Oliver]

I built the latest version of QEMU

commit b4ae3cfa57b8c1bdbbd7b7d420971e9171203ade
Date: Mon Oct 1 12:34:37 2012 +1000

My system is:
Darwin localhost 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64

localhost:qemu oliverks$ gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

Shortly after start up I freeze. I am running the command line

./arm-softmmu/qemu-system-arm -M lm3s811evb -kernel ../FreeRTOSV7.2.0/FreeRTOS/Demo/CORTEX_LM3S811_GCC/gcc/RTOSDemo.axf

The hang appears to occur due to this signal being sent

static void qemu_tcg_init_cpu_signals(void)
{
    sigset_t set;
    struct sigaction sigact;

    memset(&sigact, 0, sizeof(sigact));
    sigact.sa_handler = cpu_signal;
    sigaction(SIG_IPI, &sigact, NULL); // <-- Signal that hangs system

    sigemptyset(&set);
    sigaddset(&set, SIG_IPI);
    pthread_sigmask(SIG_UNBLOCK, &set, NULL);
}

Oliver

[Oliver (oliverks1)]

To follow up, I think this bug might be a problem with the stellaris branch of the code. I compiled the very simple gpio_led example, and this crashes with the SIGUSR1 as well.

Oliver

[Oliver (oliverks1)]

One more follow up. Using the standard startup.c with just a while(1) {} loop yields the same problem.

Has anyone got a regression test for the -M lm3s811evb that I can run?

I might be able to see what's different with the TI code that is causing the SIGUSR1.

Oliver

[Oliver (oliverks1)]

Is there anything else I can do to help debug this problem?

[Paolo Bonzini (bonzini)]

This seems like an OS bug (kernel or Cocoa). The usage of the signal is common to all QEMU system emulation targets, so it's not dependent on Stellaris.

Try an older version of OS X, or try a different video backend (e.g. VNC). That may help isolating the problem.

[Oliver (oliverks1)]

I tried compiling under Ubuntu
Linux oliverks-virtual-machine 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 17:58:38 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

and it does not appear to work. I just get the statement

VNC server running on `127.0.0.1:5900'
Oliver

[Peter Maydell (pmaydell)]

On 18 October 2012 23:06, Oliver <email address hidden> wrote:
> I tried compiling under Ubuntu
> Linux oliverks-virtual-machine 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 17:58:38 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> and it does not appear to work. I just get the statement
>
> VNC server running on `127.0.0.1:5900'

That probably means it is waiting for you to connect a VNC
client to that port so you can see the display. (Alternatively
make sure you have the libsdl1.2-dev package installed if you
want it to just bring up an X window with the graphics.)

-- PMM

[Peter Maydell (pmaydell)]

I just built QEMU from source (git master commit b6348f29, same gcc as you, MacOS 10.8.2), like this:
./configure --target-list=arm-softmmu && make -j2

and the resulting QEMU works for me. I tested with a Cortex-M3 image from here:
https://bugs.launchpad.net/qemu/+bug/1028260/+attachment/3233691/+files/stellaris-test.tar
If you untar that you'll find among other things a .bin file which is a system image for the lm3s6965evb board model, which you can run like this:
./arm-softmmu/qemu-system-arm -M lm3s6965evb -kernel ~/test-images/stellaris-test/qs_ek-lm3s6965.bin

So I think the chances are that it's just that you think that QEMU has hung because the particular guest image you're trying to run isn't working. Our M3 model has some known bugs so it's possible that it's running into one of them.

Other people also seem to have had trouble with FreeRTOS, see for instance bug 657006. Please can you try with an image that is known to work under QEMU, so that we can separate out whether this is a problem with our MacOS support or just that QEMU isn't emulating this board closely enough for the image you're trying to run?

[Oliver (oliverks1)]

Thank you for all the help. I have made a lot of progress. I think there might be a bug lm3s811 device, but I will look into that and log a bug if I find it. As usual with these problems, it was not just one thing.

The TI make files for using gcc produced bad code (I hand check by looking at the assembly files).
The FreeRTOS build was cause crashes due to other bugs
I think the lm3s811 might have a bug (with the display) which was what I was focusing on.

Thank you for everyone who responded. I think this bug can be marked closed.

Oliver