Date: Wed, 20 Mar 2013 22:56:07 +0100 From: Christoph Hoffmann <christoph_hoffmann@me.com> To: freebsd-current@freebsd.org Cc: Bjorn Larsson <bjwela@gmail.com>, Sergey Dyatko <sergey.dyatko@gmail.com>, Andriy Gapon <avg@freebsd.org> Subject: Re: gptzfsboot problem on HP P410i Smart Array Message-ID: <D6D34BE1-EB64-4B93-87FE-03A929F50ABC@me.com> In-Reply-To: <201303191220.34088.jhb@freebsd.org> References: <CAAG5QCs0G1ztH715j5pnsFmne30xZwUT5o_YkQW9k1dDc-=-Nw@mail.gmail.com> <CAJ0WZYBQcujPbW%2BiZVkPMY=voGgHQnuVLLi=DKb%2BL-%2B1OW_Arw@mail.gmail.com> <51483621.2060503@FreeBSD.org> <201303191220.34088.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@freebsd.org> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D6D34BE1-EB64-4B93-87FE-03A929F50ABC>