Re: loader(8) readin failed on 7.2R and later including 8.0R
On Thursday 18 March 2010 7:10:59 am Carsten Bäcker wrote: > Hello, > > i ran into a similar problem when recently trying to install 8.0R on an > embedded system. We've been using this hardware for a couple of > years with FreeBSD 4.11 and didn't see any problem like this. > > Disabling the memory hole (15-16M) solved the problem here, but > that shouldn't be a solution. I wonder whether it's a loader-, or a > BIOS-problem, since memory-allocation should respect reserved > areas. The problem is likely because an 8.0 kernel is simply larger than a 4.11 kernel. 4.11's loader would have had the same issue. The problem (as it were), is that we expect to be able to load the kernel + modules into one contiguous chunk of RAM, starting at 4MB (PAE and amd64 kernels start at 2MB). > Best regards > Carsten Bäcker > > > On Sunday 06 December 2009 12:16:36 am Hiroki Sato wrote: > > Hiroki Sato wrote > >in<20091205.184250.201700943@allbsd.org>: > > > > hr> A summary so far is: > > hr> > > hr> 1) a<8MB 7.1R kernel + stock 8.0R loader > > hr> 2a) a>8MB 8.0R kernel + stock 8.0R loader > > hr> 2b) a>8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes > > hr> 2c) a>8MB 8.0R kernel + loader with your patch > > hr> 3a) a<8MB 8.0R kernel + stock 8.0R loader > > hr> 3b) a<8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes > > hr> 3c) a<8MB 8.0R kernel + loader with your patch > > > > Grr, I double-checked how it got stuck, then I found the console > > redirect was disabled because of an old device.hints. The revised > > summary is: > > > > loading text loading syms boot > >1) OKOK OK > >2a) "readin failed" - - > >2b) OK"skipped!" OK > >2c) OK"skipped!" OK > >3a) OKOK OK > >3b) OKOK OK > >3c) OKOK OK > > > > So, the case 2c shows that your patch solves the problem in the case > > 2a. Thank you! :) > > > > Loading>8MB kernel works now, but loading syms sections still fails > > even in the case 2c. > > Ok. Your system's SMAP is kind of weird (it has a very small region above > 1MB, so it may not deal well with "large" kernels, though I thought it had > enough room for at least a 12MB kernel. Hmm, the size of the kernel file may > be deceptive though since it does not include BSS. I wonder if it is trying > to load the symbols after the BSS. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: loader(8) readin failed on 7.2R and later including 8.0R
on 18/03/2010 13:10 Carsten Bäcker said the following: > Hello, > > i ran into a similar problem when recently trying to install 8.0R on an > embedded system. We've been using this hardware for a couple of > years with FreeBSD 4.11 and didn't see any problem like this. > > Disabling the memory hole (15-16M) solved the problem here, but > that shouldn't be a solution. I wonder whether it's a loader-, or a > BIOS-problem, since memory-allocation should respect reserved > areas. True. Please also keep in mind that BIOS should report reserved areas correctly too. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: loader(8) readin failed on 7.2R and later including 8.0R
Hello, i ran into a similar problem when recently trying to install 8.0R on an embedded system. We've been using this hardware for a couple of years with FreeBSD 4.11 and didn't see any problem like this. Disabling the memory hole (15-16M) solved the problem here, but that shouldn't be a solution. I wonder whether it's a loader-, or a BIOS-problem, since memory-allocation should respect reserved areas. Best regards Carsten Bäcker On Sunday 06 December 2009 12:16:36 am Hiroki Sato wrote: Hiroki Sato wrote in<20091205.184250.201700943@allbsd.org>: hr> A summary so far is: hr> hr> 1) a<8MB 7.1R kernel + stock 8.0R loader hr> 2a) a>8MB 8.0R kernel + stock 8.0R loader hr> 2b) a>8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes hr> 2c) a>8MB 8.0R kernel + loader with your patch hr> 3a) a<8MB 8.0R kernel + stock 8.0R loader hr> 3b) a<8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes hr> 3c) a<8MB 8.0R kernel + loader with your patch Grr, I double-checked how it got stuck, then I found the console redirect was disabled because of an old device.hints. The revised summary is: loading text loading syms boot 1) OKOK OK 2a) "readin failed" - - 2b) OK"skipped!" OK 2c) OK"skipped!" OK 3a) OKOK OK 3b) OKOK OK 3c) OKOK OK So, the case 2c shows that your patch solves the problem in the case 2a. Thank you! :) Loading>8MB kernel works now, but loading syms sections still fails even in the case 2c. Ok. Your system's SMAP is kind of weird (it has a very small region above 1MB, so it may not deal well with "large" kernels, though I thought it had enough room for at least a 12MB kernel. Hmm, the size of the kernel file may be deceptive though since it does not include BSS. I wonder if it is trying to load the symbols after the BSS. -- John Baldwin __ -- *** *demig Prozessautomatisierung GmbH * demig Anlagentechnik GmbH * * * * * Anschrift: Haardtstrasse 40 * Haardtstrasse 40 * * D-57076 Siegen * D-57076 Siegen * * Registergericht: Siegen HRB 2819 * Siegen HRB 5532* * Geschaeftsfuehrer: Joachim Herbst, * Joachim Herbst,* *Winfried Held * Winfried Held * * Telefon: +49 271 772020 * +49 271 772020 * * Telefax: +49 271 74704 * +49 271 74704 * * E-Mail:i...@demig.de * a...@demig.de* * http://www.demig.de * http://www.demig.de* *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: loader(8) readin failed on 7.2R and later including 8.0R
On Sunday 06 December 2009 12:16:36 am Hiroki Sato wrote: > Hiroki Sato wrote > in <20091205.184250.201700943@allbsd.org>: > > hr> A summary so far is: > hr> > hr> 1) a <8MB 7.1R kernel + stock 8.0R loader > hr> 2a) a >8MB 8.0R kernel + stock 8.0R loader > hr> 2b) a >8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes > hr> 2c) a >8MB 8.0R kernel + loader with your patch > hr> 3a) a <8MB 8.0R kernel + stock 8.0R loader > hr> 3b) a <8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes > hr> 3c) a <8MB 8.0R kernel + loader with your patch > > Grr, I double-checked how it got stuck, then I found the console > redirect was disabled because of an old device.hints. The revised > summary is: > >loading text loading syms boot > 1) OKOK OK > 2a) "readin failed" - - > 2b) OK"skipped!" OK > 2c) OK"skipped!" OK > 3a) OKOK OK > 3b) OKOK OK > 3c) OKOK OK > > So, the case 2c shows that your patch solves the problem in the case > 2a. Thank you! :) > > Loading >8MB kernel works now, but loading syms sections still fails > even in the case 2c. Ok. Your system's SMAP is kind of weird (it has a very small region above 1MB, so it may not deal well with "large" kernels, though I thought it had enough room for at least a 12MB kernel. Hmm, the size of the kernel file may be deceptive though since it does not include BSS. I wonder if it is trying to load the symbols after the BSS. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: loader(8) readin failed on 7.2R and later including 8.0R
Hiroki Sato wrote in <20091205.184250.201700943@allbsd.org>: hr> A summary so far is: hr> hr> 1) a <8MB 7.1R kernel + stock 8.0R loader hr> 2a) a >8MB 8.0R kernel + stock 8.0R loader hr> 2b) a >8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes hr> 2c) a >8MB 8.0R kernel + loader with your patch hr> 3a) a <8MB 8.0R kernel + stock 8.0R loader hr> 3b) a <8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes hr> 3c) a <8MB 8.0R kernel + loader with your patch Grr, I double-checked how it got stuck, then I found the console redirect was disabled because of an old device.hints. The revised summary is: loading text loading syms boot 1) OKOK OK 2a) "readin failed" - - 2b) OK"skipped!" OK 2c) OK"skipped!" OK 3a) OKOK OK 3b) OKOK OK 3c) OKOK OK So, the case 2c shows that your patch solves the problem in the case 2a. Thank you! :) Loading >8MB kernel works now, but loading syms sections still fails even in the case 2c. -- Hiroki pgpZeDjCvRVGH.pgp Description: PGP signature
Re: loader(8) readin failed on 7.2R and later including 8.0R
John Baldwin wrote in <200912041734.24016@freebsd.org>: jh> On Friday 04 December 2009 10:35:59 am John Baldwin wrote: jh> > So memtop_copyin would start off as 0xf0 but would end up as 0xc0, 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) OKOK OK 2a) "readin failed" - - 2b) OK"skipped!" NG 2c) OK"skipped!" NG 3a) not tried yet 3b) OKOK NG 3c) OKOK 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 pgprJrQm3NyM7.pgp Description: PGP signature
Re: loader(8) readin failed on 7.2R and later including 8.0R
On Friday 04 December 2009 10:35:59 am John Baldwin wrote:
> On Thursday 03 December 2009 4:20:08 pm Hiroki Sato wrote:
> > John Baldwin wrote
> > in <200912030803.29797@freebsd.org>:
> >
> > jh> On Thursday 03 December 2009 5:29:13 am Hiroki Sato wrote:
> > jh> > John Baldwin wrote
> > jh> > in <200912020948.05698@freebsd.org>:
> > jh> >
> > jh> > jh> On Tuesday 01 December 2009 12:13:39 pm Hiroki Sato wrote:
> > jh> > jh> > While the "load" command seemed to finish, the box got stuck
> > just
> > jh> > jh> > after entering "boot" command.
> > jh> > jh> >
> > jh> > jh> > Curious to say, I have got this symptom only on a specific box
> > in
> > jh> > jh> > more than ten different boxes I upgraded so far; it is based
> > on an
> > jh> > jh> > old motherboard Supermicro P4DPE[*].
> > jh> > jh> >
> > jh> > jh> > [*]
> > jh> http://www.supermicro.com/products/motherboard/Xeon/E7500/P4DPE.cfm
> > jh> > jh> >
> > jh> > jh> > Any workaround? Booting from release CDROMs (7.2R and 8.0R)
> > also
> > jh> > jh> > fail. On the box "7.1R" or "7.1R's loader + 7.2R kernel"
> > worked
> > jh> > jh> > fine. It is possible something in changes of loader(8)
> > between 7.1R
> > jh> > jh> > and 7.2R is the cause, but I am still not sure what it is...
> > jh> > jh>
> > jh> > jh> It may be related to the loader switching to using memory > 1MB
> > for its
> > jh> > jh> malloc(). Maybe try building the loader with
> > jh> 'LOADER_NO_GPT_SUPPORT=yes' in
> > jh> > jh> /etc/src.conf?
> > jh> >
> > jh> > Thanks, a recompiled loader with LOADER_NO_GPT_SUPPORT=yes' displayed
> > jh> > "elf32_loadimage: could not read symbols - skipped!" for 8.0R kernel.
> > jh> > This is the same as 7.1R's loader + 8.0R kernel case.
> > jh>
> > jh> Can you get the output of 'smap' from the loader? Is the 8.0 kernel
> > bigger
> > jh> than the 7.x kernel? If so, can you try trimming the 8.0 kernel a bit
> > to see
> > jh> if that changes things?
> >
> > Sure. Output of smap on an 8.0R loader with LOADER_NO_GPT_SUPPORT=yes
> > was:
> >
> > | OK smap
> > | SMAP type=01 base= len=0009f400
> > | SMAP type=02 base=0009f400 len=0c00
> > | SMAP type=02 base=000dc000 len=00024000
> > | SMAP type=01 base=0010 len=00e0
>
> So this is the region that ends up getting used for malloc:
>
> /* look for the first segment in 'extended' memory */
> if ((smap.type == SMAP_TYPE_MEMORY) && (smap.base == 0x10)) {
> bios_extmem = smap.length;
>
> ...
>
> /* Set memtop to actual top of memory */
> memtop = memtop_copyin = 0x10 + bios_extmem;
>
>
> and then later:
>
> #if defined(LOADER_BZIP2_SUPPORT) || defined(LOADER_FIREWIRE_SUPPORT) ||
> defined(LOADER_GPT_SUPPORT) || defined(LOADER_ZFS_SUPPORT)
> heap_top = PTOV(memtop_copyin);
> memtop_copyin -= 0x30;
> heap_bottom = PTOV(memtop_copyin);
> #else
>
> So memtop_copyin would start off as 0xf0 but would end up as 0xc0,
> and since the kernel starts at 4MB, I think that only leaves about 8MB for
> the kernel. Probably the loader needs to be more intelligent about using
> high memory for malloc by using the largest region > 1MB but < 4GB for
> malloc() instead of stealing memory from bios_extmem in the SMAP case.
> Try the attached patch which tries to make the loader use better smarts
> when picking a memory region for the heap (warning, I haven't tested it
> myself yet).
Use the updated patch (actually tested in qemu) instead.
--
John Baldwin
--- //depot/vendor/freebsd/src/sys/boot/i386/libi386/biosmem.c 2007/10/28 21:26:35
+++ //depot/user/jhb/boot/sys/boot/i386/libi386/biosmem.c 2009/12/04 22:20:17
@@ -35,14 +35,20 @@
#include "libi386.h"
#include "btxv86.h"
-vm_offset_t memtop, memtop_copyin;
-u_int32_t bios_basemem, bios_extmem;
+vm_offset_t memtop, memtop_copyin, high_heap_base;
+uint32_t bios_basemem, bios_extmem, high_heap_size;
static struct bios_smap smap;
+/*
+ * The minimum amount of memory to reserve in bios_extmem for the heap.
+ */
+#define HEAP_MIN (3 * 1024 * 1024)
+
void
bios_getmem(void)
{
+uint64_t size;
/* Parse system memory map */
v86.ebx = 0;
@@ -65,6 +71,26 @@
if ((smap.type == SMAP_TYPE_MEMORY) && (smap.base == 0x10)) {
bios_extmem = smap.length;
}
+
+ /*
+ * Look for the largest segment in 'extended' memory beyond
+ * 1MB but below 4GB.
+ */
+ if ((smap.type == SMAP_TYPE_MEMORY) && (smap.base > 0x10) &&
+ (smap.base < 0x1ull)) {
+ size = smap.length;
+
+ /*
+ * If this segment crosses the 4GB boundary, truncate it.
+ */
+ if (smap.base + size > 0x1ull)
+ size = 0x1ull - smap.base;
+
+ if (size > high_heap_size) {
+ high_heap_size = size;
+ high_heap_base = smap.base;
+ }
+ }
} while (v86.ebx != 0);
/* Fall back to the old compatibility function for base memory */
@@ -97,5
Re: loader(8) readin failed on 7.2R and later including 8.0R
On Thursday 03 December 2009 4:20:08 pm Hiroki Sato wrote:
> John Baldwin wrote
> in <200912030803.29797@freebsd.org>:
>
> jh> On Thursday 03 December 2009 5:29:13 am Hiroki Sato wrote:
> jh> > John Baldwin wrote
> jh> > in <200912020948.05698@freebsd.org>:
> jh> >
> jh> > jh> On Tuesday 01 December 2009 12:13:39 pm Hiroki Sato wrote:
> jh> > jh> > While the "load" command seemed to finish, the box got stuck just
> jh> > jh> > after entering "boot" command.
> jh> > jh> >
> jh> > jh> > Curious to say, I have got this symptom only on a specific box in
> jh> > jh> > more than ten different boxes I upgraded so far; it is based on
> an
> jh> > jh> > old motherboard Supermicro P4DPE[*].
> jh> > jh> >
> jh> > jh> > [*]
> jh> http://www.supermicro.com/products/motherboard/Xeon/E7500/P4DPE.cfm
> jh> > jh> >
> jh> > jh> > Any workaround? Booting from release CDROMs (7.2R and 8.0R) also
> jh> > jh> > fail. On the box "7.1R" or "7.1R's loader + 7.2R kernel" worked
> jh> > jh> > fine. It is possible something in changes of loader(8) between
> 7.1R
> jh> > jh> > and 7.2R is the cause, but I am still not sure what it is...
> jh> > jh>
> jh> > jh> It may be related to the loader switching to using memory > 1MB for
> its
> jh> > jh> malloc(). Maybe try building the loader with
> jh> 'LOADER_NO_GPT_SUPPORT=yes' in
> jh> > jh> /etc/src.conf?
> jh> >
> jh> > Thanks, a recompiled loader with LOADER_NO_GPT_SUPPORT=yes' displayed
> jh> > "elf32_loadimage: could not read symbols - skipped!" for 8.0R kernel.
> jh> > This is the same as 7.1R's loader + 8.0R kernel case.
> jh>
> jh> Can you get the output of 'smap' from the loader? Is the 8.0 kernel
> bigger
> jh> than the 7.x kernel? If so, can you try trimming the 8.0 kernel a bit to
> see
> jh> if that changes things?
>
> Sure. Output of smap on an 8.0R loader with LOADER_NO_GPT_SUPPORT=yes
> was:
>
> | OK smap
> | SMAP type=01 base= len=0009f400
> | SMAP type=02 base=0009f400 len=0c00
> | SMAP type=02 base=000dc000 len=00024000
> | SMAP type=01 base=0010 len=00e0
So this is the region that ends up getting used for malloc:
/* look for the first segment in 'extended' memory */
if ((smap.type == SMAP_TYPE_MEMORY) && (smap.base == 0x10)) {
bios_extmem = smap.length;
...
/* Set memtop to actual top of memory */
memtop = memtop_copyin = 0x10 + bios_extmem;
and then later:
#if defined(LOADER_BZIP2_SUPPORT) || defined(LOADER_FIREWIRE_SUPPORT) ||
defined(LOADER_GPT_SUPPORT) || defined(LOADER_ZFS_SUPPORT)
heap_top = PTOV(memtop_copyin);
memtop_copyin -= 0x30;
heap_bottom = PTOV(memtop_copyin);
#else
So memtop_copyin would start off as 0xf0 but would end up as 0xc0,
and since the kernel starts at 4MB, I think that only leaves about 8MB for
the kernel. Probably the loader needs to be more intelligent about using
high memory for malloc by using the largest region > 1MB but < 4GB for
malloc() instead of stealing memory from bios_extmem in the SMAP case.
Try the attached patch which tries to make the loader use better smarts
when picking a memory region for the heap (warning, I haven't tested it
myself yet).
> | SMAP type=02 base=00f0 len=0010
> | SMAP type=01 base=0100 len=beef
> | SMAP type=03 base=bfef len=c000
> | SMAP type=04 base=bfefc000 len=4000
> | SMAP type=01 base=bff0 len=0008
> | SMAP type=02 base=bff8 len=0008
> | SMAP type=02 base=fec0 len=0001
> | SMAP type=02 base=fee0 len=1000
> | SMAP type=02 base=ff80 len=0040
> | SMAP type=02 base=fff0 len=0010
> | OK
>
> Size difference between the two kernels was:
>
> | -r-xr-xr-x 1 root wheel 9708240 Dec 1 16:22 kernel.7/kernel
> | -r-xr-xr-x 1 root wheel 11492703 Nov 21 15:48 kernel.8/kernel
>
> Then I rebuilt a smaller 8.0 kernel by removing some entries from the
> kernel configuration file. The size is now smaller than 7.1R kernel:
>
> | -r-xr-xr-x 1 root wheel 7710491 Dec 3 21:10 /boot/kernel.8X/kernel
>
> Loading the new kernel seemed to work fine with the recompiled 8.0R
> loader, but it got stuck just after entering "boot":
>
> | OK load /boot/kernel.8X/kernel
> | /boot/kernel.8X/kernel text=0x5a7664 data=0x88d74+0x82f04
> syms=[0x4+0x6d290+0x4+0x987e3]
> | OK boot
> | /
I'm not sure why it would get stuck. Can you add some debug printfs to see
how far it gets before it dies? E.g. does it get to the point of calling
exec() (in which case the hang is in the kernel in locore.S rather than in
the loader).
--
John Baldwin
--- //depot/vendor/freebsd/src/sys/boot/i386/libi386/biosmem.c 2007/10/28 21:26:35
+++ //depot/user/jhb/boot/sys/boot/i386/libi386/biosmem.c 2
Re: loader(8) readin failed on 7.2R and later including 8.0R
John Baldwin wrote in <200912030803.29797@freebsd.org>: jh> On Thursday 03 December 2009 5:29:13 am Hiroki Sato wrote: jh> > John Baldwin wrote jh> > in <200912020948.05698@freebsd.org>: jh> > jh> > jh> On Tuesday 01 December 2009 12:13:39 pm Hiroki Sato wrote: jh> > jh> > While the "load" command seemed to finish, the box got stuck just jh> > jh> > after entering "boot" command. jh> > jh> > jh> > jh> > Curious to say, I have got this symptom only on a specific box in jh> > jh> > more than ten different boxes I upgraded so far; it is based on an jh> > jh> > old motherboard Supermicro P4DPE[*]. jh> > jh> > jh> > jh> > [*] jh> http://www.supermicro.com/products/motherboard/Xeon/E7500/P4DPE.cfm jh> > jh> > jh> > jh> > Any workaround? Booting from release CDROMs (7.2R and 8.0R) also jh> > jh> > fail. On the box "7.1R" or "7.1R's loader + 7.2R kernel" worked jh> > jh> > fine. It is possible something in changes of loader(8) between 7.1R jh> > jh> > and 7.2R is the cause, but I am still not sure what it is... jh> > jh> jh> > jh> It may be related to the loader switching to using memory > 1MB for its jh> > jh> malloc(). Maybe try building the loader with jh> 'LOADER_NO_GPT_SUPPORT=yes' in jh> > jh> /etc/src.conf? jh> > jh> > Thanks, a recompiled loader with LOADER_NO_GPT_SUPPORT=yes' displayed jh> > "elf32_loadimage: could not read symbols - skipped!" for 8.0R kernel. jh> > This is the same as 7.1R's loader + 8.0R kernel case. jh> jh> Can you get the output of 'smap' from the loader? Is the 8.0 kernel bigger jh> than the 7.x kernel? If so, can you try trimming the 8.0 kernel a bit to see jh> if that changes things? Sure. Output of smap on an 8.0R loader with LOADER_NO_GPT_SUPPORT=yes was: | OK smap | SMAP type=01 base= len=0009f400 | SMAP type=02 base=0009f400 len=0c00 | SMAP type=02 base=000dc000 len=00024000 | SMAP type=01 base=0010 len=00e0 | SMAP type=02 base=00f0 len=0010 | SMAP type=01 base=0100 len=beef | SMAP type=03 base=bfef len=c000 | SMAP type=04 base=bfefc000 len=4000 | SMAP type=01 base=bff0 len=0008 | SMAP type=02 base=bff8 len=0008 | SMAP type=02 base=fec0 len=0001 | SMAP type=02 base=fee0 len=1000 | SMAP type=02 base=ff80 len=0040 | SMAP type=02 base=fff0 len=0010 | OK Size difference between the two kernels was: | -r-xr-xr-x 1 root wheel 9708240 Dec 1 16:22 kernel.7/kernel | -r-xr-xr-x 1 root wheel 11492703 Nov 21 15:48 kernel.8/kernel Then I rebuilt a smaller 8.0 kernel by removing some entries from the kernel configuration file. The size is now smaller than 7.1R kernel: | -r-xr-xr-x 1 root wheel 7710491 Dec 3 21:10 /boot/kernel.8X/kernel Loading the new kernel seemed to work fine with the recompiled 8.0R loader, but it got stuck just after entering "boot": | OK load /boot/kernel.8X/kernel | /boot/kernel.8X/kernel text=0x5a7664 data=0x88d74+0x82f04 syms=[0x4+0x6d290+0x4+0x987e3] | OK boot | / Loading 7.1R kernel by using the recompiled 8.0R loader had no problem. -- Hiroki pgp4kNtLrPHOy.pgp Description: PGP signature
Re: loader(8) readin failed on 7.2R and later including 8.0R
On Thursday 03 December 2009 5:29:13 am Hiroki Sato wrote: > John Baldwin wrote > in <200912020948.05698@freebsd.org>: > > jh> On Tuesday 01 December 2009 12:13:39 pm Hiroki Sato wrote: > jh> > While the "load" command seemed to finish, the box got stuck just > jh> > after entering "boot" command. > jh> > > jh> > Curious to say, I have got this symptom only on a specific box in > jh> > more than ten different boxes I upgraded so far; it is based on an > jh> > old motherboard Supermicro P4DPE[*]. > jh> > > jh> > [*] http://www.supermicro.com/products/motherboard/Xeon/E7500/P4DPE.cfm > jh> > > jh> > Any workaround? Booting from release CDROMs (7.2R and 8.0R) also > jh> > fail. On the box "7.1R" or "7.1R's loader + 7.2R kernel" worked > jh> > fine. It is possible something in changes of loader(8) between 7.1R > jh> > and 7.2R is the cause, but I am still not sure what it is... > jh> > jh> It may be related to the loader switching to using memory > 1MB for its > jh> malloc(). Maybe try building the loader with 'LOADER_NO_GPT_SUPPORT=yes' in > jh> /etc/src.conf? > > Thanks, a recompiled loader with LOADER_NO_GPT_SUPPORT=yes' displayed > "elf32_loadimage: could not read symbols - skipped!" for 8.0R kernel. > This is the same as 7.1R's loader + 8.0R kernel case. Can you get the output of 'smap' from the loader? Is the 8.0 kernel bigger than the 7.x kernel? If so, can you try trimming the 8.0 kernel a bit to see if that changes things? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: loader(8) readin failed on 7.2R and later including 8.0R
John Baldwin wrote in <200912020948.05698@freebsd.org>: jh> On Tuesday 01 December 2009 12:13:39 pm Hiroki Sato wrote: jh> > While the "load" command seemed to finish, the box got stuck just jh> > after entering "boot" command. jh> > jh> > Curious to say, I have got this symptom only on a specific box in jh> > more than ten different boxes I upgraded so far; it is based on an jh> > old motherboard Supermicro P4DPE[*]. jh> > jh> > [*] http://www.supermicro.com/products/motherboard/Xeon/E7500/P4DPE.cfm jh> > jh> > Any workaround? Booting from release CDROMs (7.2R and 8.0R) also jh> > fail. On the box "7.1R" or "7.1R's loader + 7.2R kernel" worked jh> > fine. It is possible something in changes of loader(8) between 7.1R jh> > and 7.2R is the cause, but I am still not sure what it is... jh> jh> It may be related to the loader switching to using memory > 1MB for its jh> malloc(). Maybe try building the loader with 'LOADER_NO_GPT_SUPPORT=yes' in jh> /etc/src.conf? Thanks, a recompiled loader with LOADER_NO_GPT_SUPPORT=yes' displayed "elf32_loadimage: could not read symbols - skipped!" for 8.0R kernel. This is the same as 7.1R's loader + 8.0R kernel case. -- Hiroki pgppYSmidXp4L.pgp Description: PGP signature
Re: loader(8) readin failed on 7.2R and later including 8.0R
On Tuesday 01 December 2009 12:13:39 pm Hiroki Sato wrote: > Hi, > > This may be a rare case, but I post this with the hope for ideas from > people here. > > I have experienced a strange loader(8) error. After upgrading one of > my boxes from 7.1R to 7.2R, an error appeared on "boot" command of > loader(8) like this: > > | FreeBSD/i386 bootstrap loader, Revision 1.1 > | (h...@cmaster.allbsd.org, Mon Nov 30 04:01:24 JST 2009) > | Loading /boot/defaults/loader.conf > | /boot/kernel/kernel text=0x8b6c04 > | readin failed > | > | elf32_loadimage: read failed > | /boot/kernel/kernel text=0x8b6c04 > | readin failed > | > | elf32_loadimage: read failed > | Unable to load a kernel! > > (Actually the above error message was displayed when I upgraded it to > 8.0R. The message was the same when I tried 7.2R.) > > Replacing the /boot/loader with 7.1R's one, 7.2R's kernel worked > fine. > > Next, I tried to upgrade it to 8.0R. As I explained earlier, the > 8.0R's loader did not work either, so I replaced it with 7.1R again. > However, 7.1R loader(8) + 8.0R kernel displayed the following error > and did not work: > > | OK load /boot/kernel/kernel > | /boot/kernel/kernel text=0x8db9a4 data=0xdd134+0xa5e84 syms=[0x4+0x99390+0x4+0xd2201 > | elf32_loadimage: could not read symbols - skipped! > > While the "load" command seemed to finish, the box got stuck just > after entering "boot" command. > > Curious to say, I have got this symptom only on a specific box in > more than ten different boxes I upgraded so far; it is based on an > old motherboard Supermicro P4DPE[*]. > > [*] http://www.supermicro.com/products/motherboard/Xeon/E7500/P4DPE.cfm > > Any workaround? Booting from release CDROMs (7.2R and 8.0R) also > fail. On the box "7.1R" or "7.1R's loader + 7.2R kernel" worked > fine. It is possible something in changes of loader(8) between 7.1R > and 7.2R is the cause, but I am still not sure what it is... It may be related to the loader switching to using memory > 1MB for its malloc(). Maybe try building the loader with 'LOADER_NO_GPT_SUPPORT=yes' in /etc/src.conf? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
