Re: Stability of netbsd-10 on real hardware?

On Mon, Mar 06, 2023 at 07:50:45AM +0000, Mark Cave-Ayland wrote:
> On 04/03/2023 00:34, Paul Ripke wrote:
> 
> > On Wed, Mar 01, 2023 at 06:40:11AM +0000, Mark Cave-Ayland wrote:
> > > On 26/02/2023 22:56, Paul Ripke wrote:
> > > 
> > > > I've managed to get netbsd-10 installed running under qemu-system-m68k,
> > > > which emulates a Apple Macintosh Quadra 800. Building a few random things
> > > > and running some random stuff, I've tripped over a bunch of little stability
> > > > issues, and I'm wondering if these are as a result of the emulation, netbsd,
> > > > or perhaps compilers. MacOS 8.1 seems stable, although I'd imagine that
> > > > netbsd stresses the emulation far more. I've seen internet breadcrumbs
> > > > saying that Linux is also stable.
> > > 
> > > Can I ask specifically which branch you are currently using? If you are
> > > using a branch with "upstream" in the name then those branches are
> > > constantly being rebased onto QEMU git master for testing with the aim of
> > > submitting upstream.
> > > 
> > > I've just pushed the latest version of the patches to
> > > https://github.com/mcayland/qemu/tree/q800.upstream3 if you can confirm
> > > whether the issues still exist there.
> > 
> > Yes, that's the branch I've been using. Just updated and rebuilt, and...
> > crash on first boot:
> > 
> > /home/stix/src/github/q800-upstream3/build/qemu-system-m68k \
> >          -M q800 -cpu m68040 -m 256 -bios Quadra800.rom \
> >          -rtc base=localtime \
> >          -g 1152x870x8 \
> >          -boot d \
> >          -drive file=pram-macos.img,format=raw,if=mtd \
> >          -device scsi-hd,scsi-id=0,drive=hd0,vendor="SEAGATE",product="ST225N",ver="1.0" \
> >          -drive id=hd0,file=MacHD.img,media=disk,format=raw,if=none \
> >          -device scsi-hd,scsi-id=1,drive=hd1,vendor="SEAGATE",product="ST225N",ver="1.0" \
> >          -drive id=hd1,file=netbsd-10.img,media=disk,format=raw,if=none \
> >          -device scsi-cd,scsi-id=3,drive=cd1,vendor="MATSHITA",product="CD-ROM CR-8005",ver="1.0k" \
> >          -drive id=cd1,file=MacOS_81.toast,media=cdrom,if=none \
> >          -nic tap,model=dp83932,ifname=tap3,script=no,downscript=no,mac=aa:00:04:4d:52:a5 \
> >          -serial mon:stdio

Right, finally got around to some testing.

> A couple of things I spotted here:
> 
> - Firstly a real Q800 can only use a maximum of 132MB (which is 128MB for
> QEMU which requires a power of 2 amount of RAM

Ok.

> - There is no need to supply the SCSI vendor/product/version information on
> the command line since this is now done automatically by newer versions of
> the patchset

Cool!

> In theory the extra RAM shouldn't make any difference, unless something is
> also playing with the djMEMC controller. Can you try the updated command
> line below instead?

I do note that there is a kernel define for DJMEMCMAX, which appears to do...
something during boot - I do know that it is supposed to allow the memory
controller to detect large SIMMs, but the fact that the Mac ROMs appear to
detect 256MiB fine under qemu, I don't think this is required?

Ok, I have now tested with netbsd-9 (branch, not specifically netbsd-9.1),
and user mode NIC, as well as tap, and I can't say it's any more reliable.
User mode nic is much slower, fwiw, and tap is definitely more convenient.
Building devel/cmake from pkgsrc regularly trips some sort of failure,
the most recent was ssh detecting corruption:

c++ -O2 -fno-reorder-blocks -fPIC -D_FORTIFY_SOURCE=2 -I/usr/include -I/usr/pkg/include -I/usr/include/krb5 -D_NETBSD_SOURCE         -DCMAKE_BOOTSTRAP      -I/home/tmp/pkgwrk.qemu-m68k/devel/cmake/work/cmake-3.25.1/Bootstrap.cmk   -I/home/tmp/pkgwrk.qemu-m68k/devel/cmake/work/cmake-3.25.1/Source   -I/home/tmp/pkgwrk.qemu-m68k/devel/cmake/work/cmake-3.25.1/Source/LexerParser   -I/home/tmp/pkgwrk.qemu-m68k/devel/cmake/work/cmake-3.25.1/Utilities/std   -I/home/tmp/pkgwrk.qemu-m68k/devel/cmake/work/cmake-3.25.1/Utilities  -c /home/tmp/pkgwrk.qemu-m68k/devel/cmake/work/cmake-3.25.1/Source/cmGeneratorTarget.cxx -o cmGeneratorTarget.o
Bad packet length 3376367803.
ssh_dispatch_run_fatal: Connection to 192.168.0.52 port 22: Connection corrupted

which although suggests network, I hesitate to blame just network
given the other random failures. The command also continued in tmux,
and later failed:

cc1plus: internal compiler error: in unregister, at symtab.c:426
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://www.NetBSD.org/support/send-pr.html> for instructions.
make: *** [Makefile:192: cmGeneratorTarget.o] Error 1

I'll do some more testing, since right now I have the pkgsrc work
directory on NFS, which will be stressing the network.

Cheers,
-- 
Paul Ripke
"Great minds discuss ideas, average minds discuss events, small minds
 discuss people."
-- Disputed: Often attributed to Eleanor Roosevelt. 1948.