This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: [SMP] direct/indirect printing via asr can cause lockups
- From: Nick Garnett <nickg at ecoscentric dot com>
- To: sandeep <shimple0 at yahoo dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: 24 Nov 2004 10:27:58 +0000
- Subject: Re: [ECOS] [SMP] direct/indirect printing via asr can cause lockups
- References: <20041121160447.30953.qmail@web52705.mail.yahoo.com>
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