[rescue] best NetBSD support

[Greg A. Woods]

[ On Monday, June 17, 2002 at 14:19:26 (-0500), Eric Dittman wrote: ]
> Subject: Re: [rescue] best NetBSD support
>
> > > People run it in spite of the problem.  Check GoogleGroups and
> > > you'll see that this is a known bug.  Once you are bitten, though,
> > > a mainboard replacement is your only option.
> > 
> > I read the lists -- I've followed the debate on the problem.  It's not
> > nearly so black&white as you suggest.
> 
> How so?  It either does or doesn't damage the firmware.

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.

> 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...

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

> 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.

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.

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.

> 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.


>  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.

> 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.

Put your money where your mouth is....

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods at acm.org>;  <g.a.woods at ieee.org>;  <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>