[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Possible bug in RTEMS core.
- Date: 26 Feb 1999 19:11:11 +0300
- From: osv at Javad.RU (Sergei Organov)
- Subject: Possible bug in RTEMS core.
I think there is a bug in the '_Thread_Yield_processor()' routine. I
had encountered problem (the program just hangs) that disappears if I
comment out '_ISR_Flash(level)' call in the middle of the routine. The
problem description follows. It'd be fine if somebody experienced in
RTEMS internals takes a close look into '_Thread_Yield_processor()'.
The problem occurs when there are two tasks with equal priorities that
are just usual forever loops calling
rtems_task_wake_after(RTEMS_YIELD_PROCESSOR) at every loop
iteration. To run into trouble it's enough to have one of these two
tasks to wait on, let's say semaphore, that is released by _interrupt
service routine_ that handles asynchronous interrupt. In my program
the semaphore is inside RS232 driver and task just calls 'printf' that
eventually results in waiting on the semaphore:
Commenting out any of calls makes problem go away. Making priorities
for 'task1' and 'task2' different (not the same) makes problem go
away. Commenting out '_ISR_Flash(level)' inside
'_Thread_Yield_processor' makes problem go away.
I used RTEMS 3.6.0 and my own BSP for custom hardware when problem
occured. Unfortunately I have no possibility to check if problem
exists if some of BSPs provided with RTEMS is used. All tests provided
with RTEMS run smoothly with my configuration, though. I looked into
RTEMS 4.0 code - it seems nothing significant was changed in this area
BTW, do you think it is really critical for maximum interrupt latency
to have _ISR_Flash(level) call in the '_Thread_Yield_processor()'?
Also, I'd like to say that all these isn't at all critical for me - I
just want to inform you that maybe there is some bug here.