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