Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
I thought about this issue again and found the reason for my vague bad
feeling: re-init is not atomic, thus racy. But also the test+sem_init
pattern I suggested is no
Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>> Jan Kiszka wrote:
Jan Kiszka wrote:
> I thought about this issue again and found the reason for my vague bad
> feeling: re-init is not atomic, thus racy. But also the test+sem_init
> pattern I suggeste
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
I thought about this issue again and found the reason for my vague bad
feeling: re-init is not atomic, thus racy. But also the test+sem_init
pattern I suggested is not save.
I guess we need to enhance rtdm_XXX_in
Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>> I thought about this issue again and found the reason for my vague bad
>>> feeling: re-init is not atomic, thus racy. But also the test+sem_init
>>> pattern I suggested is not save.
>>>
>>> I guess we need to enhance rtdm_XXX_i
Jan Kiszka wrote:
Jan Kiszka wrote:
I thought about this issue again and found the reason for my vague bad
feeling: re-init is not atomic, thus racy. But also the test+sem_init
pattern I suggested is not save.
I guess we need to enhance rtdm_XXX_init in this regard to make the
RT-CAN use case a
Jan Kiszka wrote:
> I thought about this issue again and found the reason for my vague bad
> feeling: re-init is not atomic, thus racy. But also the test+sem_init
> pattern I suggested is not save.
>
> I guess we need to enhance rtdm_XXX_init in this regard to make the
> RT-CAN use case an officia
Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>> Jan Kiszka wrote:
Wolfgang Grandegger wrote:
> Hi Jan,
>
> Jan Kiszka wrote:
>> Hi Wolfgang,
>>
>> fiddling with the CAN utils, I noticed the behaviour that
>> rtcansend on
>> fresh
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hi Jan,
Jan Kiszka wrote:
Hi Wolfgang,
fiddling with the CAN utils, I noticed the behaviour that rtcansend on
freshly registered but stopped devices simply blocks. And when you
meanwhile call rtcanconf
Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>> Hi Jan,
>>>
>>> Jan Kiszka wrote:
Hi Wolfgang,
fiddling with the CAN utils, I noticed the behaviour that rtcansend on
freshly registered but stopped devices simply blocks. And when you
meanwhil
Jan Kiszka wrote:
> I don't think that the sem state
> should be used for encoding the CAN device state towards potential senders.
Why not?
--
Sebastian
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hi Jan,
Jan Kiszka wrote:
Hi Wolfgang,
fiddling with the CAN utils, I noticed the behaviour that rtcansend on
freshly registered but stopped devices simply blocks. And when you
meanwhile call rtcanconfig up on that device, rtcansend will continue t
Wolfgang Grandegger wrote:
> Hi Jan,
>
> Jan Kiszka wrote:
>> Hi Wolfgang,
>>
>> fiddling with the CAN utils, I noticed the behaviour that rtcansend on
>> freshly registered but stopped devices simply blocks. And when you
>> meanwhile call rtcanconfig up on that device, rtcansend will continue to
Hi Jan,
Jan Kiszka wrote:
Hi Wolfgang,
fiddling with the CAN utils, I noticed the behaviour that rtcansend on
freshly registered but stopped devices simply blocks. And when you
meanwhile call rtcanconfig up on that device, rtcansend will continue to
block.
I see the expected behavior on stopp
Jan Kiszka wrote:
Hi Wolfgang,
fiddling with the CAN utils, I noticed the behaviour that rtcansend on
freshly registered but stopped devices simply blocks. And when you
meanwhile call rtcanconfig up on that device, rtcansend will continue to
block.
This is a bug, the send function should retur
14 matches
Mail list logo
