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