In message <Pine.SOL.4.33.0106301532000.9280-100000@libra.cus.cam.ac.uk>
          Ben Harris <bjh21@netbsd.org> wrote:

> On Sat, 30 Jun 2001, Kjetil B. Thomassen wrote:
> 
> > Getting my R140 up and booting over the network again, I have run into
> > the following problem with BBBB 0.44 (looks like this is the latest
> > when trying to do a cvs update -dP):
> > Error: Page 19 not free at line 3210 (Error number &1)
> >
> > Before that error I have:
> > Machine has 256 pages of 32K each. Total RAM: 8Mb
> > Lowering HIMEM: &598000 -> &18000
> > [snip]
> >
> > So, maybe someone wants to take a look at this?
> 
> What does the memory map (printed between the header and the error
> message) look like?  That message means that one of the physical pages
> that BBBB wanted to load the kernel into is in use for something else.
> You probably want to ensure that RMASize, FontSize, SpriteSize and
> RAMFSSize are all set to small (or zero) values.

Which is exactly where the problem was, and I realized that this could
be the problem before I read this email. So I reset all those values to
zero, except the fontmax, which I left at 1020 KB.

> > I am attaching a copy of the output that was generated by the PodID2,ffb
> > program that I found at
> > ftp://ftp.netbsd.org/pub/NetBSD/arch/arm26/riscos/
> 
> Right, both those podules should be supported (by hcide(4) and ea(4)
> respectively).

Which means that I need a kernel that has them. At present, the hcide is
not in the GENERIC kernel config file, so the kernels I have don't have
them.

I am now fully up and running, and even without swap I was able to log
in, although I haven't been playing around much. I have done some
experimentation though after I got the swap added.

Ian Fry made a kernel that is trying to save space so that he can boot
on his 4 MB computer, but that did not get any further than starting
cron (or was it updating motd), so I had to resort to using the October
snapshot kernels. His kernel config files are available as:
http://home.eunet.no/~kjetilbt/R140_IanFry.txt
http://home.eunet.no/~kjetilbt/A5000_IanFry.txt

The October snapshot GENERIC kernel got some part of the way, and then
paniced. I didn't investigate the matter further as I have heard that
that is no good for 8 MB computers anyway.

The FOURMEG kernel OTOH, does work fine, and the rest of my comments are
based on that kernel.

The R140 does not feel like a fast box, but that may be due to the fact
that I am mounting root and everything over NFS on an ea0. I don't know
whether it is the box itself or the ea0, but it has to be one of them.

My Ethernet hub tells me that the network utilization is less than 15 %
all the time, and that is also confirmed by a:
time cp /netbsd .

That gave me a speed of around 30 KBytes/s.

So, it looks like the ea0 driver was not very good at this time.
According to the information on the arm26 ports page, this is much
improved now IIRC.

The console code is very slow, so I tried telneting into the box, and
then the R140 paniced.

But, before I tried that I used ftp to put the dmesg up at:
http://home.eunet.no/~kjetilbt/dmesg_r140.txt

And, once I was in the ftp client, everything seemed a lot faster, so
the ea driver was no good at that point in time.

I have not tried my FPA10 in that box as I prefer to have a faster ARM3.
As the FPA10 is not supported, and I have to downclock my ARM3 to 25 MHz
to use it, I prefer it that way.

If you want me to try the FPA10, please let me know and I will do that.

Well, anyway, I have proven that I can get the system up to multiuser
with a well-made kernel, so now I can really start working on the port.

If you want me to test anything, then please provide me with the stuff,
and I will test.

TIA!

Kjetil B.
mailto:kjetil@thomassen.priv.no
http://www.thomassen.priv.no/