From owner-freebsd-alpha Tue Mar 16 14: 0:32 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 C43FC151B5 for ; Tue, 16 Mar 1999 14:00:27 -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 WAA53760; Tue, 16 Mar 1999 22:02:37 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 16 Mar 1999 22:02:37 +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: > > 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? > > NT successfully, but that's not to say I actually consider it an OS ;) > Since this is exactly why I have these boxes, I'll try to burn one down > asap and try Linux or NetBSD on it. > > > > panic: ffs_valloc: dup inode > [ SNIP ] > > 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. > > That could be... Maybe I was just hoping that the VM is finally past the > 'Dave Rivers panic' stage. I could believe it's the hardware, except that > under 4.0-C it seems bulletproof. I'm going to continue hammering one of > these boxes and see what results. > > > > dec_axppci_33_intr_map: bad interrupt pin 30 > > Possibly dodgy firmware? > > I saw in the archives another Multia person had these messages. They > appear to be harmless. This message appears on Multia's but not UDB's. > I've flashed the SRM console/firmware to the latest available from DEC. > > Hmmmm. Is there a pattern here? > > On boot I get 6 pin 30's right after the probe message > > Probing for devices on PCI bus 0: > 6 times > ncr0: rev 0x01 inta irq 11 on pci0.6.0 > chip0: rev 0x03 on pci0.7.0 > de0: rev 0x23 int a irq 15 on pci0.8.0 > 1 time > 16 times > > > Is the fact I get 6 messages then find a device at pci0.6.0 a coincidence? > Also, some (warm?) warm boots under the 3.1-S kernel finds the following > before the isa probe and it's associated pin 30 messages: > > vga0: rev 0x00 on pci0.14.0 > (There's no vga device in there... Not even an expansion slot until > recently) > > So, is it possible these messages are a result of the pci probe code > stepping through all of the non-connected PCI addresses on the bus? Could > it be that because there is no possible way a device could ever show up > there (ie: no expansion bus) the chip just fires back interrupts on pin > 30? > > (Forgive my ignorance of the PCI code if this is not the way things > work... I've not had a chance to become aquainted adequately with the > PCI code ;) Possibly the code is seeing some sort of phantom device? Does it print anything more interesting for a verbose boot (boot -flags v from SRM)? -- 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