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
@erikd,
can you check whether this has been fixed in wily?
** Changed in: qemu (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Un
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 ar
Patch which seems to at least make the test case work (tested with
i386-on-i386 linux-user): http://patchwork.ozlabs.org/patch/378769/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1042388
Title:
qe
On 9 August 2014 07:15, Erik de Castro Lopo <1042...@bugs.launchpad.net> 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
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_
Have you had any more time to look into this? Should the QEMU (project)
task also be re-marked open?
** Changed in: qemu (Ubuntu)
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launc
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
@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!
--
Yo
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
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
$ ./
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
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).
** Also affects: qemu (Ubuntu)
Imp
13 matches
Mail list logo
