From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 22:56:30 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 D6C983E2; Wed, 20 Mar 2013 22:56:30 +0000 (UTC) (envelope-from christoph_hoffmann@me.com) Received: from nk11p04mm-asmtp001.mac.com (nk11p04mm-asmtpout001.mac.com [17.158.236.236]) by mx1.freebsd.org (Postfix) with ESMTP id C06869B8; Wed, 20 Mar 2013 22:56:30 +0000 (UTC) Received: from tunnel8.sec101.ch ([62.2.44.120]) by nk11p04mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MJZ0070WBLK0I80@nk11p04mm-asmtp001.mac.com>; Wed, 20 Mar 2013 21:56:12 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-03-20_06:2013-03-20,2013-03-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1302030000 definitions=main-1303200197 Subject: Re: gptzfsboot problem on HP P410i Smart Array MIME-version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-type: text/plain; charset=us-ascii From: Christoph Hoffmann In-reply-to: <201303191220.34088.jhb@freebsd.org> Date: Wed, 20 Mar 2013 22:56:07 +0100 Content-transfer-encoding: quoted-printable Message-id: References: <51483621.2060503@FreeBSD.org> <201303191220.34088.jhb@freebsd.org> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1503) Cc: Bjorn Larsson , Sergey Dyatko , Andriy Gapon 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: Wed, 20 Mar 2013 22:56:30 -0000 Dear All, At present I do not have access to a HP box with a SmartArray=20 but zfsboot works perfectly with FreeBSD 9.1-RELEASE #0 r245668=20 (including EDD fix) on: hpiLO-> show system1 [...] Properties name=3DProLiant DL160 Gen8 [...] with the following firmware hpiLO-> show system1/firmware1=20 [...] /system1/firmware1 Targets Properties version=3DJ03 date=3D08/20/2012 [...] I know it is not much help, but hope it might give you=20 some input.=20 Thank you very much indeed for your work on this issue. Best Regards, Christoph -- Christoph Hoffmann e-mail: christoph_hoffmann@me.com On Mar 19, 2013, at 5:20 PM, John Baldwin wrote: > On Tuesday, March 19, 2013 5:55:45 am Andriy Gapon wrote: >> 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 =3D malloc(sizeof(struct dsk)); fix boot. Yesterday, avg@ = proposed >>> patch: >>> Index: /usr/src/sys/boot/i386/zfsboot/zfsboot.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- /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 =3D 0; >>> if (bios_extmem >=3D HEAP_MIN && high_heap_size < HEAP_MIN) { >>> high_heap_size =3D HEAP_MIN; >>> high_heap_base =3D bios_extmem + 0x100000 - HEAP_MIN; >>>=20 >>> it works for me, without printf() :) Can you test it ? >>=20 >> A comment about a nature of this patch. >>=20 >> Based on the previous investigation by Christoph Hoffmann and jhb: >> http://thread.gmane.org/gmane.os.freebsd.current/134199/focus=3D134309 >> 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. >>=20 >> Just in case, here is how the memory map looks on the Sergey's = system: >> SMAP type=3D01 base=3D0000000000000000 end=3D000000000009fc00 = len=3D000000000009fc00 >> SMAP type=3D02 base=3D000000000009fc00 end=3D00000000000a0000 = len=3D0000000000000400 >> SMAP type=3D02 base=3D00000000000e0000 end=3D0000000000100000 = len=3D0000000000020000 >> SMAP type=3D01 base=3D0000000000100000 end=3D00000000bc1a1000 = len=3D00000000bc0a1000 >> SMAP type=3D04 base=3D00000000bc1a1000 end=3D00000000bc1a4000 = len=3D0000000000003000 >> SMAP type=3D01 base=3D00000000bc1a4000 end=3D00000000bdf04000 = len=3D0000000001d60000 >> SMAP type=3D04 base=3D00000000bdf04000 end=3D00000000bdf3f000 = len=3D000000000003b000 >> SMAP type=3D01 base=3D00000000bdf3f000 end=3D00000000bdf6a000 = len=3D000000000002b000 >> SMAP type=3D02 base=3D00000000bdf6a000 end=3D00000000bdfbf000 = len=3D0000000000055000 >> SMAP type=3D01 base=3D00000000bdfbf000 end=3D00000000bdfeb000 = len=3D000000000002c000 >> SMAP type=3D03 base=3D00000000bdfeb000 end=3D00000000bdfff000 = len=3D0000000000014000 >> SMAP type=3D01 base=3D00000000bdfff000 end=3D00000000be000000 = len=3D0000000000001000 >> SMAP type=3D02 base=3D00000000be000000 end=3D00000000c0000000 = len=3D0000000002000000 >> SMAP type=3D02 base=3D00000000f8000000 end=3D00000000fc000000 = len=3D0000000004000000 >> SMAP type=3D02 base=3D00000000fec00000 end=3D00000000fec01000 = len=3D0000000000001000 >> SMAP type=3D02 base=3D00000000fed10000 end=3D00000000fed14000 = len=3D0000000000004000 >> SMAP type=3D02 base=3D00000000fed18000 end=3D00000000fed1a000 = len=3D0000000000002000 >> SMAP type=3D02 base=3D00000000fed1c000 end=3D00000000fed20000 = len=3D0000000000004000 >> SMAP type=3D02 base=3D00000000fee00000 end=3D00000000fee01000 = len=3D0000000000001000 >> SMAP type=3D02 base=3D00000000ffe00000 end=3D0000000100000000 = len=3D0000000000200000 >> SMAP type=3D01 base=3D0000000100000000 end=3D0000000140000000 = len=3D0000000040000000 >>=20 >> 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. >>=20 >> 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. >=20 > Yes, we likely could start using that, we would just need to ensure it = has some > sort of minimum size. However, maybe it would always have that = minimum size as you > are only going to have additional ranges if you have more than 4GB of = RAM anyway. > I think though that there were some odd BIOSes that would place a hole = at 15-16MB, > and for those the memory region at 1MB is too small. A minimum size = of 16MB might > handle that case correctly while using the first extended region in = the common > case. >=20 >> Additionally, in the case of zfsboot I think that we do not use = memory above 1MB >> for anything else besides the heap. >=20 > You load either /boot/zfsloader or the kernel there. >=20 > --=20 > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"