Date: Thu, 11 Mar 2004 22:23:04 -0500 From: Ken Smith <kensmith@cse.Buffalo.EDU> To: Tillman Hodgson <tillman@seekingfire.com> Cc: sparc64@freebsd.org Subject: Re: (was Re: HEADS UP! MAJOR change to FreeBSD/sparc64) Boot failure on rebuild Message-ID: <20040312032304.GB13945@electra.cse.Buffalo.EDU> In-Reply-To: <20040312031334.GP462@seekingfire.com> References: <p060204f5bc750679b827@[128.113.24.47]> <20040311165639.GJ462@seekingfire.com> <20040311170547.GA22014@ns1.xcllnt.net> <20040312031334.GP462@seekingfire.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 11, 2004 at 09:13:34PM -0600, Tillman Hodgson wrote:
>
> Ok, I cvsup'ed, 'make buildworld', 'make buildkernel', 'mergemaster -p',
> 'make installworld', 'make installkernel' and 'mergemaster'. And ...
> hrrm. It did not Go As Planned:
>
> FreeBSD 5.2-CURRENT #0: Thu Mar 11 18:44:21 CST 2004
> toor@caliban.rospa.ca:/usr/obj/usr/src/sys/CALIBAN
> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0506000.
> Timecounter "tick" frequency 360000000 Hz quality 0
> real memory = 402653184 (384 MB)
> avail memory = 376864768 (359 MB)
> cpu0: Sun Microsystems UltraSparc-IIi Processor (360.00 MHz CPU)
> nexus0: <OpenFirmware Nexus device>
> cpu0 on nexus0
> Timecounters tick every 0.976 msec
> ipfw2 initialized, divert enabled, rule-based forwarding enabled,
> default to accept, logging limited to 5 packets/entry by default
> IPsec: Initialized Security Association Processing.
> IP Filter: v3.4.31 initialized. Default = pass all, Logging = enabled
> Mounting root from ufs:/dev/ad0a
> setrootbyname failed
> ffs_mountroot: can't find rootvp
> Root mount failed: 6
> Manual root filesystem specification:
> <fstype>:<device> Mount <device> using filesystem <fstype>
> eg. ufs:/dev/da0a
> ? List valid disk boot devices
> <empty line> Abort manual input
> mountroot> ?
> List of GEOM managed disk devices:
>
> ^^^
> Blank list, naturally.
>
> It's a good thing I have a serial-over-ethernet terminal server :-)
>
> Any suggestions? This looks like a geom boot disk thing rather than a
> 64bTT thing, but what with the timing I thought I'd better explore all
> scenarios.
I *just* finished tracking this down like five minutes ago. If my
digging around is correct this is caused by the latest version of
sys/kern/subr_smp.c. If you apply the patch below and override
the kernel build's dislike for errors during compile (I was doing
this:
env WERROR= make kernel
because just commenting out the one line results in things being
defined but not used...) the kernel seems to work. You can probably
just back out this one file to rev 1.182 instead of the above contortions
if you want.
I just sent the analysis off to the person that did this
commit. I could be wrong about all this but we'll see what he says.
Index: subr_smp.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/subr_smp.c,v
retrieving revision 1.183
diff -u -r1.183 subr_smp.c
--- subr_smp.c 9 Mar 2004 03:37:20 -0000 1.183
+++ subr_smp.c 12 Mar 2004 02:49:47 -0000
@@ -121,7 +121,9 @@
1, /* no softc */
};
static devclass_t cpu_devclass;
+/*
DRIVER_MODULE(cpu, nexus, cpu_driver, cpu_devclass, 0, 0);
+*/
#ifdef SMP
/* Enable forwarding of a signal to a process running on a different CPU */
--
Ken Smith
- From there to here, from here to | kensmith@cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040312032304.GB13945>