From owner-freebsd-alpha Tue Mar 16 13:20:43 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id D3BB915230 for ; Tue, 16 Mar 1999 13:20:08 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id VAA53561; Tue, 16 Mar 1999 21:22:04 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 16 Mar 1999 21:22:04 +0000 (GMT) From: Doug Rabson To: "Bruce M. Walter" Cc: freebsd-alpha@freebsd.org Subject: Re: Multia X-Files... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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