This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

sandeep



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]