Re: Supermicro X8DT6 crashes in bootloader after r239066

On Tue, Oct 30, 2012 at 08:34:53PM -0400, Ryan Stone wrote:
> I have a X8DT6 that appears to crash in the bootloader from HEAD.  I say
> "appears to" because it's difficult to really see what the problem is; the
> system reboots pretty much as soon as it enters the FreeBSD boot process.
> The problem affects PXE booting, booting from ZFS on GPT on a SATA drive
> and UFS on MBR on a USB stick.
> 
> The problem only occurs if I have any SATA disks plugged in.  If I remove
> all SATA disks I can successfully PXE boot or boot from a USB key.  I've
> tried with a couple of different SATA disks, some with GPT and some with
> MBR, and the reboot happens in both cases.
> 
> The last things that I see on the serial console before the reboot is:
> 
> DHCP..-
> 
> ^[[06;07H^[[06;00HDH
> CP..\
> ^[
> [06;07H^[[05;00HCLIENT MAC ADDR: 00 25 90 92 19 94  GUID: 84F7C23B 5F21
> 2533 625
> C 002590921994  ^[[06;00HCLIENT IP: 172.16.1.50  MASK: 255.255.255.0  DHCP
> IP: 1
> 72.16.1.1                ^[[07;00HGATEWAY IP:
> 172.16.1.1
>                                   ^[[08;00HPXE Loader
> 1.00^[[2JM-^_at_^[[01;00H^[[0
> m^[[2m^[[0m^[[2;30;40m
> ^_at_^[[0m^[[2;37;40m
>                                         ^[[02;00H^[[0m^[[2;30;40m
> 
> So it really doesn't seem to get very far at all.
> 
> I've bisected and confirmed that the problem was introduced in r239066.  I
> tried reverting that commit locally and I can boot fine again.  I took a
> quick look at that commit but it appears to be way over my head.  I'm
> willing to test patches or gather more debugging information; this thing
> isn't going anywhere until I can get it booting. :)

I have one of these X8DT6 systems.  It has grub2 as the primary boot
loader which then loads zfsloader.  Many weeks back I updated the BIOS,
grub, and FreeBSD and ran into a similar problem -- zfsloader would
start, print a few messages, and then the system would reboot.  I
tracked it down to the int 0x13 call (with eax=0x4800) in bd_int13probe.
It would walk past the end of the edd_params structure and corrupt the
return address on the stack.  I worked around it by padding edd_params.
I was planning to debug it further to find out which of the 3 things
that were updated caused the problem but Other Things(tm) came up.  See
if this works for you too:

diff -r d35d326e437a -r e5228169f3f1 sys/boot/i386/common/edd.h
--- a/sys/boot/i386/common/edd.h        Tue Oct 30 21:51:09 2012 -0700
+++ b/sys/boot/i386/common/edd.h        Tue Oct 30 21:51:20 2012 -0700
_at__at_ -62,6 +62,7 _at__at_ struct edd_params {
        uint16_t        sector_size;
        uint16_t        edd_params_seg;
        uint16_t        edd_params_off;
+       char            pad[64];
 };

Regards,
Navdeep