This occurs on x86-64 build, related to the recent change http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stage/master_under_test&id=78728229311f9ef1746b2cc048a0b86a234b4be7 ERROR: ioctl(SNDCTL_DSP_MAPINBUF): target=0x80085013 host=0x80105013 | ERROR: ioctl(SNDCTL_DSP_MAPOUTBUF): target=0x80085014 host=0x80105014 | qemu: Unsupported syscall: 202 | qemu: uncaught target signal 11 (Segmentation fault) - core dumped | /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/work/qemux86_64-poky-linux/core-image-sato-dev-1.0-r0/rootfs/etc/rpm-postinsts/pango-module-basic-fc.sh: line 8: 15371 Segmentation fault PSEUDO_RELOADED=YES qemu-x86_64 -L $D $D/usr/bin/pango-querymodules > "$D/etc/pango/pango.modules" |
I was unable to reproduce the segfault on my machine. However, I have the SDL and GL patches disabled on my build as they cause general segfaults in QEMU on my machine. I did however track down the source of the messages. It appears that syscall 202 is a futex call, and futex emulation is only enabled if you qemu is configured in user-mode only. (As far as I can tell it's not.... thus the unimplemented syscall.) However, the actual error appears to be the ioctl message: ERROR: ioctl(SNDCTL_DSP_MAPOUTBUF): target=0x80085014 host=0x80105014 This points to a bug within QEMU itself. See the code in question: linux-user/syscall.c: /* automatic consistency check if same arch */ #if (defined(__i386__) && defined(TARGET_I386) && defined(TARGET_ABI32)) || \ (defined(__x86_64__) && defined(TARGET_X86_64)) if (unlikely(ie->target_cmd != ie->host_cmd)) { fprintf(stderr, "ERROR: ioctl(%s): target=0x%x host=0x%x\n", ie->name, ie->target_cmd, ie->host_cmd); } #endif My understanding is that its verifying that after loading/processing the command for emulation it is NOT the same, and should be.. thus causing the failure condition. Someone more familiar with QEMU and the internals likely needs to investigate this and determine what the cause of this failure is and how to correct it.
Just to try and clarify the situation, I think the recent bitbake environment fixes have "solved" the segfault issues. The segfault occurs when qemu thinks its root and makes root only operations. x86 doesn't seem to have multiuser support in qemu which is why the futex isses occurs. Whether these are related to the ioctl message or not, I don't know. For now we're reverted the pango change though as there are too many issues appearing due to it.
There are three different issues presented here. The first is the Unsupported syscall: 202 -- this is the futex issue. The second is the segfault, likely fixed or addressed as RP mentioned. The third is the ioctl... target=... host=... message. This indicates a bug in the processor emulation within QEMU. The program was trying to do something and since the target and host are the same it can check that the emulated instruction is the same as the actual instruction, which it isn't in this case. Someone with QEMU knowledge needs to investigate the ioctl issue and determine the cause and potential fix. I did some basic investigation on this (via google/mailing lists) and it could be related to vsyscalls, or similar specialized "fast-path" calling. However, I could not find any remedy for the issue within the latest QEMU release or git changelogs. (I did not try running the software with the newer version, this likely should be tried.)
Redefine this as normal, not major since we're not currently hitting this any any builds since we disabled running this until we're on the target device.
We should attempt to retest this as QEMU has been updated.
Remarking this as a feature enhancement. It would be nice to run some of the postinstalls under qemu user mode emulation but it looks like we need much more detailed investigation and planning to make this work reliably on all supported architectures. It may be there is missing functionality in qemu that needs investigation too.
I expect QEMU will work for the core BSPs, but when we start to deviate to the unusual ones, i.e. very new cores or cores with specialty instructions, it is likely to not be able to run post install scripts. One possibility is, if BSPs are tagged if they can run qemu or not, we can add the ability to use QEMU to the install scriptlet intercept code in RPM, as well as potentially the other packaging systems. Estimate assumes: * QEMU is functional, and can run what we need with minimal additional work Estimate includes: * the time to create (or verify) a flag to indicate if a machine can use qemu for the scripts * modification of the scriptlet processing code in RPM * modification of the scriptlet processing code in IPK * modification of the scriptlet processing code in DEB * Preserve existing functionality for the non-QEMU case
I don't know why this became a 1.3 Medium+. This should really be a future enhancement of medium priority and I'm rescehduling as such.
We now have postinstalls running under qemu emulation for 1.4 so closing this as resolved.