[Qemu-devel] utimensat trouble on mips

[Johannes Schauer <j.schauer@email.de>]

Hi,

I am following up on threads started here [1] and here [2]. I'm not
subscribed to qemu-devel so please dont forget to CC me.

About a year ago, Kenneth Johansson reported [1], that trying to do a
debian debootstrap using qemu user emulation will fail due to the
following error:

/bin/tar: ./postinst: Cannot utime: Level 2 not synchronized

Lisandro had a very similar issue [2]:

/usr/bin/touch: setting times of `tito': Level 2 not synchronized

Since I was also interested in bootstrapping debian using qemu user mode
emulation at some point I tracked down the error to the usage of
utimensat which results in a ENOSYS error (being translated to
EL2NSYNC).

Here is a quick and dirty C snippet that allows to reproduce the issue:

-%<-----------------------------------------
#include <stdio.h>
#include <sys/stat.h>
#include <fcntl.h>

int main()
{
    int ret, fd, dir;

    dir = open(".", O_RDONLY);
    fd = open("./foobar", O_WRONLY|O_CREAT, 0666);
    ret = utimensat(dir, "./foobar", NULL, 0);
    perror("utimensat");

    return 0;
}
----------------------------------------->%-

To see how different architectures behave when executing this, I
compiled it natively and crosscompiled it for arm and mips. I statically
compiled it to avoid shared library troubles. Because of binfmt support
I do not prepend qemu-mips or qemu-arm in the following.

$ gcc -Wall -static utimensat.c
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.18, not stripped
$ ./a.out
utimensat: Success
$ arm-linux-gnueabi-gcc -Wall -static utimensat.c
$ file a.out
a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, not stripped
$ ./a.out
utimensat: Success
$ mips-linux-gnu-gcc -Wall -static utimensat.c
$ file a.out
a.out: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70401, not stripped
$ ./a.out
utimensat: Level 2 not synchronized
$ mipsel-linux-gnu-gcc -Wall -static utimensat.c
$ file a.out
a.out: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, not stripped
$ ./a.out
utimensat: Level 2 not synchronized

As one can see the error only shows on mips. It also occurs when
natively compiling above snippet on mips and it also occurs when using a
natively compiled `touch` binary for mips from the debian coreutils
package.

Now my questions are:

* why is this happening with mips?
* Whose fault is it?
* is it a qemu bug?
* should I open a bugreport about this issue?
* why was nobody else complaining about it, given that this is an issue
  for over a year now?

thank you

cheers, josch

[1] http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00116.html
[2] http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg00102.html