Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 13 Nov 2011 18:56:12 +0100
From:      Stefan Esser <se@freebsd.org>
To:        Attilio Rao <attilio@freebsd.org>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: [amd64] Reproducible cold boot failure (reboot succeeds) in -CURRENT
Message-ID:  <4EC004BC.6060406@freebsd.org>
In-Reply-To: <CAJ-FndANGDEhiMm99Sx2__CNg3fxi8xtaU1GLugB3e-EOrf5Sg@mail.gmail.com>
References:  <4EBB885E.9060908@freebsd.org> <CAJ-FndBqwhS_Ez_2JV81LCE68edAHqWHTseBY5TzM_T%2B%2BS5xWw@mail.gmail.com> <4EBD10E6.9000302@freebsd.org> <CAJ-FndANGDEhiMm99Sx2__CNg3fxi8xtaU1GLugB3e-EOrf5Sg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Am 11.11.2011 13:15, schrieb Attilio Rao:
> Can you try rebuilding your kernel and modules from scratch and see if
> it fixes your problem?

Sorry for the delay, but my system seems to need being turned off (S5)
for many hours (whole night) to reproduce the problem ...

I had already rebuilt my kernel multiple times in the last weeks. But
just to be sure, I removed the build directories for kernel and world
and built a new kernel after building and installing world from scratch.
The next reboot (with boot  blocks from the freshly built world) failed
again ...

But the first lines of boot messages look strange:

...
WARNING: WITNESS option enabled, expect reduced performance.
Table 'FACP' at 0xba918a58
Table 'APIC' at 0xba918b50
Table 'SSDT' at 0xba918be8
Table 'MCFG' at 0xba918dc0
Table 'HPET' at 0xba918e00
ACPI: No SRAT table found
Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81109000
Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff81109370 <--
kldload: unexpected relocation type 67108875
kernel trap 12 with interrupts disabled

The irritating detail is the load address of "zfs.ko", which is just
0x370 bytes above the kernel load address ...

A verbose boot scrolls these lines off the screen to fast (and is to
long to be preserved in dmesg.boot from the start), so I do not have any
idea whether other values are reported in case of a successful boot.

I had already assumed that memory was corrupted during early start-up,
but now I think that gptzfsboot writes the zfs kernel module over the
start of the loaded kernel. I'll try some more tests later today.

Regards, STefan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EC004BC.6060406>