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
@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:
@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
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1042388
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
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
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
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
and
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
Server Team, which is subscribed to qemu in Ubuntu.
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
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
and
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:
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
Server Team, which is subscribed to qemu in Ubuntu.
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.
@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
@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
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)
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
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
$
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
Server Team, which is
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)
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
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
$
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
25 matches
Mail list logo
