Re: slot-based crash! not SBusFPGA (Re: CG14 in 8-bit color)

[David Brownlee <abs%netbsd.org@localhost>]

On Wed, 12 Jan 2022 at 18:25, Romain Dolbeau <romain%dolbeau.org@localhost> wrote:
>
> Le mer. 12 janv. 2022 à 18:07, David Brownlee <abs%netbsd.org@localhost> a écrit :
> > That's a little wild (though congratulations on finally finding it!)
>
> Yeah it's weird. A bit of luck was involved; I ended up trying to
> reproduce a real cg6 even more, and moving slots was really just to be
> thorough, I really didn't expect it to do anything.
>
> > I wonder what specific usage is triggering the issue
>
> Me too, I have honestly no idea of even (a) possible reason(s), let
> alone the real one(s).
>
> > - Known hardware issue: Could slot 1 not be certified for
> > framebuffers?
>
> Possibly, but as far I know slots in the SS20 are supposed to be
> identical. The only irregularity I remember is slot 3 in the 3-slots
> pizzabox (SS1, SS2) which is slave-only. And Sun would recommend
> putting the framebuffer there as framebuffers are slave-only devices,
> whereas other common SBus cards (Ethernet, SCSI, even high-speed
> serials) are bus masters.

Aha, that rings a bell. Neurons refreshed - thanks :)

> > - Software issue: Does SunOS/Solaris on the box show the issue (in
> > case its a usage pattern that only NetBSD triggers)
>
> Haven't tried either yet; I could try with either bw2 or cg3 - I
> suspect my cg6 emulation is nowhere near complete enough for
> period-accurate operating systems.
> The problem with SunOS/Solaris is that whereas they can use my dumb
> framebuffer emulation, neither will be able to use any of the other
> devices (USB, micro-sd, RAM disk). That's why I've stayed with NetBSD
> only so far.

That makes sense. It would be more a one off data collection pass than
anything, based on some old random USB devices which fell over if they
were talked to in anything other than the exact way Windows used.

> > - Specific trigger: It might be possible to run as a cg3 and "do less"
> > to see what is the minimum to trigger
>
> As far as I can tell, 'minimum trigger' is X11 + swap. I don't
> remember a crash under other circumstances. But I didn't try a lot of
> different things, either.
> And with just the cg3 emulation, X11 is pretty much only writing
> through SBus to the framebuffer (and maybe reading for
> read-modify-write, and maybe not even reading if the SW uses byte
> accesses) so there's little opportunity to mess up - unlike the cg6
> emulation where theoretically the VexRiscv core could inadvertently
> write to some random DVMA address and mess up other devices.

That's a pretty awkward reproducer :/ Was it just "startx then exit,
then reboot" or did stuff need to happen for a while (feel free to
punt on answering further, this is just me playing curious monkey as
opposed to likely being of any use, when plugging into another box
would likely just give the answer :)

> I haven't really had time to figure out the issue. I probably should
> try in another SS20 first, and if it works in Slot 1 there, I have my
> answer. If not, then I will need to find more time.
> But then on my 'todo' list, I also need to do a 8/24 FB with some
> acceleration, probably inspired by Michael's work on the SX, which is
> going to take time. Then think about another update to the carrier to
> get a proper video output (FPGA are OK at doing HDMI), but my current
> design will run out of pins - so with a different FPGA daughterboard
> as well... that project is an endless waste of time and money :-)

But such a _cool_ waste of time and money :-p

> So in the meantime I've found another way to waste time and money -
> I'm considering re-using the same FPGA daughterboard for a NuBus
> carrier for old Macs, where I could prototype the VGA and/or HDMI
> output (old 68k Macs are worse than SPARCstation when it comes to
> video output, at least the TGX+ and SX can do 1280x1024 and use 17"
> and 19" LCDs at native resolution, 68k Macs are stuck at 1152x870 at
> best and often at 1024x768 or even 832x624 or 640x480). The nice thing
> is that theoretically, I could get the same X11 acceleration in both
> NetBSD/mac68k and NetBSD/sparc eventually (should I manage to install
> a working NetBSD on my Quadra 650, primary target for NuBusFPGA is
> good old System 7 / MacOS 8 at first).

Ooo, as it happens I have a Duo 270c plus Duo Dock II
http://2.bp.blogspot.com/-4LU3si07i_U/UB0SqkcU6FI/AAAAAAAANVY/6b2oUDNRFFw/s1600/IMG_20120804_130630.jpg
so you have at least one customer - what would you be thinking of
charging for completed units? :) :) :)

> Of course the NuBus work would be even more useful if NetBSD/macppc
> supported the NuBus-based Power Macintoshes :-)

Careful, someone might threaten to ship you a nearly endless supply of
beer to try to get you to write the support!

David