Re: CURRENT kernel crashes on boot with BTX error

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
> 
> I'm not really sure if the process I'm using is supported, so I will 
> detail that first:
> 
> (CSup to Tuesday 21 Oct 2008 1100Z sources from cvsup6.au.freebsd.org)
> /usr/src-8# make buildworld && make buildkernel KERNCONF=GENERIC-DEBUG
> /usr/src-8# make installkernel KERNCONF=GENERIC-DEBUG INSTKERNNAME=gd-8
> /usr/src-8# nextboot -o "-D -h -s" -k gd-8

That should be fine.

> 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

> (Copied by hand because I can't convince the loader to output BTX errors 
> to serial console.)

make BTX_SERIAL=yes will enable this actually, but it's not enabled by default 
(for one, it's not nearly as intelligent, you can't change it 
via /boot.config, etc.).

> 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?

> 2. Any hints on where to go with the BTX error? I have compiled DDB into 
> this config, but haven't convinced the kernel to break into the debugger. 
> What little I've found on the web about BTX debugging suggests that it's 
> something of a black art.

I use this script (btxfault) to help parse the cs:eip stream into 
instructions:

% cat ~/work/envrepo/bin/btxfault
#!/bin/sh
#
# Takes cs:eip stream from a BTX fault as args

# Use sed to prefix all bytes with 0x
echo "$_at_" | sed -e 's/^/0x/' -e 's/[ -]/ 0x/g' | dh | ndisasm /dev/stdin

ndisasm is part of the devel/nasm port.  dh is a little utility I wrote that 
inverts 'hd' output (sort of).  That is, it takes input of the form '0xyy 
0xzz 0xaa 0xbb' and converts the hexadecimal strings to their byte values.

-- 
John Baldwin