Re: Debugging an early kernel problem (more MIPS trouble)

2016-07-05 Thread coypu
I've resorted to taking advantage of the fact I'm running an emulator and made it print a message to stderr every time it changes the interrupt level. Which, conveniently, didn't boot as well (although it got stuck a lot later). However, the problem was found: Seems like all the interrupt code is

Re: Debugging an early kernel problem (more MIPS trouble)

2016-07-05 Thread coypu
On Tue, Jul 05, 2016 at 03:52:21AM +, David Holland wrote: > On Tue, Jul 05, 2016 at 02:00:35AM +, co...@sdf.org wrote: > > After failing to fix enough broken things with the interrupt code by > > reading it, I wanted to try adding some code to let me know when the > > interrupt level

Re: Debugging an early kernel problem (more MIPS trouble)

2016-07-03 Thread coypu
I was under the impression I am seeing init being forked by the kernel (which I was told is lwp0), but that is not the case. This is also not the first fork1 call. So I am back to looking at machine-dependent code disabling interrupts and not enabling them back.

Debugging an early kernel problem (more MIPS trouble)

2016-07-03 Thread coypu
Hi, I've been trying to understand why with DIAGNOSTIC, a pmax kernel panics at init, with the following: init path (default /sbin/init): init: copying out path `/sbin/init' 11 pid 1(init): ABI set to O32 (e_flags=0x1007) panic: kernel diagnostic assertion "pcb2->pcb_context.val[_L_SR] &