[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
> - 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
> 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.
"Great minds discuss ideas, average minds discuss events, small minds
-- Disputed: Often attributed to Eleanor Roosevelt. 1948.
Main Index |
Thread Index |