Basically the msg ring interrupt was being re-enabled
inside a spinlock as the thread set it self up for rescheduling.
This won't work since inside the re-enable is another
spin lock.. which means on return from the reenable
the interrupts have been reenabled. Thus you would
get a clock int and end up panicing holding a spin
lock to long :-o
Copy sys/dev/rmi to sys/mips/rmi/dev [sic]. For devices that are on
only one SoC, or family of SoC, we place them under sys/<vendor>/dev.
I'll fix the build problems this causes as best I can since rmi kernel
require external toolchains due to lack of support for rmi op-codes in
the ancient binutils we have in the tree.
original codes (I had changed one by accident)
Also do the pic_ack/pic_delayed_ack after the interrupt
so we clear it. The clock with these changes starts working.
Its off doing a short/long short/long warning but it
now runs.
My NFS mount now works but has the same problem with
sbin/init (errno 8 ENOEXEC) so it panics with no init.
Either this is a problem with my buildworld.. OR its a
yet undiscovered RMI issue.
the mi_startup (or to the last of it).. and
hit a panic after :
uart0: <16550 or compatible> on iodi0
Trap cause = 2 (TLB miss....)
I did have to take the pci bus OUT of the
build to get this far, hit a cache error with
the PCI code in. Interesting thing is the machine
reboots too ;-)
compile and many of them may disappear. For example
the xlr_boot1_console.c is old code that is ifdef'd out.
I will clean these sorts of things up as I make progress
on the port. So far the only thing I have I think straightened
out is the bits around the interupt handling... and hey that
may be broke ;-)
