[openbeos] Re: Boot failure with Quad-core
- From: "Larry Baydak" <lbaydak@xxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 07 Jan 2007 14:08:26 -0500 EST
Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
>
> Oh, it *reboots*. That's new information. Till now I was believing
> we're
> looking for an endless loop or something like this. Well,
> sort_addr_range()
> does memcpy()s and, I believe, the array boundaries are never
> checked.
>
> The arrays are defined in headers/private/kernel/boot/kernel_args.h,
> their
> sizes in
> headers/private/kernel/boot/platform/bios_ia32/platform_kernel_args.h
> (the
> MAX_*_RANGE definitions). Currently they are set to 4. So, if the
> boundaries of one of the first 2 arrays are overwritten (i.e. there
> are
> more ranges for any reason), the range count of the following array
> will be
> invalid and the sort_addr_range() for that array will happily explore
> a
> good deal of memory (earlier or later unmapped addresses too). Which
> would
> be an excellent reason for reboot. :-)
Right. TEE
>
> Unfortunately the debug output of get_memory_map() is completely
> missing in
> your log (don't know why). I don't know what exactly those extended
> memory
> infos are -- apparently a description of the physical memory layout -
> - and
> what properties they have, but they seem to directly affect the size
> of the
> physical_allocated_range array. I'm sure the more knowledgable in
> this area
> (Axel and Marcus supposedly) can give more insights.
>
> In doubt I'd print the array sizes before any sort_addr_range()
> invocation.
> If indeed the second array is too small in your case, just try to
> increase
> its size.
>
> > But perhaps it
> > has something to do with the amount of memory this machine can
> > support.
> >
> > The Motherboard can hold 4 DDR2 DIMMs. Up to a total of 8Gb of RAM.
> > But
> > I only have a single 1 Gb DIMM installed.
> >
> > Ideally - for best speed - one should use 2 DIMMS for balanced
> > memory
> > accesses. Wild speculation here -
> > perhaps the MMU is setting up banks of shadow memory - to simulate
> > two
> > DIMMS.
> >
> > Or perhaps the sort code is not handling the 8Gb memory ranges
> > reported
> > by the MMU. Which will exceed 32 bits.
> > (Forgive me if this last sounds like criticism. I have not actually
> > studied the code yet. And am just speculating.)
>
> I wouldn't think this has anything to do with the size of supported
> or
> installed RAM. If the mainboard chipset (or whatever is responsible)
> presents the installed memory as more than 4 disjoint physical
> address
> ranges, that would be an explanation, though.
>
> CU, Ingo
>
Other related posts:
