[rescue] best NetBSD support

[Eric Dittman]

> There are hints that NetBSD itself doesn't damage the firmware -- that
> the damage is somehow incurred by other actions.  I'm not a VAX expert
> though and I certainly know very little about the 4000/90's internals
> and design.  Even so I find it stunning that the firmware can be somehow
> damaged irreparably.  Firmware is nothing but software encoded in some
> form of normally read-only memory.  If it got encoded there once then it
> can be encoded there again, even if doing so necessitates replacing the
> media it's encoded on.

I've seen reports that booting NetBSD caused the corruption.  The
problem with reprogramming in place is the corruption causes the
firmware updater (if you can get it) to abort.

> > That's a nice trick with a soldered-in EEPROM.  Most people
> > can't handle desoldering them without further damage.
> 
> Such unskilled people should probably avoid such hardware then...

*IF* they know about it ahead of time.

> (of course if an EEPROM can be "damaged" in-circuit then that suggests
> it can be "repaired", i.e. reprogrammed, in-circuit too)

See above.

> > When someone says something works just fine, then others will
> > accept this, esp. if the report is listed on the official
> > NetBSD web site.
> 
> Anyone and everyone can file a PR to the GNATS database.  It'd take
> quite an act of sabotage and/or subterfuge to elide such a PR unnoticed
> from the DB.  If you have proof of such damage, or know someone who
> does, then I _STRONGLY_ suggest that you or that someone file a PR.

Again, since the problem is known the the NetBSD/VAX developers,
there's no need to file since the people that can fix it know about
it.

> In the mean time there are those who say that NetBSD-current (and
> presumably that now means 1.6-BETA too) runs fine on 4000/90's and they
> seem to be able to provide proof of this fact.

The problem may have finally been fixed in 1.6-BETA, but until I
see proof of that I'm still doubtful, given that they said it was
working before when it caused the problem.

A good way to see if the firmware is corrupted with the new version
is to try to install VMS.  If you can install VMS, and VMS can
correctly identify the system type, then I'd say the bug is fixed.

> I'm sitting on the fence not knowing who to believe and without
> technical data to back up the failure mode I'm leaning towards calling
> it operator error, not a NetBSD bug.

If booting NetBSD causes the error then I'd say the bug is a
NetBSD bug.

> > It's a known issue with the NetBSD/VAX developers.
> 
> Perhaps it is, but it's not documented in the GNATS PR database, at
> least not with something obvious like "4000/90" somewhere in the text.
> Those who know of it don't seem to agree on the cause though, and it's
> pretty damn difficult to fix something when the cause is still a
> mystery.  Perhaps the problem is really a hardware bug, and if so it may
> be difficult to avoid triggering it, and if so it's certainly impossible
> to fix it with software alone.  If you have insight into this mystery
> then I suggest you file a PR contianing your valuable knowledge.

I doubt the problem is a hardware bug, more likely they are twiddling
bits they shouldn't.  I know I've never seen VMS corrupt a 4000/90.
At the very least the NetBSD/VAX developers should check the bits
they twiddle against the VMS source to make sure they understand
what they are doing.  And if they've fixed the problem, then that
may be just what they did.

> >  They just
> > haven't bothered fixing it.  They are the one that *SHOULD*
> > have the know-how to fix this bug.  Instead they devote their
> > time to newer projects.  Software is being written, but not
> > completed.
> 
> There _you_ go now deciding how some volunteer should spend his or her time.

Now, I'm reporting a problem and an inability to fix it.  I want
to prevent faulty software from killing another nice 4000/90.  The
NetBSD/VAX people didn't finish the port, but said they did.

> > It's kind of like MAME.  People were adding more and more games
> > so they could say MAME supported them, but the known bugs in
> > the already supported games weren't being fixed.  A couple of
> > time there were freezes on adding new games so the current
> > bugs could be fixed, but that didn't help much.  Most of the
> > people writing the drivers were more interested in how many
> > games they could add rather than completing their old drivers.
> 
> And yet again you're deciding how some volunteers should spend their time.

Again, the game isn't supported if there are bugs, even if the
people writing the drivers said they are.

> Put your money where your mouth is....

I am.  I am warning people of a possible problem.  If you don't
like that, too bad.
-- 
Eric Dittman
dittman at dittman.net
Check out the DEC Enthusiasts Club at http://www.dittman.net/