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

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

On Mon, Jan 27, 2025 at 10:38 AM David Brownlee <abs%netbsd.org@localhost> wrote:
>
> On Mon, 27 Jan 2025 at 13:22, foo bar <tokenalt%gmail.com@localhost> wrote:
> >
> > On Mon, Jan 27, 2025 at 4:29 AM Julian Coleman <jdc%coris.org.uk@localhost> wrote:
> > >
> > > Hi,
> > >
> > > > So as the subject says I'm having problems with these two
> > > > framebuffers. It seems to be related to the issue reported a few
> > > > months ago here.
> > >
> > > > Luckily my cgfour is still working and I've attached a dmesg from
> > > > current below. Any help would be appreciated.
> > >
> > > > 1152 x 900cpu0: data fault: pc=0xe80112e4 addr=0xfe02a000
> > > > ser=0x8002<WRITE,SZERR>
> > >
> > > I tried to test 4/300 card, but the power supply has failed in my 4/330.
> > > I'm still puzzled as to exactly what causes the size error for the P4 bus
> > > write.  Like last time, we could try by trial and error, but it might be
> > > an extended process.
> > >
> > > David's suggestion is good though - if you can check that it boots with an
> > > earlier kernel, then we could look at the differences in the P4 bus setup,
> > > which would give us a good starting point.
> >
> > I sent a reply to David yesterday but I accidentally sent it just to
> > him and not the list, here it is below.
> >
> > 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?

>uai, uao, ua9600, ub9600, ue
>b le()
Using IP Address 10.0.0.33 = 0A000021
Boot: le(0,0,0)
Booting from tftp server at 10.0.0.4 = 0A000004
Downloaded 68966 bytes from tftp server.

>> NetBSD/sparc Secondary Boot, Revision 1.15 (Mon Jan 13 02:23:29 UTC 2025)
Booting netbsd
Using IP Address 10.0.0.33 = 0A000021
Trying BOOTP protocol... bootp: no reply
Trying BOOTPARAMS protocol... ip address: 10.0.0.33, hostname: tycho
root addr=10.0.0.4 path=/export/root/tycho/netbsd_current
2381409+115748+235184 [153296+111862]=0x2ebf0c
Copyright (c) 1996, 1997, 1998, 1999, 2000
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 1.5 (GENERIC) #1: Wed Nov 29 00:29:52 MET 2000
    root@flambard:/usr/src/sys/arch/sparc/compile/GENERIC
total memory = 32704 KB
avail memory = 27736 KB
using 217 buffers containing 1736 KB of memory
bootpath: /obio0/le0
mainbus0 (root): SUN-4/300 series
cpu0 at mainbus0: cache chip bug; trap page uncached: CY7C601 @ 25
MHz, L64812 or ACT8847 FPU
cpu0: 128K byte write-back, 16 bytes/line, sw flush: cache enabled
obio0 at mainbus0
timer0 at obio0 addr 0xef000000 delay constant 10
dma0 at obio0 addr 0xfa001000 level 4: rev 0
le0 at obio0 addr 0xf9000000 level 6: address 08:00:20:10:ad:b3
le0: 8 receive buffers, 2 transmit buffers
esp0 at obio0 addr 0xfa000000 level 4: ESP100A, 24MHz, SCSI ID 7
scsibus0 at esp0: 8 targets, 8 luns per target
clock0 at obio0 addr 0xf2000000: mk48t02 (eeprom)
memreg0 at obio0 addr 0xf4000000
zs0 at obio0 addr 0xf1000000 level 12 softpri 6
zstty0 at zs0 channel 0 (console i/o)
zstty1 at zs0 channel 1
zs1 at obio0 addr 0xf0000000 level 12 softpri 6
kbd0 at zs1 channel 0
ms0 at zs1 channel 1
zs2 at obio0 addr 0xe0000000 level 12 softpri 6
zstty2 at zs2 channel 0
zstty3þþþþþþþþ at zs2 channel 1
bwtwo0 at obio0 addr 0xfb300000 level 4: bwtwo/p4, 1152 x 900
bwtwo0: cgfour overlay plane
bwtwo0: attached to /dev/fb
cgfour0 at obio0 addr 0xfb300000 level 4: cgfour/p4, 1152 x 900
cgfour0: replacing bwtwo0
cgfour0: attached to /dev/fb
sparcvme0 at mainbus0
vme0 at sparcvme0
scsibus0: waiting 2 seconds for devices to settle...
probe(esp0:3:0): max sync rate 4.80MB/s
sd0 at scsibus0 target 3 lun 0: <Sun, SUN0699, 2.0> SCSI2 0/direct fixed
sd0: 670 MB, 1694 cyl, 15 head, 54 sec, 512 bytes/sect x 1372160 sectors
probe(esp0:6:0): max sync rate 4.80MB/s
cd0 at scsibus0 target 6 lun 0: <ZULUSCSI, CDROM, 2.0> SCSI2 5/cdrom removable
root on le0
nfs_boot: trying RARP (and RPC/bootparam)
nfs_boot: client_addr=10.0.0.33 (RARP from 10.0.0.4)

Watchdog reset.
>


> > However this
> > framebuffer works fine on sun3 so I believe it's something specific to
> > sparc. Using printf() I found the line causing the panic is this.
> >
> > bt->bt_addr = 0;
> >
> > I've been scratching my head for a while now trying to figure out how
> > and why this causes it. My only guess is that it only accepts 8 bit
> > writes. But that would be rather odd as no other sun framebuffer had
> > that limitation from what I can tell looking at the drivers. Not
> > really sure where to go from here.
>
> Does anyone have a SunOS dmesg to hand to confirm the address values
> match those used by NetBSD?

SunOS Release 4.1.1 (GENERIC) #1: Fri Oct 12 18:17:55 PDT 1990
Copyright (c) 1983-1990, Sun Microsystems, Inc.
cpu = Sun SPARCsystem 300
mem = 32768K (0x2000000)
avail mem = 31055872
Ethernet address = 8:0:20:10:ad:b3
sm0 at obio 0xfa000000 pri 2
st0 at sm0 slave 32
st1 at sm0 slave 40
st2 at sm0 slave 24
st3 at sm0 slave 16
sr0 at sm0 slave 48
   defaulting to generic cdrom
sd0 at sm0 slave 0
sd1 at sm0 slave 1
sd2 at sm0 slave 8
sd3 at sm0 slave 9
sd4 at sm0 slave 16
sd6 at sm0 slave 24
sd6:  <SUN0669 cyl 1614 alt 2 hd 15 sec 54>
zs0 at obio 0xf1000000 pri 3
zs1 at obio 0xf0000000 pri 3
zs2 at obio 0xe0000000 pri 3
le0 at obio 0xf9000000 pri 3
cgfour0 at obio 0xfb300000 pri 4
bwtwo0 at obio 0xfb300000 pri 4
bwtwo0: resolution 1152 x 900
root on sd6a fstype 4.2
swap on sd6b fstype spec size 32400K
dump on sd6b fstype spec size 32376K