Source: qemu
Followup-For: Bug #1030545
Control: block -1 by 1031753
Source: qemu
Followup-For: Bug #1030545
Control: tags -1 - help
Control: tags -1 + pending
It seems that the root cause of this issue is the kernel bug which is fixed in
5.10 upstream stable.
This kernel patch is currently pending for the next bullseye upload against
#1031753: linux-image-5.10.0-21-s390x: user space process hangs on s390
Regards,
-Dipak
Source: qemu
Followup-For: Bug #1030545
After further investigation, the absence of the 'getenforce' binary in
the libguestfs build-deps appears to be a non-issue (and in hindsight was not
relevant in a 'src:qemu' bug thread, anyway). There is a comment[1] in
the source mentioning that failures
Source: qemu
Followup-For: Bug #1030545
> In the build logs for libguestfs, I see last successful builds were done
> on 5.10.0-20-s390x kernel, and on 5.10.0-21-s390x, all builds fails.
> 5.10.0-21-s390x is the one running on zelenka too.
Sorry for what I now worry may have been distractions in
Source: qemu
Followup-For: Bug #1030545
(ack - that does seem like an unusually-timed coincidence. continuing on with
some unrelated investigation, though...)
There's a commit[1] from Y2019 that appears to describe a similar set of
circumstances - iothreads blocked forever for a bunch of
Hi,
On Sat, 11 Feb 2023 20:18:57 + James Addison wrote:
Source: qemu
Followup-For: Bug #1030545
For anyone else looking into this bug: it seemed to me that 'qcow2.c' is a
likely candidate for this infinite looping[1] behaviour to originate from.
The fact that metadata preallocation is
Source: qemu
Followup-For: Bug #1030545
For anyone else looking into this bug: it seemed to me that 'qcow2.c' is a
likely candidate for this infinite looping[1] behaviour to originate from.
The fact that metadata preallocation is enabled when it occurs could be
relevant information too.
(my
So, we tried to reproduce it on a different machine at IBM.
The problem doesn't show itself there.
I asked the debian admin team to reboot zelenka into 5.10.0-20 kernel
to verify, - there was no answer so far.
So I'm leaving this as it is now. If the next kernel update will
not fix the issue,
In the build logs for libguestfs, I see last successful builds were done
on 5.10.0-20-s390x kernel, and on 5.10.0-21-s390x, all builds fails.
5.10.0-21-s390x is the one running on zelenka too.
It looks to me like a kernel issue..
/mjt
So, many previous versions behave the same, including bullseye.
However.
1. I was able to create a 512-bytes qcow2 file once in /home/mjt on zelenka.
And.
2. All versions always work fine in /tmp, on a tmpfs.
Is it possible that the tests were running on a tmpfs before?
/mjt
Processing control commands:
> tag -1 + help
Bug #1030545 [src:qemu] qemu: qemu-img and qemu-system-s390x hang on s390x
Added tag(s) help.
> found -1 1:5.2+dfsg-11+deb11u2
Bug #1030545 [src:qemu] qemu: qemu-img and qemu-system-s390x hang on s390x
Marked as found in versions qemu/1:5.2+d
Control: tag -1 + help
Control: found -1 1:5.2+dfsg-11+deb11u2
05.02.2023 20:30, Michael Tokarev wrote:
..
The thing is: I can't find *any* working version of qemu-img, they all
hang like described. This includes 1:7.2+dfsg-1+b1 too.
There's more: I installed bullseye on zelenka, and tried
04.02.2023 23:48, Hilko Bengen wrote:
..
Does 7.2+dfsg-1 work?
I don't have s390x environment so have no way to deal with this one.
No, it doesn't. On the porterbox (zelenka.debian.org) I was only able to
install 1:7.2+dfsg-1+b1 without rebuilding.
Oh, I forgot about zelenka. Tried that one
* Michael Tokarev:
> 04.02.2023 23:19, Hilko Bengen wrote:
>> Package: src:qemu
>> Version: 1:7.2+dfsg-2
> ..
>> qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1s.qcow2
>> 512
>> would hang in what appears a tight loop (100% CPU).
>
> Does 7.2+dfsg-1 work?
>
> I don't have
04.02.2023 23:19, Hilko Bengen wrote:
Package: src:qemu
Version: 1:7.2+dfsg-2
..
qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1s.qcow2 512
would hang in what appears a tight loop (100% CPU).
Does 7.2+dfsg-1 work?
I don't have s390x environment so have no way to deal
Package: src:qemu
Version: 1:7.2+dfsg-2
Severity: grave
X-Debbugs-Cc: none, Hilko Bengen
Dear Maintainer,
While investigating recent s390x build failures of libguestfs, I noticed
that variants of
qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1s.qcow2 512
would hang in
17 matches
Mail list logo
