From owner-freebsd-alpha@FreeBSD.ORG Wed Nov 10 20:03:06 2004 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F76216A4D0; Wed, 10 Nov 2004 20:03:06 +0000 (GMT) Received: from tabernacle.vortex4.net (tabernacle.vortex4.net [69.36.240.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id C490143D39; Wed, 10 Nov 2004 20:03:01 +0000 (GMT) (envelope-from friend@vortex4.net) Received: from paquita (c-67-169-10-21.client.comcast.net [67.169.10.21]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by tabernacle.vortex4.net (Postfix) with ESMTP id A39282848D; Wed, 10 Nov 2004 12:03:01 -0800 (PST) Received: from friend by paquita with local (Exim 3.35 #1 (Debian)) id 1CRyjf-0007fw-00; Wed, 10 Nov 2004 12:06:31 -0800 Date: Wed, 10 Nov 2004 12:06:31 -0800 To: Sven Petai Message-ID: <20041110200631.GA789@vortex4.net> References: <20041108111610.GA19719@bsd.ee> <20041109100007.GF43113@ip.net.ua> <200411102117.31780.hadara@bsd.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411102117.31780.hadara@bsd.ee> X-Operating-System: Linux paquita 2.6.7 X-System-Stats: 08:29:11 up 1 min, 2 users, load average: 0.37, 0.14, 0.05 User-Agent: Mutt/1.5.6+20040907i From: Dave cc: freebsd-alpha@freebsd.org Subject: Re: 5.3 broken on AlphaPC 164LX X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2004 20:03:06 -0000 We may be having similar issues; I tried the 5.2.1-> 5.3 migration again and has the same results as I posted a few days ago; I am SCSI and maxed out with 512MB memory in 4 sticks. Furthermore, the last time I booted I hit space to stop the automatic boot sequence and got something new: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK *** Unexpected System Machine Check through vector 660 Machine Check Logout Frame @ 0x6068 Code = 0x207 Machine Check Code - 0x207 Non-Existant Memory Error Alpha 21164PC IPRs: EXC_ADDR: 0000000000072674 EXC_SUM: 0000000000000000 EXC_MASK: 0000000000000000 ISR: 0000000080200000 ICSR: 0000004064020000 IC_PERR_STAT:0000000000000000 DC_PERR_STAT:0000000000000000 VA: 00000089000003FE MM_STAT: 0000000000005010 CBOX_ADDR: F480010000012C24 CBOX_STAT: 0000000000000180 PAL_BASE: 000000000000C000 Pyxis Error Registers ERR: 80000008 STAT: 00000000 ERR_MASK: 00000B98 ECC_SYN: 00000000 MEAR: 000003F0 MESR: 160001E9 PCI_ERR0: 06200206 PCI_ERR1: 7065646C PCI_ERR2: 7065646C Pyxis Memory Control Registers MCR: 003A1C00 BBAR0: 00000000 BCR0: 000000E5 BTR0: 00000022 BBAR1: 00000400 BCR1: 000000E5 BTR1: 00000022 *** Console Stopped because of 660 Machine Check *** *** Press HALT Button to return to console !! *** This is COMPLETELY new for me; I have been rock solid from 5.0-RELEASE through 5.2.1, and this is the first time anything like this has happened. Dave On Wed, Nov 10, 2004 at 09:17:31PM +0200, Sven Petai wrote: > On Tuesday 09 November 2004 12:00, Ruslan Ermilov wrote: > > On Mon, Nov 08, 2004 at 01:16:10PM +0200, Sven Petai wrote: > > > Hi I'm having some problems with getting 5.3 to work on > > > a pcalpha (AlphaPC 164LX). This box was running 5.2.1 > > > until now without any problems. Basically it now panics > > > in most cases right after trying to execute init, > > > sometimes it just hangs there forever. > > > boot messages & panic & some ddb output is available @ > > > http://bsd.ee/~hadara/debug/pcalpha/pcalpha_panic_08.11.2004.txt > > > kernel config is available at: > > > http://bsd.ee/~hadara/debug/pcalpha/kernel.txt > > > > > > any debug ideas ? > > > > I have AlphaPC 164SX which is basically the same h/w, and > > it runs without any illness. > > hmm but are you using IDE or SCSI disks ? > I'm closing in on the commit that broke it for me and currently it seems to be > something ATA related. > > > > > > if there aren't any better ones then I will just try to > > > trace down the commit that caused it by cvsuping up/down > > > but that will probably take at least a week... > > > > Can you check that it's not a bad memory issue? > > well.. I guess one can never be sure about that but... > a) it was stable under 5.2.1 > b) it has 512M of memory which consists of 4 sticks, taking lower ones out > and replacing them with 2 higher ones didn't make much difference (it hangs > instead of crashing). using random combinations of the 2 sticks doesn't make > any difference either. So the crash vs. hang behaviour seems to be tied only > to amount of memory. > c) SRMs built in memory testing tool didn't find anything interesting either > d) i'm not 100% sure but I believe this machine uses ECC ram so I should > probably get ECC error > > so considering all this together, I think it's rather certain that I'm not > having just a faulty memory problem here > > > > > PS > > > how can I tell kernel were it should dump core when it can't > > > reach userland to use dumpdev command ? > > > I tried various ways like setting dumpdev=/dev/ad2b from loader > > > and tried to compile it into kernel, without much luck > > > > Good question. Setting dump device early from loader(8) has > > not been supported since 2002 when Poul-Henning re-implemented > > it for GEOM. > > > > maybe references to that possibility should be removed from loaders manpage > and developers handbook then... > _______________________________________________ > freebsd-alpha@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-alpha > To unsubscribe, send any mail to "freebsd-alpha-unsubscribe@freebsd.org" -- Dave Cotton friend@vortex4.net