Port-sparc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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 :)

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

David


Home | Main Index | Thread Index | Old Index