On 2/1/21 10:45 AM, Richard W.M. Jones wrote:
> This commit breaks running certain s390x binaries, at least
> the "mount" command (or a library it uses) breaks.
>
> More details in this BZ:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1922248
>
> Could we revert this change since it seems to have caused other
> problems as well?
Well, the other problems have been fixed (which were in fact latent, and could
have been produced by other means). I would not like to sideline this patch
set indefinitely.
Could you give me some help extracting the relevant binaries? "Begin with an
s390x host" is a non-starter.
FWIW, with qemu-system-s390x, booting debian, building qemu-s390x, and running
"/bin/mount -t proc proc /mnt" under double-emulation does not show the bug.
I suspect that's because debian targets a relatively old s390x cpu, and that
yours is using the relatively new vector instructions. But I don't know.
What I do know is that current qemu doesn't seem to boot current fedora:
$ ../bld/qemu-system-s390x -nographic -m 4G -cpu max -drive
file=Fedora-Server-netinst-s390x-33-1.2.iso,format=raw,if=virtio
qemu-system-s390x: warning: 'msa5-base' requires 'kimd-sha-512'.
qemu-system-s390x: warning: 'msa5-base' requires 'klmd-sha-512'.
LOADPARM=[ ]
Using virtio-blk.
ISO boot image size verified
KASLR disabled: CPU has no PRNG
Linux version 5.8.15-301.fc33.s390x
(mockbu...@buildvm-s390x-07.s390.fedoraproject.org) 1 SMP Thu Oct 15 15:55:57
UTC 2020Kernel fault: interruption code 0005 ilc:2
PSW : 0000200180000000 00000000000124c4
R:0 T:0 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:0 CC:2 PM:0 RI:0 EA:3
GPRS: 0000000000000000 0000000b806a2da6 7aa19c5cbb980703 95f62d65812b83ab
d5e42882af203615 0000000b806a2da0 0000000000000000 0000000000000000
00000000000230e8 0000000001438500 0000000001720320 0000000000000000
0000000001442718 0000000000010070 0000000000012482 000000000000bf20
Which makes me thing that fedora 33 is now targeting a cpu that is too new and
not actually supported by tcg.
r~
