Subject: Re: Panic: MMU fault :(
To: Leo Weppelman <email@example.com>
From: Julian Coleman <J.D.Coleman@newcastle.ac.uk>
Date: 01/05/1998 00:06:58
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
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)! ;-)
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