Re: virtio hard disk on qemu

[Mark Cave-Ayland <mark.cave-ayland%ilande.co.uk@localhost>]

On 26/01/2023 16:33, Connor McLaughlan wrote:

> On Wed, Jan 25, 2023 at 8:26 PM Tyler Mitchell <fission%ldx.ca@localhost> wrote:
> > On Wed, Jan 25, 2023 at 07:30:43PM +0100, Connor McLaughlan wrote:
> > > I suppose you are not using NetBSD/sparc64 as the host for QEMU?
> > >
> > > Because no matter what i try i can get it compiled but none of the
> > > binaries will run at all...like sitting there, doing nothing...
> > >
> > > As in:
> > >
> > > root@localhost:/# qemu-img -help
> > > []
> > >
> > > [] = means the cursor goes to newline after the command is run and
> > > nothing ever happens...all of qemu's binaries show that behavior on a
> > > sparc64 host.
> > >
> > > Process info from top says the PID is in parked state.
> >
> > Yes, that is actually the "next stage" of what I am trying to do
> > (macOS -> qemu NetBSD/sparc64 -> qemu DOS/i386).
> >
> > I have the exact same problem. After many days (almost weeks) of
> > compiling qemu and all its dependencies, I launched qemu within
> > NetBSD/sparc64 and it... just hung forever. All of them seem to do
> > the same thing (qemu-system-*, doesn't seem to matter which).
> >
> >          aldea$ file /usr/pkg/bin/qemu-system-i386
> >          /usr/pkg/bin/qemu-system-i386: ELF 64-bit MSB pie executable, SPARC V9, relaxed memory ordering, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 9.3, PaX: -mprotect, compiler model: medmid, not stripped
> >          aldea$ qemu-system-i386 -help &
> >          aldea$ echo $!
> >          1343
> >          aldea$ gdb
> >          GNU gdb (GDB) 8.3
> >          [...]
> >          (gdb) attach 1343
> >          Attaching to process 1343
> >          Reading symbols from /usr/pkg/bin/qemu-system-i386...
> >          (No debugging symbols found in /usr/pkg/bin/qemu-system-i386)
> >          [...]
> >          [Switching to LWP 1343 of process 1343]
> >          0x0000000044609ba8 in ?? () from /usr/lib/libpthread.so.1
> >          (gdb) bt
> >          #0  0x0000000044609ba8 in ?? () from /usr/lib/libpthread.so.1
> >          Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> >          (gdb)
> >
> > Sorry, I have no idea really what to do about it. :-(
> >
> > I might try putting CFLAGS="-g -Og" and rebuilding qemu, but I've
> > already sunk a lot of time into this project and need to take a
> > step back for a bit. Please let me know if you figure something
> > out!
> >
> > Tyler

For recent versions of QEMU the easiest way to get a debug build is to pass 
--enable-debug to configure (when setting CFLAGS there are some subtleties around how 
CFLAGS is passed into the various external git submodules).

> I did by error not send my reply to the port-sparc64 list. Doing so
> now in research of a possible fix for the above (non)-behavior of qemu
> on netbsd/sparc64.

For a debug backtrace you'll want to include all the threads so "thread apply all bt 
full" would be useful.

Finally you'll want the meson output generated by configure since there are all sorts 
of interesting bits and pieces there.


ATB,

Mark.