On Sat, 30 Jun 2001, Kjetil B. Thomassen wrote:

> > > 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.

It looks like I added hcide to GENERIC last Sunday, so if you're using
sources older than that, you won't have it.

> 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),

Did it panic, or just hang?

> 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.

It's not a fast box, and NetBSD isn't a fast OS (try booting RISC iX for a
scary comparison).  The ea driver probably isn't helping any, though.

> 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.

I get around 50 KB/s doing the same test.  I notice that GENERIC has
NFS_BOOT_RWSIZE=1024.  You might try removing that and seeing if things
get better.  I think the "bug" mentioned there was just a nasty
interaction between my Ether3 and my EtherExpress.

> 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.

I can't actually remember if I've made the driver any faster lately.  I've
certainly made it a lot more functional.  It certainly _could_ be made
faster.

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

Ah.  That indicates another reason why it'll be slow:

cpu0 (root): ARM3 (rev. 0), cache disabled

I can't remember under what circumstances that kernel will turn off the
cache, but a -current one should turn it on.

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

At the moment, it looks like your machine hasn't got anything I haven't
got here.  Oh, unless you've got a parallel printer.  I know that driver
doesn't work, but I haven't got a printer here to test it with.

Incidentally, I'm building a -current snapshot now.  It'll take a while.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>