From owner-freebsd-current@FreeBSD.ORG Tue Mar 19 09:55:49 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 41941657; Tue, 19 Mar 2013 09:55:49 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6097165B; Tue, 19 Mar 2013 09:55:47 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA09365; Tue, 19 Mar 2013 11:55:46 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UHtGk-000IJe-H6; Tue, 19 Mar 2013 11:55:46 +0200 Message-ID: <51483621.2060503@FreeBSD.org> Date: Tue, 19 Mar 2013 11:55:45 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: Re: gptzfsboot problem on HP P410i Smart Array References: <50311741.3000204@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Bjorn Larsson , Sergey Dyatko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 09:55:49 -0000 on 19/03/2013 07:41 Sergey Dyatko said the following: > I was faced with same problem on my laptop. Adding printf() into main() > before dsk = malloc(sizeof(struct dsk)); fix boot. Yesterday, avg@ proposed > patch: > Index: /usr/src/sys/boot/i386/zfsboot/zfsboot.c > =================================================================== > --- /usr/src/sys/boot/i386/zfsboot/zfsboot.c (revision 248421) > +++ /usr/src/sys/boot/i386/zfsboot/zfsboot.c (working copy) > @@ -302,6 +302,7 @@ > * region in the SMAP, use the last 3MB of 'extended' memory as a > * high heap candidate. > */ > + high_heap_size = 0; > if (bios_extmem >= HEAP_MIN && high_heap_size < HEAP_MIN) { > high_heap_size = HEAP_MIN; > high_heap_base = bios_extmem + 0x100000 - HEAP_MIN; > > it works for me, without printf() :) Can you test it ? A comment about a nature of this patch. Based on the previous investigation by Christoph Hoffmann and jhb: http://thread.gmane.org/gmane.os.freebsd.current/134199/focus=134309 I made a guess that either BIOS/firmware provides incorrect memory map or some agent in the BIOS/firmware (e.g. SMM handler) or controller firmware writes outside of a memory range reserved for it. I think that jhb made a similar guess at the time while Christoph conjectured that memory corruption was related to CPU caches or some such. My conjecture is that it is simply a combination of timing and a particular memory range. Just in case, here is how the memory map looks on the Sergey's system: SMAP type=01 base=0000000000000000 end=000000000009fc00 len=000000000009fc00 SMAP type=02 base=000000000009fc00 end=00000000000a0000 len=0000000000000400 SMAP type=02 base=00000000000e0000 end=0000000000100000 len=0000000000020000 SMAP type=01 base=0000000000100000 end=00000000bc1a1000 len=00000000bc0a1000 SMAP type=04 base=00000000bc1a1000 end=00000000bc1a4000 len=0000000000003000 SMAP type=01 base=00000000bc1a4000 end=00000000bdf04000 len=0000000001d60000 SMAP type=04 base=00000000bdf04000 end=00000000bdf3f000 len=000000000003b000 SMAP type=01 base=00000000bdf3f000 end=00000000bdf6a000 len=000000000002b000 SMAP type=02 base=00000000bdf6a000 end=00000000bdfbf000 len=0000000000055000 SMAP type=01 base=00000000bdfbf000 end=00000000bdfeb000 len=000000000002c000 SMAP type=03 base=00000000bdfeb000 end=00000000bdfff000 len=0000000000014000 SMAP type=01 base=00000000bdfff000 end=00000000be000000 len=0000000000001000 SMAP type=02 base=00000000be000000 end=00000000c0000000 len=0000000002000000 SMAP type=02 base=00000000f8000000 end=00000000fc000000 len=0000000004000000 SMAP type=02 base=00000000fec00000 end=00000000fec01000 len=0000000000001000 SMAP type=02 base=00000000fed10000 end=00000000fed14000 len=0000000000004000 SMAP type=02 base=00000000fed18000 end=00000000fed1a000 len=0000000000002000 SMAP type=02 base=00000000fed1c000 end=00000000fed20000 len=0000000000004000 SMAP type=02 base=00000000fee00000 end=00000000fee01000 len=0000000000001000 SMAP type=02 base=00000000ffe00000 end=0000000100000000 len=0000000000200000 SMAP type=01 base=0000000100000000 end=0000000140000000 len=0000000040000000 The algorithm for placing the heap picks up a range at bc1a4000, which is between two ranges of type '4' (ACPI NVS memory). So my idea was just to try a different memory range. Seems that it worked. P.S. I am not sure why our algorithm for selecting heap location is what it is. On all systems that I have I see that the "bios_extmem" range (the one starting at 0x100000) is usually the largest one and has more than enough space for both the heap and other things that are placed there. Additionally, in the case of zfsboot I think that we do not use memory above 1MB for anything else besides the heap. -- Andriy Gapon