[ECOS] [SMP] direct/indirect printing via asr can cause lockups

Nick Garnett nickg@ecoscentric.com
Wed Nov 24 11:15:00 GMT 2004

sandeep <shimple0@yahoo.com> writes:

> in smp setup, sometimes some tests have been observed
> to get into a state (after part execution) where they
> keep on running for hours w/o progressing further.
> following are the findings with compat-posix-sigsetjmp
> test.
> pthread_entry2 -> cyg_test_output -> diag_write_char
> -> hal_diag_write_char **** timer interrupt ****
> ---> interrupt vsr ---> interrupt_end --->
> unlock_inner
> ---> posix_asr ---> cyg_posix_signal_asr
> ---> cyg_deliver_signals --> sigusr2
> ---> cyg_test_output
> since CYG_HAL_DIAG_LOCK is defined for smp setup and
> amounts to "HAL_SPINLOCK_SPIN(cyg_hal_smp_diag_lock)"
> during second cyg_test_output, when it tries to take
> diag_lock, outcome is obvious.
> what solutions are possible to come out of this
> situation?
> -?- disabling interrupts will be too bad idea during
> cyg_test_output.
> -?- what about taking a schedlock instead of spinlock?
>  it can also have unpleasant effects as sometimes
> message-being-printed could be quite big. 
> so, should we 
> -?- not do any direct/indirect printing via asr.
> -?- have a notion of lock owner (as with schedlock) in
> case of spinlock??? this might not be right. spinlocks
> have specific usage semantics. ecos maintainers/
> experienced developers can provide more insight into -
> how it will be for ecos.

I suspect the simplest approach is to introduce a CPU id and counter
alongside cyg_hal_smp_diag_lock and then implement a recursive lock
just for this purpose. There is already code in the scheduler lock to
do this, so this can be copied and adapted very easily. I don't think
there is any need to introduce a new spinlock type, or to change the
definition of spinlocks as a whole.

Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list