[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: amiboot - tlsfmem


I was able to complete an install of debian3.1 just a few hours ago,
it was a rather painful process, so i'll be looking into improving
that, hopefully.

2009/1/6 Chris Hodges <chrisly@platon42.de>:
> Huhu Geert,
> You wrote on 05.01.09:
>>> avail flush
>>> Type  Available    In-Use   Maximum   Largest
>>> chip    1678408    414680   2093088   1644460
>>> fast   29402264   3627880  33030144  27781372
>>> total  31080672   4042560  35123232  27781372
>>> amiboot
>>> Found 4 Blocks of Memory
>>> Block 0: 0x78154000 to 0x79e94000 (29952K)
>>> Block 1: 0x780d3000 to 0x78153000 (512K)
>>> Block 2: 0x79ee8000 to 0x79f68000 (512K)
>>> Block 3: 0x78000000 to 0x79f80000 (32256K)
>> Strange, blocks 0-2 overlap with block 3?
>>> 36K of CHIP memory
>> That's indeed not much...
> TLSFMem does not use a linear linked list of chunks, otherwise it  wouldn't
> be able to achieve its O(1) time complexity.
> On startup of TLSFMem, the old AmigaOS memory headers  with  the  remaining
> free  memory* are converted to a new format, with the mh_First field set to
> NULL, as there are no longer a compatible linked chunk  list  and  programs
> traversing the internal memory lists would probably do no good to them.
> * all free memory chunks that are larger than 512 KB are  converted,  hence
> if  big memory blocks already are fragmented, there will be multiple memory
> headers for each of these chunks. These memory headers are  sorted  by  the
> size of the chunks, so the biggest block will be accessed first.
> If a memory header cannot  be  converted  completely  (e.g.  because  there
> already  was memory allocated in the old format and this memory still needs
> to be freeable), an additional old version of  the  memory  header  remains
> with remaining free chunks or chunks that are freed later. This is what you
> probably see with the 36KB of chip  memory.  Also,  on  these  headers  the
> mh_Lower  and  mh_Upper  ranges  may  be  overlapping  with the TLSF memory
> headers, but only, if the TLSF headers  does  not  reach  the  end  of  the
> original memory range.
>>> The kernel will be located at 0x78154000
>>> Not enough Chip RAM in this system.  Aborting...
> If the Linux loader would be using the exec allocation  functions  and  not
> some private exec magic, the memory could be allocated normally.
>> From looking at the code, a possible cause of the apparent lack of Chip RAM is
>> that there are now multiple memory headers with the MEMF_CHIP flag set. In that
>> case, bi.chip_size will be set to the size of the last header.
> If this is the case, you're probably looking at the  legacy  memory  header
> which has a very low priority and is behind the new TLSF memory headers.
> --
> Regards, Chris Hodges )-> http://www.platon42.de <-(
> GCS/IT d@ s-: a32 C+++>$ U*+ P++ L- E W++ N+(++) !o K- w----- !O M- !V PS+
> PE Y+ PGP t++(-) 5+++ X++(-) R+ !tv b++ DI D-- G+ e+++*>++++ h-- r++>+++ y+
>  (Sexy, slow female voice:)  oooOOOO, Greg's in...  OOOOooo,
>  Greg's out...  ooooOOOOO, Greg's in...  OOOoooo, Greg's out...
>  ooooOOOOO, Greg's in...  Humph, Greg's busy, you had better call
>  back later...
>  -- Answering machine madness - family fun

Reply to: