[coyotos-dev] For your amusement

[Jeroen Visser]

I put the image of a bootable CD and tried a few floppy-less computers.

On a Toshiba Intel Core2 (T5500) laptop the kernel fails (as expected)
with an assertion on line 182 of 8259.c. But not before reporting
checksum errors on two APIC descriptors.

Coyotos boots on a HP Pavillion with an Athlon XP 2220+/512MB. No
twiddlers are seen twiddling on this machine. But it comes up to the
pig-Deutsch welcome page anyway.

Another, slightly older Athlon boots fine too.


On 9/28/07, Jonathan S. Shapiro <shap at eros-os.com> wrote:
>
> 1. Why 6M?  I don't know, and I would like to find out. I *suspect* it
> has to do with the way that we pre-allocate page tables, but I do not
> know. Can you tell me what diagnostic appears when you attempt to boot
> with less?

#qemu -m 5 -fda grubdisk
...
cache_preload ....
/mkimage.out: loaded  NPage=18 nCapPage=0 nGPT=6 nEndpoint=5 nProc=2
Have processed 488 pages. Now adding 19 more (tot 507), but estimate
only allowed for 505

(hand transcribed)

Other memory starved attempts report substantially similar messages.

> 2. Startup delay. I suspect the root cause of this is that we are
> initializing all of object space eagerly, and that we are using
> temporary mappings to do that. The temporary mappings need to be
> invalidated fairly often, and QEMU is very slow at that. We need to
> confirm whether this is true.
>
> One way to do that is to run under GDB and hit ^c a couple of times
> during that delay. Do a back-trace ("bt") and you will probably find
> that some procedure call is driving all of this. If someone can identify
> that procedure, it would be a big help.

Sorry, I need to set up a debug qemu before I can do that :(

JCV