Re: Panic at boot on 4/330 with cgfour and cgsix

[foo bar <tokenalt%gmail.com@localhost>]

On Wed, Jan 29, 2025 at 8:55 AM David Brownlee <abs%absd.org@localhost> wrote:
>
> On Wed, 29 Jan 2025 at 09:20, Julian Coleman <jdc%coris.org.uk@localhost> wrote:
> >
> > Hi,
> >
> > > > > So I tried to boot a 4.0 kernel as it was the last one to have cgfour
> > > > > enabled by default and it had the same panic. I suspect this driver
> > > > > may not have been working for a very long time.
> > > >
> > > > It may be worth testing as far back as you can go - I think cgfour
> > > > support arrived in netbsd-1-2. Its unlikely to work if netbsd-4-0
> > > > didn't, but it is possible, and will be a big help if it does :)
> > >
> > > I tried 1.5 which is the first version to list the cgfour as supported
> > > and it booted fine but I don't have a 1.5 user land set up to test
> > > further. Would it help if I set one up and tried to run X?
> >
> > This is good news!  It would be useful if you are able to find the last
> > working version - that would narrow down the set of changes to look at.
> > I don't think that it's worth installing the userland, unless you do
> > want to run that older version.
> >
> > I think that we can look at the changes between the last working version
> > and the first non-working one and see why the write is failing.  I wonder
> > if we end up writing to the wrong address for the framebuffer.  We might
> > need to build a version of the last working kernel with some extra debug,
> > but I think that we could do that using qemu.  I have qemu-system-sparc
> > running here, so it should be (relatively) straightforward to install the
> > version that works on the 4/330 in qemu and build custom kernels there
> > (I think that this would be easier/faster than using the real hardware!).
>
> NetBSD 1.x will probably not crossbuild from a modern compiler, but
> you may have a faster build if you installed the matching NetBSD/i386
> in an x86 vm or chroot and used build.sh :)
>
> I'll also chime in with Julian to suggest testing NetBSD 1.6 - 3 to
> try to find at which major release it broke. Once there it is likely
> to be debugging, or we could bisect the NetBSD current tree around
> that time, building test kernels (I've done that before using an older
> NetBSD release in a chroot to build. It is possible, but we'll see if
> needed :)

So after testing several kernels I found the last working version is
1.5.3 and the first not working version is 2.0. The 1.6.x kernels are
unknown, I tried booting several of them but all of them would drop to
sunmon after loading the kernel, some times with a memory alignment
error, some times with no error.

> I did notice that the newer kernel attaches bwtwo0 before cgfour0.
> Probably not significant... but might be

Yeah I noticed that on 1.5.x bwtwo0 and cgfour0 are detected back to
back but on 2.0 - current cgfour0 is detected well after bwtwo0.