Date: Tue, 16 Mar 1999 21:22:04 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: "Bruce M. Walter" <walter@fortean.com> Cc: freebsd-alpha@freebsd.org Subject: Re: Multia X-Files... Message-ID: <Pine.BSF.4.05.9903162059510.47099-100000@herring.nlsystems.com> In-Reply-To: <Pine.BSF.3.96.990316101930.27748B-100000@aries.fortean.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Mar 1999, Bruce M. Walter wrote: > Hello all, > > This is not a complaint or request for help... Merely a report of my > recent experiences with FreeBSD/alpha. I have a Personal Workstation > 500au which I will eventually move into a role as my development server > and thought it best to also pick up a Multia or two to act as frontline > machines for tracking current, stable and such. > > 3.1-R seemed quite happy on my Miata (once I had labeled the disks with > the 4.0-C utility ;) so I figured it was the place to start for the Multia > as well. I've pretty much found that older Quantum drives + the NCR > controller = CCB already dequeued problems, so I picked up an el-cheapo > Fireball ST. It's working, although the tagged openings have a tendency > to decrease and I can't turn off tagged queueing from camcontrol without > freezing the drive. > > Unfortunately, I was unable to get the 4.0-C kernel from the 2/6 snap to > load because of the kern_lock problems Julian fixed last night (thanks!), > so I wound up using a 3.1-R kern.flp along with a 3.1-S mfsroot.flp to > partition and install the 3.1-R distributions. This worked and produced a > complete 3.1-R system I was able to build a kernel from. > > Now we get into the X-Files part ;) The system, under both 3.1-R and > 3.1-S, would reboot without warning, apparently at random. This condition > persisted. After several attempts at building world I assumed it to be > faulty hardware, most likely memory. Since I had access to another Multia > NCR controller, I popped it in... Still problems. Finally, the machine > dropped into the the debugger instead of rebooting with no messages. The > message was I don't know what the exact reason for the spontaneous reboots might be but I suspect dodgy hardware. Do these multias run any other operating systems successfully? > > panic: ffs_valloc: dup inode > > In doing some searching, I found alot of similarities between my situation > and the 'Dave Rivers memorial panic.' This in and of itself didn't seem > strange, as I thought Dave's problems to be hardware related at the time. > What *IS* a mystery to me is now that I can boot a 4.0-C kernel, the > problems appear to be gone. With sources cvsupped as of late last night, > I've built world successfully twice. I have often seen this after rebooting from a crash. It is caused by fsck not picking up some inconsistency of the disk I think. > > I realize this is probably not very helpful, but wanted to post my > observations. This could be either: > > 1) Matt's recent fixes to the VM stuff has produced VM code which doesn't > exercise the faults in my hardware -or- > > 2) Matt's recent fixes to the VM stuff 'exorcised' the bugs causing my > problems and possibly one of the more elusive, recurring panics in > recent releases. I wonder if Dave still runs that old news server ;) > > Hopefully the second is true. Now, if I can just figure out how to get rid > of those annoying > > dec_axppci_33_intr_map: bad interrupt pin 30 > > messages during the Multia's PCI probe, I'd be a happy man. Ideas anyone? Possibly dodgy firmware? -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9903162059510.47099-100000>