Re: NetBSD/hpcmips userland crashes (Re: IBM Workpad z50 dmesg collection)

On Mon, Mar 27, 2023, 12:00 PM David Brownlee <[email protected]> wrote:

> On Mon, 27 Mar 2023 at 06:15, B 9 <[email protected]> wrote:
> >
> > On Sun, Mar 26, 2023 at 4:31 AM David Brownlee [email protected] wrote:
> >>
> >>
> >> We (mainly Alex) are trying to track down when the issue started by
> >> starting with a netbsd-7 install and then testing different kernels
> >> built from source between netbsd-7 and netbsd-8.
> >
> > Where did you get the NetBSD 7 install? The earliest one I see on
> NetBSD.org is 8.0.
>
> There should be a pretty complete list at
> http://archive.netbsd.org/pub/NetBSD-archive/ (which could be better
> signposted)
>
> > I was able to get a filesystem formatted on wd0a using sysinst 9.3 (and
> a lot of persistence), but I wasn’t able to download base or any other
> sets, so I just copied over sysinst’s root to wd0a. I tried using /bin/sh
> as /sbin/init, but that causes a kernel panic. (panic: init died (signal 0,
> exit 0)). It’s been a while since I used NetBSD, but shouldn’t that work?
> >
> > I'm also running into some issue with, I believe, power management.
> Shortly after booting, I’ll see some message flash up on the screen and
> before I have a chance to read it, the screen will turn off. This is
> happening with the 9.3 kernel as well as the kernel from 2013-01-01. The
> power button does not wake it up and I have to reset the machine all the
> way back to WinCE. Any idea how to disable APM (and/or screensavers) at
> boot time?
>
> At this point I think there is a fundamental (caching?) (VM?) issue
> affecting some mips devices introduced between netbsd-7 and netbsd-8,
> so on those devices pretty much any version after that is going to
> behave badly. There may well be other issues on some devices, but they
> behaviour will be conflated with that initial issue, so it probably
> makes sense to try to track it  down first
>

I agree. Until the random core dumps are solved, everything else seems a
distraction....

And the vm being replaced does suggest the vr41xx parameters are wrong
somehow. Maybe we are creating multiple mappings to one page? Maybe there
are bugs in the locking code? Maybe cache parameters are wrong, so we
aren't flushing right? Maybe the old code used uncached mappings to paper
over trouble and the new code doesn't? The vr41xx was an odd duck since it
didn't do the linked load instructions. I have vague recollections that for
the kernel you had to disable interrupts... maybe the common vm relies more
on spl...

Warner

>