Date: Sun, 27 May 2001 12:35:12 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: John Baldwin <jhb@FreeBSD.ORG> Cc: alpha@FreeBSD.ORG Subject: Re: HEADS UP: loader broken Message-ID: <15121.11456.143667.486928@grasshopper.cs.duke.edu> In-Reply-To: <XFMail.010525163719.jhb@FreeBSD.org> References: <XFMail.010525163719.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin writes: > Looks like the loader is hosed: > > Loading /boot/loader > Console: SRM firmware console > VMS PAL rev: 0x1000000010114 > OSF PAL rev: 0x1000000020116 > Switch to OSF PAL code succeeded. > > FreeBSD/alpha SRM disk boot, Revision 1.1 > (jhb@baz.osd.bsdi.com, Fri May 25 16:22:52 PDT 2001) > Memory: 262144 k > \ > halted CPU 0 > > halt code = 2 > kernel stack not valid halt > PC = 200000000 > boot failure > >>> e ra > gpr: 1A ( R26) FFFFFC00005A21B4 > > Hmm. Crap would be a good term here I think. loader.old doesn't work either. > It seems to die while loading the kernel. I wonder if my kernel is too big and > is now triggering a bug in the loader? This is a major PITA now. :( > > For loader.old the RA is 0x0000000020025F18 > > Hmm, I seem to be rather screwed now until I can take this drive out and move > it to another system I suppose. :( > Since loader.old is screwed too, I'd guess the culprit is the extra allocation in src/sys/boot/forth/loader.4th rev 1.20 I just tried to start tracking this down, but my UP1000 test machine seems to still boot with the new loader. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15121.11456.143667.486928>