Date: Wed, 10 Nov 2004 21:17:31 +0200 From: Sven Petai <hadara@bsd.ee> To: Ruslan Ermilov <ru@freebsd.org> Cc: freebsd-alpha@freebsd.org Subject: Re: 5.3 broken on AlphaPC 164LX Message-ID: <200411102117.31780.hadara@bsd.ee> In-Reply-To: <20041109100007.GF43113@ip.net.ua> References: <20041108111610.GA19719@bsd.ee> <20041109100007.GF43113@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411102117.31780.hadara>