> Sunny Daniels wrote:
> > I wonder whether, in this configuration, the LCII has "holes" in its
> > physical address space and has to use the PMMU to produce a contiguous
> > virtual address space, even when virtual memory is turned off in the
> > "Memory" control panel!  Does anyone know whether this might be the cause
> > of the problems with running MacBSD in multi-user mode?
> [...]
> Geoffrey Alexander answered:
> Leaving something out of the kernel did fix the problem, though after
> writing him it seems he's focus on other bugs, rather than finding the
> specific cause of this one -- so we still don't know the cause,
> and I still need ppp :)...

Hm... Last week my school switched from SLIP to PPP so we should have
now similar interests...

> It's interesting that he can get ADBTEST.132 to run in 4Megs RAM, yet I
> get bitten with the same '10'Meg configuration you discuss (two megs one
> one of the chips is hidden from the system) -- though bootstrap messages
> don't indicate problems with that scenario. But, yes, I think you're onto
> something.

Early I thought one of the kernel options whould cause th problem. But
last weekend I tried to compile a kernel with even fewer options
switched on (to find out WHICH option causes the problems) and this very
small kernel does not work at all!

Currently I have some indicators for the poor behaviour. The first one
is simply that pmap_bootstrap indicates a lot of non-existing non-system
RAM. If I remember right it indicates two extra areas of 400Megs - much
more someone could plug into the slots.

The second one is the scrolling problem. Depending on the size of system
RAM (?) and the kernel size (?) some of the upper lines in the console
don't scroll. This appears not at system startup and in 4 kilobyte
(approx. half a line) chunks. Heavy system usage (e.g. compilation)
sometimes increases the area.

The third one is the experience with the very small kernel. Somewhere in
machdep.c the variable VBLQueue is set to zero. This erases all memory
in this area to zero! Realy strange. Very early in kernel startup all
the area of low-memory-globals is set to the same value. MacOS stored
other values there.

> If I had disk space, I'd be configuring and testing kernels myself -- but
> I'm afraid I have to depend upon the proverbial kindness of strangers...
> :)

Some tries to make the modem dialing failed. Had you more success?

> I no longer have a copy of ADBTEST.132, but if it would help I'll get
> another and post my boot messages....

How much system / non-system RAM indicates the kernel on your machine ?

> Geoffrey Alexander geoffrey@netins.net

Here is some code to reproduce the strange behaviour of the very small
kernel:

ROMBase is in 0x260, VBLQueue in 0x160;

...
ROMBase = 0x40a00000;
...
dumpmem (0x260, 0x60);
VBLQueue = 0;
dumpmem (0x260, 0x60);
...

This code produces following output (The wrong place of the ROMBase
value is no typo):

00000260: 1508 1508 1508 1508 1508 1508 1508 1508
00000280: 1508 1508 1508 1508 1508 1508 1508 1508
000002a0: 1508 1508 1508 40a0 0000 1508 1508 1508

00000260: 0000 0000 0000 0000 0000 0000 0000 0000
00000280: 0000 0000 0000 0000 0000 0000 0000 0000
000002a0: 0000 0000 0000 0000 0000 0000 0000 0000

As you see ROMBase is now zero, only because a location 256 bytes away
is cleared. This causes the kernel to panic.

Now I hope for a inspiration of a reader of these lines and a lot of
patience to compile lots of test kernels.


Markus

-----------------------------------------------------------------------
Markus Hitter             Voice: ++49/651/828172
                          Email: hitterm@trier.fh-rpl.de
Trier (Germany)           WWW: http://www.trier.fh-rpl.de/~hitterm