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>