Port-pmax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

re: Is pmax alive?



Felix Deichmann writes:
> Am 06.03.2016 um 21:31 schrieb Tobias Nygren:
> > Agreed. And it's happening. I got -current going on gxemul!
> > There are some mips1 vs mips3 bugs in trap handling and some debug
> > code that assumes mips3. Moving on to physical hardware ...
> 
> Saw that you commited a patch for /src/sys/arch/mips/mips/trap.c, but is 
> there anything else needed to get pmax to boot?
> 
> I'm the proud owner of a Personal DECstation 5000/33 now, but booting a 
> current kernel I get the same panic as was already described here:
> http://mail-index.netbsd.org/port-pmax/2014/03/03/msg000158.html

hmmm, the latest kernels boot for me in gxemul.  at least, if i use
"3max" or "pmax" machines -- most of the other DECstation machines
in gxemul crash gxemul itself.

can you diagnose the addresses in the trap message?  eg, the above
post has these lines:

> pid 0(system): trap: cpu0, address error (load or I-fetch) in kernel mode
> status=0x80010, cause=0x30000010, epc=0x8000001c, vaddr=0xdeadbeef
> tf=0x8056cce8 ksp=0x8056cd88 ra=0x800b0120 ppl=0

can you open the kernel in gdb and try to find out where 0x8000001c
is in the kernel object?  also 0x800b0120.

also, the vaddr=0xdeadbeef can only come from a handful of places
in the pmax kernel.  none of them are in MD code, these are the
only ones i can see it could be:

sys/uvm/uvm_page.c:     pg->uobject = (void *)0xdeadbeef;
sys/uvm/uvm_page.c:     pg->uanon = (void *)0xdeadbeef;
sys/uvm/uvm_pglist.c:           pg->uobject = (void *)0xdeadbeef;
sys/uvm/uvm_pglist.c:           pg->uanon = (void *)0xdeadbeef;

could you try adjusting each of these to see if they are it?

thanks.


.mrg.


Home | Main Index | Thread Index | Old Index