Public bug reported:
I was trying to do an ARMv6 cross compile with qemu-user-static when I
ran into this:
https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/326884620#L1596
I was close to giving up when I found the following:
https://github.com/osrf/multiarch-docker-image-generation/issues/36
rovided memory-pinning
is required user still has to white-list mbind() in container
configuration.
Reported-by: Manuel Hohmann
Signed-off-by: Igor Mammedov
---
CC: berra...@redhat.com
CC: ehabk...@redhat.com
CC: pbonz...@redhat.com
CC: mhohm...@physnet.uni-hamburg.de
CC: qemu-sta...@nongnu.org
ode ? backend->host_nodes : NULL, maxnode + 1, flags)) {
+ maxnode ? backend->host_nodes : NULL, 0, flags)) {
if (backend->policy != MPOL_DEFAULT || errno != ENOSYS) {
But no success, the same error occurs.
Best regards,
xenos1984 / Manuel Hohmann
sig
MPOL_DEFAULT || errno != ENOSYS) {
But no success, the same error occurs. It happens only within docker - the same
command runs fine on my desktop (also Ubuntu 20.04) system.
Best regards,
xenos1984 / Manuel Hohmann
PS: I apologize if this mail is sent / received more than once; there was a
pr
Managed to get a coredump. Coredumps usually tell me nothing but maybe
someone here can find something useful in there...
** Attachment added: "core.1001.13055.1585661762.bz2"
https://bugs.launchpad.net/qemu/+bug/1869782/+attachment/5343797/+files/core.1001.13055.1585661762.bz2
--
You receiv
This is a "Ubuntu Bionic" thing.
I've tried again on a VM with up-to-date Ubuntu Bionic and get the same
segfault.
For comparison I've placed the Debian build of qemu-user-static version
4.2 to my Arch Linux VM and have no crash there.
So either the kernel version or some kernel configuration. N
Here we go:
https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/309187889#L332
Created with this commit:
https://github.com/VDR4Arch/vdr4arch/commit/29ec2197483bf15102c889eef2749bb0cffc0839
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to Q
I could run an "qemu... --version" in the chroot to get it into log.
But I'm close to 100% sure it is version 4.2 as the VM is set up from
scratch for every build and the chroot is also set up from scratch.
--
You received this bug notification because you are a member of qemu-
devel-ml, which i
** Description changed:
I'm not actually sure how far I can help as I so far failed to reproduce
the issue on my local VM but I get it on Travis CI every time. I even
went through the hassle of hacking a Debian repository into their Ubuntu
Bionic VM to get qemu 4.2 as I hoped a new version
Public bug reported:
I'm not actually sure how far I can help as I so far failed to reproduce
the issue on my local VM but I get it on Travis CI every time. I even
went through the hassle of hacking a Debian repository into their Ubuntu
Bionic VM to get qemu 4.2 as I hoped a new version could fix
I seem to have found another workaround. Knowing now what causes this my
guess was: If I make the qemu-arm-static on the host a 32 bit binary and
get "multilib" running to make my 64 bit Linux installation run this,
then in theory this incompatibility should not happen. If it would, then
32 bit x86
Public bug reported:
I try to autobuild for ARM7 with qemu-arm-static. Part of this is
downloading source via SVN.
Whenever I try to download a SVN repository I get the following output:
svn: E75: Can't read directory '...': Value too large for
defined data type
This is the repository I
Actually this one magically went good. I'm testing in Virtual Box as my
ARM64 host. Maybe something went wrong there. After rebooting the whole
machine today "git" works well.
Will reopen if it happens again...
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notifi
Public bug reported:
I want to use qemu-arm-static to cross-compile software. The compiler
itself is a native cross-compiler connected via "distcc".
The problem is that a script tries to do some stuff with "git" and with
a "git clone -s" command the whole story reproducibly stops with a
"segmenta
node/issues/19348#issuecomment-500465502
I need further assistance to track down the cause of the bug.
Kind regards
Manuel
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1832281/+subscriptions
ing qemu-system-
x86_64 was used.
Node.js is compiled on the vm guest (v12.4.0 / master)
see also
https://github.com/nodejs/node/issues/19348#issuecomment-500465502
I need further assistance to track down the cause of the bug.
Kind regards
Manuel
To manage notifications a
is compiled on the vm guest (v12.4.0 / master)
see also
https://github.com/nodejs/node/issues/19348#issuecomment-500465502
I need further assistance to track down the cause of the bug.
Kind regards
Manuel
** Affects: qemu
Importance: Undecided
Status: New
** Description changed
Thank you for your reply. Sorry to take so long (was on vacations).
Your comment seems correct to me. I tried with the ELF file instead of
the binary file and it worked perfectly (and all the cores were running
instead of just core 0).
>From my point of view, this bug can be marked as invalid.
T
Public bug reported:
Hello,
I'm running qemu 2.12 on a raspberry pi 3 with the command:
qemu-system-aarch64 -M raspi3 -serial stdio -kernel executable.bin
On my start file (right in the beginning with the highest EL), the
following instructions:
ldr x0 , =1920
msr CNTFRQ_EL0, x0
and qemu
Public bug reported:
When running a virtual machine with qemu 2.9.0 with this parameter for
sharing a folder:
-virtfs local,id=fsdev1,path=$HOME/git,security_model=none,mount_tag=git
then the folder is shared to the VM but in some subfolders I can't
delete files. The guest system then reports th
Public bug reported:
qemu-system-x86_64 -net nic,model=help
output comes to stderr instead of std
qemu-system-x86_64 -net nic,model=help -> stdout
qemu-system-x86_64 -machine help -> stdout
qemu-system-x86_64 -cpu help -> stdout
as of
https://github.com/qemu/qemu/blob/044d65525f6ac2093042ae18
Public bug reported:
compiled qemu at commit 1eeace9c237a729d11c7acd7c0338ab4562af637
with ./configure --enable-debug --enable-vnc --target-
list=x86_64-softmmu
gdb --args ./qemu-system-x86_64 -nographic -parallel none -serial none
-nodefconfig -nodefaults -machine accel=kvm -enable-kvm -m 102
RIght, with '-usb' qemu creates then 'piix3-usb-uhci' device:
00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB
[Natoma/Triton II] (rev 01)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/685
followup:
my understanding is there are a bunch of usb interfaces:
uhci is usb 1.0
ehci is usb 2.0
xhci is usb 3.0
…
-device piix3-usb-uhci will create an usb 1.0 interface. I guess usb 1.0
is insufficent for modern usb devices so windows errors with code 10.
ehci have enough to bring full suppo
Hi, I had the same problem. Tested a lot. My solution to passthrough usb
devices to a windows 7 x64 guest:
parameter part:
-device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-
host,vendorid=0x{},productid=0x{},id=hostdev0,bus=usb.0
I also tried the device
piix4-usb-uhci
instead of usb-ehci
Public bug reported:
As discussed in the ganeti group[1], I'm opening this bug to request
that qemu provides a runtime command or switch to list the supported
keymaps for vnc.
[1] -
http://groups.google.com/group/ganeti/browse_thread/thread/dd524f5311d8d79e
** Affects: qemu
Importance: Und
I also have an old
Win95 license if Win98 is too "heavy". If this also doesn't work then
my scanner also has an Win3.1 driver ;-)
Thank you very much for any answer!
CU
Manuel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
27 matches
Mail list logo