Something is very fishy with the RM200 (E)ISA interrupt handler code.
Sympthom was that some time we loose (E)ISA interrupts which essentially is
almost equivalent to a crash since without timer interrupt there isn't very
much left to loose ... What I observed was that the 8259 PICs stop signaling
interrupts to the processor however if I poll them for interrupts they tell
me there'd be an interrupt. In some cases not all interrupts are dead an
another interrupt may resurrect the dead ones. For a user this bug was
visible as strange hangs from which the machine may recover by for example
hitting a key or telneting to the machine. This bug affects all RM200C
kernels since at least 2.1.73, probably even longer. No idea what's the
cause for this.
I've done a major overhaul of the keyboard stuff. Essentially my current
2.1.126 based kernel has the MIPS keyboard stuff redone completly. For
the first time without CONFIG_STUPID system and flexible enough to
add about any new port with non-standard keyboard controller interface like
the Algorithmics P4032 board. During that I found the probably oldest
Linux/MIPS bug, __delay has a wrong operand to multu resulting usually in
way to short delay loops which on some machines may result in funny
keyboard messages or even the keyboard not being detected. Another effect
is that now the PS/2 mouse of the RM200 works.
I've hacked the NCR 53C8xx driver back into usability. It works on my two
NCR based systems but I'd never call that thing reliable because I know how
horribly hacked my source is. Anyway since it seems to be usable I'll
I just found that I accidently never commited the uaccess.h file with my
module fixes to CVS, so modules built from the CVS source can in most cases
not be loaded due to relocation overflows.
Modutils have bug which prevents them from building on little endian machines.
I've fixed that one just like two other modutil bugs.