Re: realtime-preempt for MIPS - compile problem with rwsem

[john cooper <john.cooper@member.fsf.org>]

Steven Rostedt wrote:
> On Wed, 21 Jun 2006, Ryan McAvoy wrote:

>> I did just that when I first started with these patches and did
>> succeed in getting it compiling and booting.  The resulting kernel,
>> however, is very unstable and hangs frequently with no output.  (It
>> will hang within hours if left idle.  I can hang it more quickly by
>> attempting to use it).

I also had stability issues with 2.6.14+RT+MIPS.
The only point I found it to be stable was under 2.6.13
where it successfully passed a standard battery of QA
tests.  To my knowledge no one has updated MIPS RT
since that time so I'd assume it is either in the
same state as then (best case) or worse (likely) due to
languishing.

Note the MIPS patch under discussion also required a
patch from linux-mips to produce a functional kernel
on the malta 4Kc which was the only MIPS target known
to be supported by that combination.

>> I have deadlock detection turned on and have
>> confirmed that it does produce output at least for some deadlocks:
>> http://groups.google.com/group/linux.kernel/browse_frm/thread/1559667001b7da2d/2558b539a5adc660?lnk=st&q=realtime+preempt+mips&rnum=2&hl=en#2558b539a5adc660
>> In the more common hangs though, I get no output.
> 
> That output looks like it had a deadlock on the serial output of sysrq
> key.  But that back trace looks screwy.

Well, not for MIPS.  There isn't any easy/painless method of
backtracing the stack so the MIPS version of dump_stack()
doesn't even try.  Instead it scans the entirety of the
stack and prints out anything and everything which smells
like a valid kernel text address, hence the screwy output.

>> I decided to review the changes I made in getting it to compile and
>> was hoping that this one may be the cause of the instability.  I
>> thought that perhaps this change was incorrect because
>> include/asm-mips/rwsem.h is introduced by the rt-preempt patch and
> 
> Ha, you're right!  (added John Cooper to this so he can clean up this mess
> ;)

Deselection of RWSEM_GENERIC_SPINLOCK in arch/mips/Kconfig is
a bug.   Unfortunately I don't have an available mips target
ATM and few if any spare cycles, but I'd sure like to get MIPS
through this nagging impasse.

That said, keep in mind due to limitations in the MIPS ABI
which carry over to gcc, latency instrumentation as it
currently exists (or may ever exist) is effectively
unsupportable.  IMHO this is a serious stumbling block for
realistic support of the RT work on this architecture.

-john

-- 
john.cooper@member.fsf.org