[En-Nut-Discussion] Nut errors!? -- Found and corrected

[Matthias Ringwald]

Hi

the bug which let main sleep forever was cause by NutThreadWake which  
is called from
NutProcessElapsed timer. This callback is now been done in user  
context instead of IRQ
context to improve responsiveness of nut/os as whole. unfortunately,  
we forgot to
protect the access to the readyList in NutThreadWake.

so if a NutThreadWake was called in the same time when another Thread  
was signaled,
e.g. by data from uart, the access to the readyList resulted in one  
thread getting lost.

I think I'll have another check on some functions, after I do  
understand the code right now. :)

Oh. If you're using nut cvs head, you definitely should update soon..

matthias


On 11.07.2005, at 16:15, Lukas Winterhalter wrote:

> Hello Matthias
>
>
>> I did already suspect that the main thread did not show  
>> 'signaled'  only because of the usart driver.
>> The question is now, how did the thread get signaled but not moved  
>> to  the ready-to-run queue.
>> I guess it is signaled from the USART driver by means of   
>> NutPostEventFromIrq.
>> checking the event.c code, I see, that if the thread is waiting  
>> in  the queue, it will
>> be put to the readyQueue (and should be woken) up. The   
>> NutThreadResume code looks solid.
>> So the more likely option would be that the queue is signaled  
>> before  NutEventPostFromIrq is called.
>> Hm. this sounds weird, I do agree.
>> Could you somehow check, if NutEventWait, NutEventPostFromIrq and   
>> NutThreadResume work on this specific
>> queue?
>>
> I didn't found a good way on how to do this yet.
>
>
>> I'll have a deeper look on this later.
>> Did you use timeouts for the uarts ?
>>
> No. I did a testrun with a 2 sec timeout and this is what I get:
>
> Hndl Name     Prio Sta QUE  Timr StkP FreeMem
> 2E59 status     64 RUN 0453 0000 2E03   938 OK 2E59 061E
> 2A3C sleeper8   64 SLP 0000 2EC6 2A1C   992 OK
> 261F sleeper7   64 SLP 0000 2E9E 25FF   992 OK
> 2202 sleeper6   64 SLP 0000 2E76 21E2   992 OK
> 1DE5 sleeper5   64 SLP 0000 2F16 1DC5   992 OK
> 19C8 sleeper4   64 SLP 0000 2EB2 19A8   992 OK
> 15AB sleeper3   64 SLP 0000 2F02 158B   992 OK
> 118E sleeper2   64 SLP 0000 2E8A 116E   992 OK
> 0D71 sleeper1   64 SLP 0000 2EDA 0D51   992 OK
> 093B main       64 SLP 0236 2E76 0848   525 OK
> 061E idle      254 RDY 0453 0000 0602   356 OK 2E59 061E
>
> Cheers
> Lukas
>
>
>> matthias
>> On 11.07.2005, at 14:30, Lukas Winterhalter wrote:
>>
>>> Hi all,
>>>
>>> I tried the crash_termthread example with the uart driver  
>>> instead  of the usart driver. The main thread gets blocked again  
>>> quickly,  but the output was slightly different:
>>>
>>> Hndl Name     Prio Sta QUE  Timr StkP FreeMem
>>> 2E59 status     64 RUN 0453 0000 2E03   938 OK 2E59 061E
>>> ..
>>> 093B main       64 SLP 0238 0000 087F   580 OKSIGNALED
>>> 061E idle      254 RDY 0453 0000 0602   356 OK 2E59 061E
>>> ..
>>>
>>> Note that the main threads wait queue is marked 'SIGNALED' while   
>>> still being not in ready queue. As far as I understand it this   
>>> _should_ not be possible??
>>>
>>>
>>>
>> _______________________________________________
>> En-Nut-Discussion mailing list
>> En-Nut-Discussion at egnite.de
>> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
>>
>
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
>