qemu: Unsupported syscall: 257 (timer_create)

Yes, qemu's linux-user emulation layer doesn't currently support any of the posix timer syscalls.

Peter Maydell wrote:

> Yes, qemu's linux-user emulation layer doesn't currently support any of
> the posix timer syscalls.

Any idea how much work is involved to implement this?

On 27 August 2012 22:33, Erik de Castro Lopo <email address hidden> wrote:
> Peter Maydell wrote:
>> Yes, qemu's linux-user emulation layer doesn't currently support any of
>> the posix timer syscalls.
>
> Any idea how much work is involved to implement this?

A couple of days for somebody who knows what they're doing and has
a convenient test case.

-- PMM

Implementing timer_create along is probably not enough, one would have to implement rest of the related syscalls:

       * timer_create(): Create a timer.
       * timer_settime(2): Arm (start) or disarm (stop) a timer.
       * timer_gettime(2): Fetch the time remaining until the next expiration of a timer, along with the interval setting of the timer.
       * timer_getoverrun(2): Return the overrun count for the last timer expiration.
       * timer_delete(2): Disarm and delete a timer.

Convinient testcases for timer* syscalls exist apparently in ltp suite.

I have a fix for this. I can now successfully install ghc and compile programs with it.

In the process of cleaning up the patch and working on a test for the test suite.

Erik,

Is this patch available for public consumption? It doesn't seem to be upstream.

Thanks,
#matt

Matt Robinson wrote:

> Is this patch available for public consumption? It doesn't seem to be
> upstream.

Unfortunately not yet. I'm working on getting permission to release it.

Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Any news on this?

@Eric any news on your patch? Could you please link it here?

Still waiting on approval from my employer's lawyers to release it. Have no idea how long this is going to take.

Until proper patch is available I'm using attached temp workaround.

After some testing GHC and produced executables appear to work correctly in foreign arch chroot.

I'm sure there will be issues but I only need compilation to work in foreign arch chroot because I will deploy produced executables to Raspberry Pi anyway.

cabal-installing works too but I had to comment out anything related to Template Haskell from (to be installed) packages.

versions:

qemu 1.4.1 (static build)
host: Linux proton 3.9.2-1-ARCH #1 SMP PREEMPT Sat May 11 20:31:08 CEST 2013 x86_64 GNU/Linux
foreign: Linux proton 3.9.2-1-ARCH #1 SMP PREEMPT Sat May 11 20:31:08 CEST 2013 armv6l GNU/Linux
chroot created from 2013-02-09-wheezy-raspbian.img
ghc 7.4.1-4+rpi1 armhf

The two patches have been sent to the qemu-devel mailing list and I will also attach them here.
?field.comment=The two patches have been sent to the qemu-devel mailing list and I will also attach them here.

Latest version of my patch. Also submitted to the qemu-devel mailing list.

Bah, the patch in #13 segfaults in some circumstances, the previous one doesn't.

This has been fixed in Git in the following commits:

    commit f4f1e10a58cb5ec7806d47d20671e668a52c3e70
    Author: Erik de Castro Lopo <email address hidden>
    Date: Fri Nov 29 18:39:23 2013 +1100

        linux-user: Implement handling of 5 POSIX timer syscalls.

        Implement timer_create, timer_settime, timer_gettime, timer_getoverrun
        and timer_delete.

        Signed-off-by: Erik de Castro Lopo <email address hidden>
        Signed-off-by: Riku Voipio <email address hidden>

    commit 905bba13ca292cb8c83fe5ccdf8a95bd04168bb1
    Author: Erik de Castro Lopo <email address hidden>
    Date: Fri Nov 29 18:39:22 2013 +1100

        linux-user: Add target struct defs needed for POSIX timer syscalls.

        Signed-off-by: Erik de Castro Lopo <email address hidden>
        Signed-off-by: Riku Voipio <email address hidden>

Thi s bug can be closed as resolved.

will it be solved in the next qemu upload, right? how long will it take to have it on launchpad builders?

Its currently in git HEAD. It will be in the next full release which I think is 2.0.

If someone wants to fix what's currently in Ubtuntu they should make a package which includes those two patches.

mmm I don't know, I built it in my ppa, with your patch.
Upgraded the system
https://code.launchpad.net/~costamagnagianfranco/+archive/firefox/+packages
Preparing to replace qemu-user 1.5.0+dfsg-3ubuntu5.2 (using .../qemu-user_1.7.0+dfsg-2ubuntu4~saucy1_amd64.deb) ...
Unpacking replacement qemu-user ...
Preparing to replace qemu-keymaps 1.5.0+dfsg-3ubuntu5.2 (using .../qemu-keymaps_1.7.0+dfsg-2ubuntu4~saucy1_all.deb) ...
Unpacking replacement qemu-keymaps ...
Preparing to replace qemu-system-ppc 1.5.0+dfsg-3ubuntu5.2 (using .../qemu-system-ppc_1.7.0+dfsg-2ubuntu4~saucy1_amd64.deb) ...
Unpacking replacement qemu-system-ppc ...
Preparing to replace qemu-system-sparc 1.5.0+dfsg-3ubuntu5.2 (using .../qemu-system-sparc_1.7.0+dfsg-2ubuntu4~saucy1_amd64.deb) ...
Unpacking replacement qemu-system-sparc ...
Preparing to replace qemu-system-x86 1.5.0+dfsg-3ubuntu5.2 (using .../qemu-system-x86_1.7.0+dfsg-2ubuntu4~saucy1_amd64.deb) ...
Unpacking replacement qemu-system-x86 ...
Preparing to replace qemu-system-arm 1.5.0+dfsg-3ubuntu5.2 (using .../qemu-system-arm_1.7.0+dfsg-2ubuntu4~saucy1_amd64.deb) ...
Unpacking replacement qemu-system-arm ...
Preparing to replace qemu-system-misc 1.5.0+dfsg-3ubuntu5.2 (using .../qemu-system-misc_1.7.0+dfsg-2ubuntu4~saucy1_amd64.deb) ...
Unpacking replacement qemu-system-misc ...
Preparing to replace qemu-system-mips 1.5.0+dfsg-3ubuntu5.2 (using .../qemu-system-mips_1.7.0+dfsg-2ubuntu4~saucy1_amd64.deb) ...
Unpacking replacement qemu-system-mips ...
Preparing to replace qemu-system 1.5.0+dfsg-3ubuntu5.2 (using .../qemu-system_1.7.0+dfsg-2ubuntu4~saucy1_amd64.deb) ...
Unpacking replacement qemu-system ...
Preparing to replace qemu-utils 1.5.0+dfsg-3ubuntu5.2 (using .../qemu-utils_1.7.0+dfsg-2ubuntu4~saucy1_amd64.deb) ...
Unpacking replacement qemu-utils ...
Preparing to replace qemu 1.5.0+dfsg-3ubuntu5.2 (using .../qemu_1.7.0+dfsg-2ubuntu4~saucy1_amd64.deb) ...
Unpacking replacement qemu ...
Preparing to replace qemu-user-static 1.5.0+dfsg-3ubuntu5.2 (using .../qemu-user-static_1.7.0+dfsg-2ubuntu4~saucy1_amd64.deb) ...
Unpacking replacement qemu-user-static ...

pbuilder-dist sid armhf login
apt-get install ghc
Setting up ghc (7.6.3-6) ...
qemu: Unsupported syscall: 257
ghc: timer_create: Function not implemented
update-alternatives: using /usr/bin/ghc to provide /usr/bin/haskell-compiler (haskell-compiler) in auto mode
qemu: Unsupported syscall: 257
ghc-pkg: timer_create: Function not implemented
dpkg: error processing package ghc (--configure):
 subprocess installed post-installation script returned error exit status 1

I just tried it here on my system using:

    - QEMU compiled from git HEAD.
    - ghc 7.6.3-6 from Debian

and I was able to start compiling GHC from git. I didn't let it run to completion because I only have my laptop available at the moment.

I suggest you try debugging some more and maybe try building something smaller than GHC.

but I just tried to install ghc, not to build it, can you try my ppa?

I don't have a machine running Ubuntu. I onlu lodged a bug here because this is the official bug tracker for Qemu.

This my Debian system:

    $ uname -a
    Linux rolly 3.11-2-amd64 #1 SMP Debian 3.11.10-1 (2013-12-04) x86_64 GNU/Linux

I normally run my qemu chroot using schroot as follows:

    schroot -c armhf

If I need to install packages I schroot as root:

    schroot -c armhf -u root

In the chroot, I get:

    Linux rolly 3.11-2-amd64 #1 SMP Debian 3.11.10-1 (2013-12-04) armv7l GNU/Linux

and as root I have successfully removed and installed ghc from the Debian repositories.

$:~/branches/ettercap (master) $ apt-cache show qemu
Package: qemu
Priority: optional
Section: otherosfs
Installed-Size: 556
Maintainer: Ubuntu Developers <email address hidden>
Architecture: amd64
Version: 1.7.0+dfsg-2ubuntu4~saucy1
Suggests: qemu-user-static
Depends: qemu-system (>= 1.7.0+dfsg-2ubuntu4~saucy1), qemu-user (>= 1.7.0+dfsg-2ubuntu4~saucy1), qemu-utils (>= 1.7.0+dfsg-2ubuntu4~saucy1)
Filename: pool/main/q/qemu/qemu_1.7.0+dfsg-2ubuntu4~saucy1_amd64.deb
Size: 230798

--------------------------------

$ pbuilder-dist sid armhf login
[sudo] password for locutus:
W: /home/locutus/.pbuilderrc does not exist
I: Building the build Environment
I: extracting base tarball [/home/locutus/pbuilder/sid-armhf-base.tgz]

this command runs qemu

ps ax |grep qemu
 1860 pts/8 S 0:00 sudo HOME=/home/locutus ARCHITECTURE=armhf DISTRIBUTION=sid ARCH=armhf DIST=sid DEB_BUILD_OPTIONS= pbuilder --login --distribution sid --buildresult /home/locutus/pbuilder/sid-armhf_result/ --basetgz /home/locutus/pbuilder/sid-armhf-base.tgz --mirror http://ftp.debian.org/debian --debootstrapopts --keyring=/usr/share/keyrings/debian-archive-keyring.gpg --components main contrib non-free --debootstrapopts --arch=armhf --debootstrap qemu-debootstrap
 1861 pts/8 S 0:00 /bin/bash /usr/sbin/pbuilder --login --distribution sid --buildresult /home/locutus/pbuilder/sid-armhf_result/ --basetgz /home/locutus/pbuilder/sid-armhf-base.tgz --mirror http://ftp.debian.org/debian --debootstrapopts --keyring=/usr/share/keyrings/debian-archive-keyring.gpg --components main contrib non-free --debootstrapopts --arch=armhf --debootstrap qemu-debootstrap
 2616 pts/8 S+ 0:00 /usr/bin/qemu-arm-static /bin/bash

I don't see any difference between your and my method, both of them seems to be calling qemu-debootstrap

Fixed upstream, thanks Eric! Marking as affecting Ubuntu, as even trusty's qemu does not have that fix yet. For the record, lp:platform-api uses posix timers for the sensor emulation, so running its tests will reproduce this qemu problem (and verify its fix).

The attachment "temp workaround to enable compilation and execution of GHC and produced executables in foreign arch chroot" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Unfortunately it is still not working with these two patches. The "Unsupported syscall: 257" is gone, but now it fails on EINVAL. I attach a little test C file which uses a timer. It works fine on x86 and a real arm machine, but under QEMU I get:

$ gcc -o timer_test -Wall timer_test.c -lrt
$ ./timer_test
Failed to create timer: Invalid argument
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted (core dumped)

So timer_create() does not actually seem to work? I tried some variations like 50 ms, or using CLOCK_REALTIME instead of CLOCK_MONOTONIC, all with the same result.

Thanks for the test case Martin. Problem confirmed.

The issue is that timer_create allows a number of different callback mechanisms and I had only implemented the one I need.

 Working on it now.

@erikd,

this is marked Fix Released in QEMU project, but comment #28 suggests that commit f4f1e10a58cb5ec7806d47d20671e668a52c3e70 does not in fact solve this bug. If there is a set of patches upstream that does fix the bug, please let me know and I'll pull them into trusty. Thanks much!

The fix that was commited to the Qemu git tree fixed the original test case I had. @pittit then found another test case that fails and I intend to fix that when I find a good chunk of free time. Problem is I only work on Wemu sporadically and it takes me quite a bit of time to get up to speed when I return to work on it.

Have you had any more time to look into this? Should the QEMU (project) task also be re-marked open?

I've been looking at it over the last week or so and I have submitted a patch toe the qemu-devel mailing list to fix another timer_create() problem sometime in the last week.

Unfortunately the test case @pittit submitted is far harder to support than the original test case. In this case the timer_create() syscall gets passed pointers to functions and data in the target's address space and I have not figured out how to handle that yet.

On 9 August 2014 07:15, Erik de Castro Lopo <email address hidden> wrote:
> Unfortunately the test case @pittit submitted is far harder to support
> than the original test case. In this case the timer_create() syscall
> gets passed pointers to functions and data in the target's address space
> and I have not figured out how to handle that yet.

Didn't we discuss this on the list a while back? You're confusing
the libc API with the kernel syscall API here -- the kernel definitely
does not take a pointer to a function to call here. (The timer_create
manpage explicitly says that the SIGEV_THREAD functionality
is implemented in the C library, not the kernel.) You can see
this if you strace it:

clone(child_stack=0xb76e5494,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0xb76e5bd8, {entry_number:6, base_addr:0xb76e5b70,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1},
child_tidptr=0xb76e5bd8) = 12666
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0xb76d324c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
timer_create(CLOCK_REALTIME, {0x984b098, 32, SIGEV_THREAD_ID,
{12666}}, {0x1}) = 0
timer_settime(0x1, 0, {it_interval={0, 0}, it_value={0, 50000000}}, NULL) = 0

Under the hood libc is creating a new thread with clone, and
what the timer_create() syscall gets passed is a struct including
the thread ID to be sent a signal when the timer expires (here
that's 12666).

So all you need to do is support SIGEV_THREAD_ID,
which I think doesn't require much more than copying
across the thread ID struct field.

(On the other hand that does mean that all programs which
use SIGEV_THREAD are by definition multithreaded, which
puts them into "this isn't supported" territory because of our
well known and longstanding threading issues.)

-- PMM

Patch which seems to at least make the test case work (tested with i386-on-i386 linux-user): http://patchwork.ozlabs.org/patch/378769/

Unfortunately it doesn't work with armhf on amd64 linux-user.

Use the test program from comment #27 I get:

    > schroot -c armhf -- ./timer_test_armhf
    About to call host's timer_create (0, 0x7fff6ee80720, 0x625b1f40)
    Host's timer_create returns -22
    Failed to create timer: Invalid argument
    qemu: uncaught target signal 6 (Aborted) - core dumped
    E: Child terminated by signal ‘Aborted’

(Yes I made very certain the schroot was using my freshly compiled version of qemu-arm-static).

@erikd,

can you check whether this has been fixed in wily?

I finally got round to looking into why the test case from comment #27 worked on x86-64 guests and i386-guest-on-i386-host but not on arm-on-x86-64. This turns out to be a wrong structure definition which meant we weren't handling the 32-bit-guest-on-64-bit-host combinations correctly. I've sent a patch:

http://patchwork.ozlabs.org/patch/665274/

I think this should tie up the last loose end in this bug report so once it gets into master we can close it.