utimensat trouble on mips

Johannes Schauer <[email protected]>
Newsgroups gmane.linux.debian.devel.embedded,gmane.comp.emulators.qemu
Message-ID <20110705120751.GA22196@hoothoot>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.