Interesting. 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 <[email protected]>: > 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 > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
