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 qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: U
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 qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
q
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 qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.laun
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 qemu-
devel-ml, which is subscrib
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
$:~/branches/ettercap (master) $ apt-cache show qemu
Package: qemu
Priority: optional
Section: otherosfs
Installed-Size: 556
Maintainer: Ubuntu Developers
Architecture: amd64
Version: 1.7.0+dfsg-2ubuntu4~saucy1
Suggests: qemu-user-static
Depends: qemu-system (>= 1.7.0+dfsg-2ubuntu4~saucy1), qemu-u
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
I don't have a machine running Ubuntu. I onlu lodged a bug here because
this is the official bug tracker for Qemu.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Unsupported sys
but I just tried to install ghc, not to build it, can you try my ppa?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Unsupported syscall: 257 (timer_create)
Status in QEMU:
C
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 b
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-us
Its currently in git HEAD. It will be in the next full release which I
think is 2.0.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Unsupported syscall: 257 (timer_create)
Stat
If someone wants to fix what's currently in Ubtuntu they should make a
package which includes those two patches.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Unsupported sysca
will it be solved in the next qemu upload, right? how long will it take
to have it on launchpad builders?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Unsupported syscall: 257
This has been fixed in Git in the following commits:
commit f4f1e10a58cb5ec7806d47d20671e668a52c3e70
Author: Erik de Castro Lopo
Date: Fri Nov 29 18:39:23 2013 +1100
linux-user: Implement handling of 5 POSIX timer syscalls.
Implement timer_create, timer_settime
Bah, the patch in #13 segfaults in some circumstances, the previous one
doesn't.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Unsupported syscall: 257 (timer_create)
Status i
Latest version of my patch. Also submitted to the qemu-devel mailing
list.
** Attachment added: "posix-timer-patch.tgz"
https://bugs.launchpad.net/qemu/+bug/1042388/+attachment/3882940/+files/posix-timer-patch.tgz
--
You received this bug notification because you are a member of qemu-
devel
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.
** Attachment added: "posix-timer-patch.tgz"
https://bugs.launchpad.net/qemu/+bug/10
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
Still waiting on approval from my employer's lawyers to release it. Have
no idea how long this is going to take.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Unsupported sysca
@Eric any news on your patch? Could you please link it here?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Unsupported syscall: 257 (timer_create)
Status in QEMU:
Confirmed
LocutusOfBorg wrote:
> Any news on this?
Sorry, still working on getting permission from my employer to get
this released.
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
Any news on this?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Unsupported syscall: 257 (timer_create)
Status in QEMU:
Confirmed
Bug description:
Running qemu-arm-static
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Unsupported syscall: 257 (timer_create)
Status in QEMU:
Confirmed
Bug desc
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.
Erik,
Is this patch available for public consumption? It doesn't seem to be
upstream.
Thanks,
#matt
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Unsupported syscall: 257 (ti
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.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.la
Peter Maydell wrote:
> A couple of days for somebody who knows what they're doing and has
> a convenient test case.
Working on it.
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 expirati
On 27 August 2012 22:33, Erik de Castro Lopo <1042...@bugs.launchpad.net> 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 wh
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?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https:/
Yes, qemu's linux-user emulation layer doesn't currently support any of
the posix timer syscalls.
** Summary changed:
- qemu: Unsupported syscall: 257
+ qemu: Unsupported syscall: 257 (timer_create)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subs
40 matches
Mail list logo
