>I have two multias... one just died running netbsd.  Seems to be
>a real problem for me because this is the third alpha I've returned
>that has failed to work (at all) after it ran netbsd.  The wierd thing
>is that these alphas run NT just fine for days and days.... Put netbsd
>on them and they don't even boot to the SRM console after two days of non-stop
>idle time.  I point this out because I wonder if anyone else has the same problems?
>An added bit of info, before the machine died, it would boot/run netbsd for a
>random period of time before failing.  

I've heard of a _lot_ of people having problems that were
hardware-related, and which looked hardware-related with the multias.

One of the two i was shipped was DOA, but since then everything's been
grand.  I think the secret to my success is that once I got a working
system, I didn't modify the kernel or system binaries.  This has led
my home machine (the multia that i'm typing this from, ssh'd through
my PPP gateway) to uptimes of > 30 days.  (I would quote an impressive
uptime number, but i halted it the other day because i went on a two
day trip and didn't want to leave any machines other than my gateway
on.  8-)


>Now for the real question I have.  I don't have this mysterious green book or
>any other real documentation on the SRM env vars and programs.  I swapped out
>this one alpha that died with another that was running NT for weeks of uptime.
>This NT worked fine on the ethernet.  I happen to have NetBSD on an external drive,
>so all I had to do was switch the machine to srm console mode and boot off the 
>drive.  It comes up fine, but refuses to talk on the ethernet.

I assume this isn't a problem with enabling the BNC connector, or
whatever it is?  I don't know remember what the resolution there was,
but as far as I know it isn't possible to use the BNC connector on the
Multia.


> Ifconfig shows it working, the boot manifest shows it working, but ping or
> traceroute or routed or whatever fails.
> 
> I hope someone has had this problem and knows a solution.

There are certainly problems with the de driver in -current.  I
_strongly_ recommend people building new kernels for themselves use
the old version.  (I'm pretty sure that either a copy of the old
version, or diffs to get back to the old version were posted to
current-users not too long ago.  If anybody needs a copy of the old
version, get in touch with me.)  I built the snapshot kernels with the
old version of the driver, since the new version is unstable (to the
point of occasionally causing machine checks) on my systems.  (I can't
conclusively prove that the machine checks were caused by the de
driver, but rolling back the driver with no other changes to the
kernel source caused the machine checks to go away... 8-)



cgd