Hi, First of all, I verified if I have this fix in my code base and I do have it.
"Are the flags == 0x101? In this case the thread is in the middle of _Event_Seize()" Yes. Even if in my test the ping packets arrive once at every second and there is plenty of time, sometimes it happens that rtems_event_send() is called from the USB ISR when we are in _Event_Seize (called from rtems_event_receive) It's rare, but it happens. (it could happen quicker if I run ping flood (-f option)) "The unblock is done in _Event_Seize() in this case" Ok, now I understand why THREAD_WAIT_STATE_INTEND_TO_BLOCK exists ... so that if an ISR arrives before _Thread_Wait_flags_try_change and changes the wait flags from INTEND_TO_BLOCK to READY_AGAIN, the function will return false and _Thread_Unblock will get called, right ? Problem is, I don't think it is called; otherwise I would see the thread making progress. Maybe there is a synchronization issue with the wait flags that I don't understand. regards, Catalin On Fri, Oct 5, 2018 at 10:06 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > > > On 04/10/2018 15:33, Catalin Demergian wrote: > > I eliminated the theory of memory corruption. I debugged and found we > > set Wait.flags = 0x104 with a function call. > > The USB interrupt can arrive at any time, so Wait.flags can be either > > INTEND_TO_BLOCK, BLOCKED or READY_AGAIN. > > > > Following the logic in _Event_Surrender: > > If it arrives when Wait.flags = INTEND_TO_BLOCK > > Are the flags == 0x101? In this case the thread is in the middle of > _Event_Seize() > > > then _Thread_Wait_flags_try_change_critical will return TRUE, > > Wait.flags will be set to READY_AGAIN, > > unblock = FALSE so _Thread_Unblock will not be called. > > The unblock is done in _Event_Seize() in this case: > > success = _Thread_Wait_flags_try_change_acquire( > executing, > intend_to_block, > wait_class | THREAD_WAIT_STATE_BLOCKED > ); > > The success == false in this case. > > > Then all the other USB interrupts will catch Wait.flags = READY_AGAIN > > and in this case_Event_Surrender doesn't do anything because unblock = > > FALSE > > > > .. so the task never runs again, but state remains marked as READY. > > is this a bug ? or I'm not understanding correctly? > > There could be a synchronization issue with the wait flag or the > interrupt disable/enable sequence. > > There was a severe bug on the ARMv7-M in this area, but it is fixed in > the 4.11.2 release: > > > https://git.rtems.org/rtems/commit/?h=4.11&id=7e91901303219f10cf865906931c07c31d2e37f4 > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
