From owner-freebsd-alpha Tue Mar 16 13:51:12 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from aries.fortean.com (aries.fortean.com [209.42.229.210]) by hub.freebsd.org (Postfix) with ESMTP id 23B2515143 for ; Tue, 16 Mar 1999 13:50:46 -0800 (PST) (envelope-from walter@fortean.com) Received: from localhost (walter@localhost) by aries.fortean.com (8.8.8/8.8.8) with SMTP id QAA00336; Tue, 16 Mar 1999 16:49:05 -0500 (EST) (envelope-from walter@fortean.com) X-Authentication-Warning: aries.fortean.com: walter owned process doing -bs Date: Tue, 16 Mar 1999 16:49:05 -0500 (EST) From: "Bruce M. Walter" To: Doug Rabson 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 > 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 ;) - Bruce ______________________ Bruce M. Walter, Principal NIXdesign Group Inc. 426 S. Dawson Street Raleigh NC 27601 USA 919.829.4901 Tel (ext 11) 919.829.4993 Fax http://www.nixdesign.com Visual communications | concept + code To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message