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.cgi?prp=125769-1-txt&n=/patch.txt > > <snip> > > 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? <snip> > > 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_at_ucc.gu.uwa.edu.auReceived on Thu Oct 23 2008 - 04:17:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:36 UTC