Subject: Re: release
To: Chuck Silvers <chs+@cs.cmu.edu>
From: Adam Glass <glass@sun-lamp.cs.berkeley.edu>
List: port-sun3
Date: 02/07/1994 19:26:27
> 
> I had the magnum snapshot up to the "children of init die" point
> (using a ramdisk that I hacked up really fast from some other code),
> but I haven't been able to get back to that point with the -current
> code.  I switched to using the nfsdiskless stuff now that I have
> ethernet between the machines I'm using.
> 

cool.

> Here's what it does for me now:
> 
> ...
> idprom0 at obctl0 addr 0x0 size 0x20
> prom0 at mainbus0
> le: initializing unit 0, reg fff4000, ram fd00000
> le: resetting unit 0, reg fff4000, ram fd00000
> [le0: stat 2f2<TINT,INTR,INEA,RXON,TXON,STRT>][le0: stat 2f2<TINT,INTR,INEA,RXON,TXON,STRT>][le0: stat 4f2<RINT,INTR,INEA,RXON,TXON,STRT>][le0: stat 2f2<TINT,INTR,INEA,RXON,TXON,STRT>][le0: stat 4f2<RINT,INTR,INEA,RXON,TXON,STRT>][le0: stat 2f2<TINT,INTR,INEA,RXON,TXON,STRT>]context_allocate: for pmap e076edc
> context_allocate: pmap e076edc associated with context e08983c num 0
> [le0: stat 2f2<TINT,INTR,INEA,RXON,TXON,STRT>][le0: stat 4f2<RINT,INTR,INEA,RXON,TXON,STRT>][le0: stat 2f2<TINT,INTR,INEA,RXON,TXON,STRT>][le0: stat 4f2<RINT,INTR,INEA,RXON,TXON,STRT>][le0: stat 2f2<TINT,INTR,INEA,RXON,TXON,STRT>][le0: stat 4f2<RINT,INTR,INEA,RXON,TXON,STRT>]panic: rminit
> booting....
> sun3_stop: kernel ended deliberately
> sun3_stop: clock(0,0)
> 
> Exception 74 at 0FEF567E
> >
> 
> This is happening because nswapmap isn't ever getting set.
> It is only set in allocsys in sun3/machdep.c, but it doesn't look
> like that's called anywhere.  That's as far as I got over the weekend.
> 
> -Chuck

Hmm...this doesn't follow.  allocsys() is called by cpu_startup(),
twice actually.  (read the comments in like the hp300 port to see what
the rational here is).

I haven't seen this bug here at all, make sure that the panic in
rminit() is because of the mapsize (i.e nswapmap), and not something
else.  Also, what is your hardware configuration?

If nswapmap is actually being set by allocsys(), and getting cleared
later than we will need to do a binary search to see whats trashing
it.

See how far you can get with this one on your end, I'll work on mine.
Make sure you do a full compile, as I've never seen this bug before...

later,
Adam Glass


------------------------------------------------------------------------------