On 25-Apr-2003 Ruslan Ermilov wrote: > On Fri, Apr 25, 2003 at 04:17:05PM -0400, John Baldwin wrote: >> >> On 25-Apr-2003 Ruslan Ermilov wrote: >> > On Fri, Apr 25, 2003 at 03:22:58PM -0400, John Baldwin wrote: >> >> >> >> On 25-Apr-2003 Ruslan Ermilov wrote: >> >> > On Fri, Apr 25, 2003 at 12:07:35PM -0400, John Baldwin wrote: >> >> >> >> >> >> On 25-Apr-2003 Ruslan Ermilov wrote: >> >> >> > On Thu, Apr 24, 2003 at 05:45:15PM -0400, John Baldwin wrote: >> >> >> >> >> >> >> >> On 24-Apr-2003 Ruslan Ermilov wrote: >> >> >> >> > On Thu, Apr 24, 2003 at 02:21:17PM -0400, John Baldwin wrote: >> >> >> >> >> >> >> >> >> >> On 24-Apr-2003 Ruslan Ermilov wrote: >> >> >> >> >> > On 5.x, loader(8) compiled with -DNOFORTH, results in >> >> >> >> >> > a system without a console. This does not affect the >> >> >> >> >> > RELENG_4. >> >> >> >> >> > >> >> >> >> >> > Can someone who knows this code please look into it? >> >> >> >> >> >> >> >> >> >> No kernel console or no loader console? The usual problem with >> >> >> >> >> no kernel console on 5.x is lack of device.hints. >> >> >> >> >> >> >> >> >> > No kernel console. The device.hints, it's there under /boot; >> >> >> >> > I only reinstalled loader(8) with -DNOFORTH, and this gave me >> >> >> >> > "no console" behavior. Can you try it locally? >> >> >> >> >> >> >> >> Since device.hints is read in by Forth code, I wouldn't be >> >> >> >> surprised if it didn't work. When you break into the 10 >> >> >> >> second countdown, do you have any hints set in the loader >> >> >> >> environment? >> >> >> >> >> >> >> > Yes, figured this out by myself already. I've ended up >> >> >> > uncommenting the "hints" line in GENERIC config, everything >> >> >> > is OK now, and bzip2(1) also works, modulo the memory >> >> >> > restrictions -- only level 1 bzipping works that requires >> >> >> > ~250K of memory. >> >> >> > >> >> >> > John, is there a way to fix btx/loader/whatever so that >> >> >> > heap memory is not limited to 640K? >> >> >> >> >> >> Not really. At least, not easily. We load the kernel up above 1mb, >> >> >> but we don't know how much memory lives up above 1mb and we assume >> >> >> that there is enough for the kernel and that's it. >> >> >> >> >> > I was referring to this message from loader(8): >> >> > >> >> > BIOS 639kB/129856kB available memory >> >> > >> >> > So I thought that the memory allocation in i386/loader is >> >> > limited to real mode's 640KB, no? >> >> > >> >> > Also, IIRC, the installation requirement was 8MB or so, >> >> > and the runtime requirement was 4MB (these are 4.x numbers >> >> > from my memory), so we can safely assume that we have at >> >> > least 4MB of memory? Now that I look at it, I see that >> >> > GENERIC kernel in 5.0 is 4.82MB, and so we can probably >> >> > always assume that we have 8MB of memory. >> >> >> >> We assume that we have enough memory to stick the kernel >> >> up there, but that's the only assumption we make. :) >> >> >> > You still does not answer my question: is the memory >> > allocation in loader(8) limited to real mode 640KB? >> >> Yes. Basically, the loader is loaded at address 0xa000 and >> it's stack grows down from 0x9ffff (0xa0000 is where video >> memory is mapped), so that gives you >> 0xa0000 - 0xa000 = 0x96000 = 614400 = 600k for all of the >> loader text, data, bss, stack, and heap. >> >> I don't think the loader catches it if the stack and heap >> grow into each other. You just start corrupting things. :) >> > But if we manage to load kernel high, above 1M, there > should be something that allows us to relocate heap > there, no? Also, can't we just trust what BIOS thinks > about the amount of memory? We load the kernel into lower memory first and then copy it up above 1mb. The memory above 1mb is not managed by the heap and is only used as the destination of the kernel. We could trust what the BIOS says, but putting the heap up above 1mb has some sticky issues. First off, where do we put it? We can't put it at 1m cause the kernel has to go there. If we stick it at 4m, then we've limited the kernel to only being 3m in size, adn GENERIC is already larger than that. Any kernel modules get loaded up above 1m as well, along with splash screens, etc. Do you want to set a max size for all that and stick the extra heap above there? You would need at least an extra meg of space for it to buy you anything, so let's say you limit the kernel + modules + module data size to 6mb, then you can start the extra heap at 7mb and still work on an 8bm machine. The loader would no longer _function_ on a 4mb machine. I really would like to have the loader function on a fairly broad range of machines. I guess the real reason for your questions is that bzip2 requires some outrageous amount of memory for some internal tables? Does bzip2 really buy us that much more space than gzip in this case? -- John Baldwin <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/Received on Fri Apr 25 2003 - 11:49:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:05 UTC