loader(8) readin failed on 7.2R and later including 8.0R

Hiroki Sato hrs at FreeBSD.org
Sat Dec 5 09:43:28 UTC 2009


John Baldwin <jhb at freebsd.org> wrote
  in <200912041734.24016.jhb at freebsd.org>:

jh> On Friday 04 December 2009 10:35:59 am John Baldwin wrote:
jh> > So memtop_copyin would start off as 0xf00000 but would end up as 0xc00000,
jh> > and since the kernel starts at 4MB, I think that only leaves about 8MB for
jh> > the kernel.  Probably the loader needs to be more intelligent about using
jh> > high memory for malloc by using the largest region > 1MB but < 4GB for
jh> > malloc() instead of stealing memory from bios_extmem in the SMAP case.
jh> > Try the attached patch which tries to make the loader use better smarts
jh> > when picking a memory region for the heap (warning, I haven't tested it
jh> > myself yet).
jh>
jh> Use the updated patch (actually tested in qemu) instead.

 Thanks!  I applied your patch and tried loading an 8.0R kernel
 (without LOADER_NO_GPT_SUPPORT=yes).  The "elf32_loadimage: read
 failed" error message disappeared:

 OK load /boot/kernel.N/kernel
 /boot/kernel.N/kernel text=0x8db9a4 data=0xdd134+0xa5e84 syms=[0x4+0x99390+0x4+0xd2201
 elf32_loadimage: could not read symbols - skipped!
 OK

 A summary so far is:

 1)  a <8MB 7.1R kernel + stock 8.0R loader
 2a) a >8MB 8.0R kernel + stock 8.0R loader
 2b) a >8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes
 2c) a >8MB 8.0R kernel + loader with your patch
 3a) a <8MB 8.0R kernel + stock 8.0R loader
 3b) a <8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes
 3c) a <8MB 8.0R kernel + loader with your patch

      loading text      loading syms       boot
 1)   OK                OK                 OK
 2a)  "readin failed"   -                  -
 2b)  OK                "skipped!"         NG
 2c)  OK                "skipped!"         NG
 3a)  not tried yet
 3b)  OK                OK                 NG
 3c)  OK                OK                 NG

 Loading syms sections still fails for the large kernel.  The
 "boot=NG" means it got stuck after l_exec() in boot.c and before
 cninit() in i386/machdep.c as far as I can check by inserting
 printf().  So the cause of that is something in the kernel,
 I guess.  Hm.

 One thing something special of that box is that it has four quad-hme
 PCI cards.  I will try removing them and see if it changes something
 or not.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091205/21cb4a8a/attachment.pgp


More information about the freebsd-stable mailing list