Has anyone seen problems with alphas mysteriously dying after a couple of
dozen hours of operation? I'm seeing panics to the effect of "vref instead
of vget" (or perhaps the other way around) on my machine. This is with a
stock 1.4 installation, GENERIC kernel, etc.. I am using a DE450 Tulip
ethernet card and NCR SCSI card, and no video card.

Grepping through the source shows "vref" and "vget" only showing up together
in the NFS code. But I'm not running any NFS servers or clients, so I
suspect I'm barking up the wrong tree. Is this something that has been seen
in the past? I'm aware that the NCR driver is a little buggy, but it doesn't
appear to be a disk problem so far. I seem to be able to hasten a crash if I
do lots of file transfers, i.e. FTP, but no one application is a known
culprit. So I'm wondering if it could be the network driver.

One other area I'm guessing could be a culprit is my use of UW-SCSI drives
with a non-UW-SCSI card. I had been planning to use a SymBios 53c875-based
UW-SCSI card, but that wouldn't boot, so I had to go back to an older
53c810-based one. Could that be it?

So, my options, I think, are (a) switch ethernet cards to a 3COM 3c900,
and/or (b) I have an adaptec 2940UW, and hang a small boot drive off of the
NCR just to get the machine start with. If anyone has ideas on how to get
this machine to stay up without dying I'd really appreciate it.

thanks,
Edwin

ps: here's the relevant parts of dmesg

de0 at pci0 dev 5 function 0
de0: interrupting at eb164 irq 9
de0: DEC DE450-CA 21041 [10Mb/s] pass 1.1
de0: address 00:00:f8:07:00:c8
ncr0: interrupting at eb164 irq 8
ncr0: minsync=25, maxsync=206, maxoffs=8, 16 dwords burst, normal dma fifo
ncr0: single-ended, open drain IRQ driver
ncr0: restart (scsi reset).
scsibus0 at ncr0: 8 targets, 8 luns per target
sd0(ncr0:0:0): 10.0 MB/s (100 ns, offset 8)
sd1(ncr0:1:0): 10.0 MB/s (100 ns, offset 8)
probe(ncr0:4:1): 10.0 MB/s (100 ns, offset 8)