Hi John,

Thanks for your reply.

On Wed, 22 Oct 2008, John Baldwin wrote:
> On Wednesday 22 October 2008 12:50:15 am David Adam wrote:
> > I've been trying to build an 8-CURRENT kernel on my 7.0-RELEASE system in
> > order to test out some patches that Pyun YongHyeon has prepared.
> > Unfortunately, I cannot get a GENERIC+DDB kernel to boot on my
> > machine.
> >
> > This is an Intel SR1200 Pentium 3-class system - there is a dmesg from
> > 7.0-RELEASE in the first part of
> > http://www.freebsd.org/cgi/query-pr....t&n=/patch.txt
> >


> > The kernel loads, the various modules I have specified in loader.conf are
> > loaded, and the loader screen appears. However, when I select "boot", the
> > expected line with the kernel version does not appear: instead, the
> > spinner briefly spins, switches to the bold colour, and then crashes with
> > a BTX error:
> >
> > int=0000000d err=00000000 efl=00010a13 eip=00000430
> > eax=ffffffb4 ebx=00006c47 ecx=0000000a edx=00000080
> > esi=00000001 edi=ffff9414 ebp=00000000 esp=0008f8b4
> > cs=002b ds=0033 es=002b fs=0033 gs=0033 ss=0033
> > cs:eip=6c 7f 94 48 00 00 00 00-0f af c1 47 00 00 00 00
> > 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
> > ss:esp=2b 00 00 00 33 00 47 91-00 fc 03 00 5f ad 08 04
> > 00 00 00 00 3f 00 00 00-00 00 00 00 c4 0f 06 00
> > BTX halted

>
> It went off into the weeds. The cs is still a 32-bit loader segment, but the
> eip value is a bit too low. The instruction stream:
>
> 00000000 6C insb
> 00000001 7F94 jg 0xff97
> 00000003 48 dec ax
> 00000004 0000 add [bx+si],al
> 00000006 0000 add [bx+si],al
> 00000008 0FAFC1 imul ax,cx
> 0000000B 47 inc di


I'm afraid this means nothing to me - any likely proximate causes?


> > 1. Is this an acceptable method of testing a CURRENT kernel? I also tried
> > building a new world and kernel with DESTDIR set to another partition but
> > had similar problems. Unforunately this machine does not have a reliable
> > CD drive so I can't use a snapshot CD to install.

>
> I wonder if building and install a new loader would fix it. If it does, that
> still indicates a bug (7.0 loader should be able to load and boot an 8.0
> kernel). Hmm, you see this after doing a boot? It's possible that you are
> actually in the kernel when you fault then, in which case it could be a
> kernel issue with your hardware somehow. If you do a boot -v, do you get any
> output from the kernel before the machine crashes?


Yes, this occurs after the 'boot' command at the loader prompt. 'boot -v'
(or at least the "verbose boot" option in the loader menu) produces no
extra output.

I did try a loader from the CURRENT sources, which produced the same
output.

However, the plot thickens. When I don't specify the kernel name with
nextboot(8), but instead interrupt the loader and use 'unload; load
/boot/kernel/gd-8; load /boot/kernel/gd-8/geom_mirror.ko' and so on for my
other modules, the kernel boots quite happily - both using the 7.0 loader
and the new one from the CURRENT sources.

Are there likely to be big differences in the boot process between using
nextboot(8) and the unload/load method? I've used nextboot(8) to
successfully load other kernels on this machine before.

In any case, now that I have a successful workaround I can try the patches
I was after in the first place. If there's any more information I can
provide, or you'd like access to this system (it has serial console and
remote power control), let me know.

David Adam
zanchey@ucc.gu.uwa.edu.au

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"