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

David Brownlee <[email protected]>
Newsgroups gmane.os.netbsd.ports.sparc
Message-ID <CAGN_6pYKoqBK+mk26V-6d=DGuD3yZqUnV0XS9EhN9m8y_kFN7A@mail.gmail.com>
On Wed, 29 Jan 2025 at 09:20, Julian Coleman <[email protected]> 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 :)

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

David
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.