Leo Weppelman wrote:
> It looks like the same problem Benny had a while back. Making sure the
> kernel runs in ST-ram fixed the problem. The 1.3 kernels will no longer
> relocate by default, meaning that you have to force them out of ST-ram
> instead of TT-ram. I don't remember if this was already the case in the
> 1.3 alpha kernels. If you try to let the kernel _only_ use ST ram, it
> probably will lockup because it has not enough memory to do the fsck's.
>
Thanks.  Yes.  However, I'm slightly confused now!  I compiled a kernel
and when I ran loadbsd.ttp, it couldn't load it because the kernel was
larger than the free ST-RAM.  I configured loadbsd.ttp to allocate memory
from TT-RAM.  I assume that this makes it load the kernel into TT-RAM.
Does that mean that when I had the MMU fault panics with the bootx kernel,
it was running in ST-RAM?  (I had a look through the kernel initialisation
code, and I see that it doesn't relocate itself).  Can I tell if the kernel
I'm running is in ST-RAM or TT-RAM?

> Maybe you should configure swap earlier?
>
Yes (again).  I didn't realise that the machine was running out of memory,
although I gather (from current-users) that this isn't handled gracefully!

I haven't had a MMU fault since I compiled a kernel, but I haven't done a
large amount of compiling in one go yet.  I've been trying to get a driver
for the Crazy Dots card to work :

I took the grfabs_et.c driver and tried to get a grfet attached to the  
card.  I couldn't get that to work.  Then, I looked at the leo.c and
if_le_vme.c files and now have a device that is probed and attached at
boot time :

        et0 at vme0 port 0xfebf000-0xfebfffff iomem 0xfec00000-0xfecfffff

I thought I should use the et4000 routines in the existing files, instead of
(more or less) duplicating them.  For the moment, I put values into the
et_priv struct (apart from pci_tag (which doesn't seem to be used anywhere))
and just copied the routines from grfabs_et.c

Presumably to use the card, I need to attach a grfet to it?  I'm not quite
sure how to do that.  Also presumably, I should look at the XFree86 SVGA
server for X?  I've seen some references to XFree86 - I take it that it is
the same source?  Will there be an X distribution for 1.3, or should I just
grab Xdaniver (aka 1.2)?

Unrelated things -

I can't run gdb because of :

	/usr/libexec/ld.so:gdb: libbfd.so.0.0: No such file or directory

I notice a libbfd directory in the gnu src, but I can't find it installed
anywhere.

I notice that date doesn't change the clock.  Is there any way to set it
from NetBSD?  My battery is dead and I noticed when I rebooted that the
date had gone back to 1989!  BTW, the system freezes for about 40 secs
when you change the time 8.5 years!

> PS: I expect the atari 1.3 release to be in place early next week. This
> for those of you wondering...

Great news!  Working bootblocks will make the edit, compile, reboot cycle
a bit faster (well the reboot bit anyway)! ;-)

Thanks again,

J

PS.  Entropy - I was looking through your code, and I don't understand
why leoread() and leowrite() both call leomove() with the same parameters.
Also, I think the sc_dev in the *_softc struct is automatically filled in.
Other drivers (e.g. sun) appear to use sc_dev.dv_xname, without explicity
assigning anything to it.

--
    1024/55A5BC19        0F 3F 62 56 18 10 8B 84  43 8F F4 94 93 37 76 AA

S.E.P.