I was assembling a Debian riscv64 (and therefore, currently, sid) root FS to test something, ultimately in a VM, and building OpenZFS git master chrooted into that root to that end.

I did the ./autogen.sh && ./configure --with-linux=.../source --with-linux-obj=.../build && make dance, left it alone for a bit, and came to curiously
find it errored out with no error output printed that I saw.

Ran make again, it did not immediately error.

I then noticed in dmesg:

[1726926.715475] cc1[66416]: segfault at 2ad48a0 ip 00000000004857e0 sp 00007ffc9ef97948 error 4 in qemu-riscv64-static[401000+2cc000]
[1726926.715488] Code: 00 e9 24 fc 18 00 0f 1f 40 00 64 83 2c 25 60 ff ff ff 01 74 05 c3 0f 1f 40 00 48 8d 3d c9 6f 77 00 e9 74 0a 19 00 0f 1f 40 00 <64> 8b 04 25 60 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b
[1726967.092517] cc1[71234]: segfault at 2ad58a0 ip 00000000004857e0 sp 00007ffc23573a18 error 4 in qemu-riscv64-static[401000+2cc000]
[1726967.092530] Code: 00 e9 24 fc 18 00 0f 1f 40 00 64 83 2c 25 60 ff ff ff 01 74 05 c3 0f 1f 40 00 48 8d 3d c9 6f 77 00 e9 74 0a 19 00 0f 1f 40 00 <64> 8b 04 25 60 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b

(There's a couple more.)

(Much later on, gcc ICEd, on something it hadn't tried building before, but that didn't reproduce on running it again...)

I have a core, from doing this dance a second time, from yet another source file that built fine on successive runs, but I'm not sure how readily useful it is. I'll upload it if it would be helpful.

- Rich

04.07.2021 02:45, Rich Ercolani wrote:
[..]> [1726926.715475] cc1[66416]: segfault at 2ad48a0 ip 00000000004857e0 sp 00007ffc9ef97948 error 4 in qemu-riscv64-static[401000+2cc000]

First of all, please try the current version of qemu, which is 6.0.
Riscv is a very rapidly developing system and it received a LOT of
changes since 5.2 and even after 6.0. I suggest you to try current
upstream git.

Myself, I don't have any expirience in this area, I never used any
riscv system or tools and know nothing about qemu emulation of it.
If the more recent version shows the same issue, it is much better
to ask upstream for more help.

I'm sorry if this seems unhelpful, - but I can't pretend to be
competent and just do nothing, either.

Thanks!

/mjt

When I tried building qemu 6.0 or git on buster, as I recall it
errored out on dependencies not available in sufficiently new
incarnations, even in backports.

If the answer to "this is quite buggy" is "just run a version not even
in unstable yet", that's...quite unfortunate.

If you're just saying this because it's qemu upstream's opinion, well,
I knew that. :)

04.07.2021 15:02, Rich wrote:

Hi Rich!

I'm sorry to disappoint you, but this was all I was able to offer.
It is not "qemu upstream's opinion", it is my opinion, - it fells
like riscv64 in 3.1 was quite buggy and there's nothing I can do
about it, - I definitely wont backport changes from 6.0 to buster's
3.1 version.

Usually qemu builds quite well on current distributions, including
debian buster. I backported 5.2 version (from bullseye) for buster
together with 2 or 3 new dependencies which were not in buster.

I can not, at the time, provide a more recent version of qemu
(6.0) even for unstable since - at the time - debian was frozen
before bullseye release. However, I did provide 6.0 version
in experimental - this is the only way I know to actually
provide a new upstream version for debian during freeze.
Ofcourse I can't provide backport of 6.0 for buster since it
wasn't in bullsyeye or instable.

So your disapproval of my answer stays solely with you - I did
everything I was able to do. And I definitely suggested you the
only realistic - to my opinion - way to go forward - which is to
try either latest stable version or even the current development
version. Because this is the only way to ensure if the bug you're
seeing is already fixed.

Meanwhile, 6.1 has been released (yesterday) and it is already
available on debian unstable today.

/mjt

Hi Michael,
First, my apologies, I hadn't noticed you were one of the maintainers
of the package when I wrote my response, so it was written thinking I
was talking to someone uninvolved in the process who had offered
suggestions while stating a lack of familiarity with the problem
domain, not someone who every well-informed person in the discussion
would know was quite familiar with qemu a priori, and is just stating
they have no experience in this one area. (I have no particular
insight into why I reached this conclusion, but somehow I did.)

I very much appreciate that you've done everything you can reasonably
do at the moment to provide a reasonably recent and patched set of
software - I know the freeze meant that 6.0 couldn't turn up in
unstable, much less bullseye, which in turn means that
buster-backports wasn't going to see anything, and buster is, as you
say, obviously a complete nonstarter.

I'm no stranger to building and running my own packages, so that's not
really the issue, it just seems unfortunate to keep shipping a program
that has a nontrivial chance of crashing and burning every time it's
run, and there being no real potential for that changing. (Of course,
you might not know that's the case until well after it's in stable, at
which point it's not getting dropped short of earth-shattering
catastrophe...) I'm not claiming to have a good idea for how to
resolve or even mitigate this, other than perhaps a breakdown
somewhere easily discoverable of "we expect these tools to work
reliably, these few usually work for most people, and these forsaken
ones may torch the crops and salt the earth while laughing". (A
warning on first run of any of the more exciting options in
qemu-user-static or if any of qemu-system-* fit the bill would
probably be troublesome, at least in the common former case of being
used to run non-native binaries...)

I had not asked upstream for help because they pretty clearly state
[1] that they don't provide support for older or distro-provided
versions, and as I mentioned before, when I tried building 6.0 against
buster, it blew up spectacularly. (Of course, with bullseye out and
6.1 sitting happily in unstable, this becomes much more
accessible...once I take the plunge on my main systems, at least. And
it seems moot anyway, because I've been hanging out in their IRC
channel, and nobody seems to be getting turned away for running older
or distro versions, just gently suggested that it might be resolved
already.)

Thank you again for your work, and I'm sorry that I came across as an
ungrateful entitled person.

- Rich

[1] - https://www.qemu.org/support/

Hi!

Do you have any information about how the situation with current qemu is?
There's 8.0 in testing now (but 8.0 had its own share of linux-user bugs),
and 8.1~rc4 in experimental, - can you try 8.1 one please?

Thanks,

/mjt

Version: 1:7.2+dfsg-1
Ok.  This bug report has been in "moreinfo" state for quite some time,
and it looks like the reported issue doesn't exist in bookworm already.

Let's close this bug report with bookworm version of qemu.

If you think this is incorrect, please feel free to reopen it.

Thanks,

/mjt