On Wed, May 26, 2021 at 1:44 PM Gabriele Borello
wrote:
> The following kernel version was used: Linux 5.9.0-rc8 x86_64,
> ...
> The kernel was compiled by configuring peer-to-peer as described in the
> p2pmem-test guide. Trying to run the command suggested in the p2pmem-test
> guide (
Public bug reported:
Host: qemu 5.1.0, linux 5.5.13
Guest: Windows 7 64-bit
This guest ran a memory intensive process, and triggered oom-killer on
host. Luckily, it killed chromium. My understanding is this should
mean qemu should have continued running unharmed. But, the spice
connection
Am I correct to expect the VM to continue successfully, after oom-killer
successfully freed up memory? This journactl does show a calltrace
which includes "vmx_vmexit", and I'm not sure what that function is for
but looks a little worrisome.
** Attachment added: "section or journalctl from host,
Apologies, it looks like I ran into two separate bugs, one with XFS, and
one with BTRFS, that had the same symptom, initially making me to think
this must be a QEMU issue.
Using blktrace, I was able to see within the VM, that the virtio block
device wasn't getting the writes that were going into
Yes, I first replicated the issue by removing "max_outputs=1", then
patched spice server, and the issue no longer happens.
QEMU 4.1.0 still changed something. If I understand correctly, it's now
in some circumstances saying there are 0 monitors, even though there's a
graphic card?
Fixing this
** Description changed:
I've had bunches of these errors on 9 different boots, between
2019-08-21 and now, with Arch host and guest, from linux 5.1.16 to
5.2.14 on host and guest, with QEMU 4.0.0 and 4.1.0. spice 0.14.2,
spice-gtk 0.37, spice-protocol 0.14.0, virt-viewer 8.0.
I've
Public bug reported:
I've had bunches of these errors on 9 different boots, between
2019-08-21 and now, with Arch host and guest, from linux 5.1.16 to
5.2.14 on host and guest, with QEMU 4.0.0 and 4.1.0. spice 0.14.2,
spice-gtk 0.37, spice-protocol 0.14.0, virt-viewer 8.0.
I've been fighting
Sorry, my #8 was really long. All builds I've done were in clean
chroots, so starting from scratch with just git source, with no
interference from other builds. Also later in #8, I show that
--disable-glusterfs doesn't work because some part of the build looks
for the .so that was never built.
Bisection is not going well at all with this code base!
Before your last reply, I started, and the first between 4.0.0 and 4.1.0
is aae6500972 which fails compilation:
==
...
CC stubs/pci-host-piix.o
CC stubs/ram-block.o
CC stubs/ramfb.o
CC stubs/fw_cfg.o
P.S. Looks like I can use --disable-docs to hopefully get around the
json parsing error, but that still doesn't help with the gluster error
or that something is still looking the .so given --disable-glusterfs.
--
You received this bug notification because you are a member of qemu-
devel-ml,
a) spice 0.14.2. Also spice-gtk 0.37, and spice-protocol 0.14.0.
b) Swapping with "-device qxl-vga,max_outputs=1" does fix the problem.
Swapping with "-device qxl-vga" still has the bug.
c) Knowing b, would the bisect still help? If needed, sure, I will.
--
You received this bug notification
Sorry, in comment #2 for the native graphics window command line, I
copied from the wrong trial. The argument for QXL should have been
included, because that works with a native graphics window:
(...bootindex=0) \
-vga qxl
--
You received this bug notification because you are a member of
Finding a minimal case did shed some light on this.
Using QEMU's native graphics window, this works fine:
$ /usr/bin/qemu-system-x86_64 \
-m 1G \
-blockdev
raw,node-name=install_iso,read-only=on,file.driver=file,file.filename=/mnt/losable/ISOs/archlinux-2019.09.01-x86_64.iso
\
-device
Comparing the spice debug logs, where I see this with QEMU 4.0.0 without
the bug:
(remote-viewer:19270): GSpice-DEBUG: 00:05:21.201: channel-display.c:1979
display-2:0: received new monitors config from guest: n: 1/4
(remote-viewer:19270): GSpice-DEBUG: 00:05:21.201: channel-display.c:1997
** Description changed:
- Host is Arch Linux. linux 5.2.13, qemu 4.1.0.
+ Host is Arch Linux. linux 5.2.13, qemu 4.1.0. virt-viewer 8.0.
Guest is Arch Linux Sept 2019 ISO. linux 5.2.11.
Have replicated this both on a system using amdgpu and one using
integrated ASPEED graphics.
Public bug reported:
Host is Arch Linux. linux 5.2.13, qemu 4.1.0.
Guest is Arch Linux Sept 2019 ISO. linux 5.2.11.
Have replicated this both on a system using amdgpu and one using
integrated ASPEED graphics.
Downgrading from 4.1.0 to 4.0.0 works as usual, see:
** Description changed:
Up to date Arch Linux on host and guest. linux 5.2.11. QEMU 4.1.0.
Full command line at bottom.
Host gives QEMU two thin LVM volumes. The first is the root filesystem,
and the second is for heavy I/O, on a Samsung 970 Evo 1TB.
When maxing out the I/O on
** Description changed:
Up to date Arch Linux on host and guest. linux 5.2.11. QEMU 4.1.0.
Full command line at bottom.
Host gives QEMU two thin LVM volumes. The first is the root filesystem,
and the second is for heavy I/O, on a Samsung 970 Evo 1TB.
When maxing out the I/O on
Public bug reported:
Up to date Arch Linux on host and guest. linux 5.2.11. QEMU 4.1.0.
Full command line at bottom.
Host gives QEMU two thin LVM volumes. The first is the root filesystem,
and the second is for heavy I/O, on a Samsung 970 Evo 1TB.
When maxing out the I/O on the second
Public bug reported:
Apologies if this is just an inherent part of paravirtualization that
should be expected.
In my host, I have an LVM thin pool with chunk_size 128MB. Within it, I
have a thin volume "tmp". In the host:
# fdisk -l /dev/lvm/tmp
Disk /dev/lvm/tmp: 256 MiB, 268435456 bytes,
I believe this feature was just merged by Linus about a week ago, and is
in linux 5.0-rc1:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d548e65904ae43b0637d200a2441fc94e0589c30
--
You received this bug notification because you are a member of qemu-
devel-ml,
only gives the same 5 button types,
so I think winds up effectively ignoring the event and never passing
it along.
Off to the spice guys.
On Sun, Dec 16, 2018 at 5:10 PM james harvey wrote:
>
> Running "remote-viewer --spice-debug" does show events for pushing the
> scroll w
18 at 5:00 PM james harvey wrote:
>
> I didn't make it very clear that my Arch Linux guest didn't had tablet
> emulation. On it, evtest only shows "ImExPS/2 Generic Explorer
> Mouse". On its monitor, "info mice" shows:
>
> * Mouse #2: QEMU PS/2 Mouse
>
>
ot used at all because the HID Tablet takes
> precedence. By entering "info mice" on the monitor console you can see
> which mouse is currently used. If you disable or uninstall the HID
> Tablet, the PS/2 mouse should take over.
>
> "IMEX" is short for Intelli Mouse Ex
Running qemu 3.1.0. virt-viewer 7.0. spice, spice-gtk, and
spice-protocol all git versions from the past week or so.
I have a Logitech G600 mouse. The scroll wheel can be pushed left or right.
On Arch Linux host, "evtest" shows these as event codes 275 (BTN_SIDE)
and 276 (BTN_EXTRA.) In
25 matches
Mail list logo
