Dear All, At present I do not have access to a HP box with a SmartArray but zfsboot works perfectly with FreeBSD 9.1-RELEASE #0 r245668 (including EDD fix) on: </>hpiLO-> show system1 [...] Properties name=ProLiant DL160 Gen8 [...] with the following firmware </>hpiLO-> show system1/firmware1 [...] /system1/firmware1 Targets Properties version=J03 date=08/20/2012 [...] I know it is not much help, but hope it might give you some input. Thank you very much indeed for your work on this issue. Best Regards, Christoph -- Christoph Hoffmann e-mail: christoph_hoffmann_at_me.com On Mar 19, 2013, at 5:20 PM, John Baldwin <jhb_at_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 = malloc(sizeof(struct dsk)); fix boot. Yesterday, avg_at_ 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) >>> _at__at_ -302,6 +302,7 _at__at_ >>> * 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. > > 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. > >> Additionally, in the case of zfsboot I think that we do not use memory above 1MB >> for anything else besides the heap. > > You load either /boot/zfsloader or the kernel there. > > -- > John Baldwin > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Wed Mar 20 2013 - 21:56:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:35 UTC