[Xenomai-core] Analogy: cancel ongoing commands when a device is closed

[Xenomai-core] Analogy: cancel ongoing commands when a device is closed

[Daniele Nicolodi]

After fixing analogy to permit continuous acquisition, I discovered that
ongoing commands are not canceled when a device is closed (I obtain a
DMA buffer owerwrite warning in the kernel log when I abruptly terminate
 my acquisition program).

I think this is quite a surprising behavior. I would expect that the
commands are canceled when there isn't a data consumer any more. Would
it be possible to cancel any ongoing command on device close? If there
is agreement on this, I can look into providing a patch.

Thanks. Cheers,
-- 
Daniele

Re: [Xenomai-core] Analogy: cancel ongoing commands when a device is closed

[Alexis Berlemont]

Daniele Nicolodi wrote:
> After fixing analogy to permit continuous acquisition, I discovered that
> ongoing commands are not canceled when a device is closed (I obtain a
> DMA buffer owerwrite warning in the kernel log when I abruptly terminate
>  my acquisition program).
> 
> I think this is quite a surprising behavior. I would expect that the
> commands are canceled when there isn't a data consumer any more. Would
> it be possible to cancel any ongoing command on device close? If there
> is agreement on this, I can look into providing a patch.
> 
The close should indeed stop any occurring acquisition. I implemented
this behaviour. It is in my git repository.

> Thanks. Cheers,

Alexis.

Re: [Xenomai-core] Analogy: cancel ongoing commands when a device is closed

[Daniele Nicolodi]

Alexis Berlemont wrote:
> Daniele Nicolodi wrote:
>> After fixing analogy to permit continuous acquisition, I discovered that
>> ongoing commands are not canceled when a device is closed (I obtain a
>> DMA buffer owerwrite warning in the kernel log when I abruptly terminate
>>  my acquisition program).
>>
>> I think this is quite a surprising behavior. I would expect that the
>> commands are canceled when there isn't a data consumer any more. Would
>> it be possible to cancel any ongoing command on device close? If there
>> is agreement on this, I can look into providing a patch.
>>
> The close should indeed stop any occurring acquisition. I implemented
> this behaviour. It is in my git repository.

Hi Alexis. I have been working with analogy from your git three and I
should say that the new behavior, in my use case, is worst than the
previous.

Now, when a device is closed, all accurring acquisition are terminated,
also the ones that haven't been started by the current process. While it
is possible to use at the same time two different subdevices, from two
different processes, now it is not possible to terminate one process and
leave the other one running. I think that the correct behavior would be
to terminate just the acquisitions started by the current process.
However, I have no idea on how difficult this would be.

This bring me also to the fact that there isn't currently a way to
prevent two concurrent processes to access the same subdevice,
interfering each other. Would it possible to have a lock() method, as
comedi has?

Thanks. Cheers,
-- 
Daniele

Re: [Xenomai-core] Analogy: cancel ongoing commands when a device is closed

[Alexis Berlemont]

Hi,

Daniele Nicolodi wrote:
> Alexis Berlemont wrote:
> > Daniele Nicolodi wrote:
> >> After fixing analogy to permit continuous acquisition, I discovered that
> >> ongoing commands are not canceled when a device is closed (I obtain a
> >> DMA buffer owerwrite warning in the kernel log when I abruptly terminate
> >>  my acquisition program).
> >>
> >> I think this is quite a surprising behavior. I would expect that the
> >> commands are canceled when there isn't a data consumer any more. Would
> >> it be possible to cancel any ongoing command on device close? If there
> >> is agreement on this, I can look into providing a patch.
> >>
> > The close should indeed stop any occurring acquisition. I implemented
> > this behaviour. It is in my git repository.
> 
> Hi Alexis. I have been working with analogy from your git three and I
> should say that the new behavior, in my use case, is worst than the
> previous.
> 
> Now, when a device is closed, all accurring acquisition are terminated,
> also the ones that haven't been started by the current process. While it
> is possible to use at the same time two different subdevices, from two
> different processes, now it is not possible to terminate one process and
> leave the other one running. I think that the correct behavior would be
> to terminate just the acquisitions started by the current process.
> However, I have no idea on how difficult this would be.
> 

We had two alternatives: either stopping nothing or cancelling "any
ongoing command" related with the device. Cancelling only acquisitions
initiated by a specific process implies the implementation of some
tricky mechanism above the file approach (open, ioctl, close). I am
afraid that we will create some complex code for an issue which should
be solved by a suitable device file organization (maybe many dev files
instead of a single one). 

I will have a look at what you asked but I cannot ensure anything, I
have no clear solution in mind.

> This bring me also to the fact that there isn't currently a way to
> prevent two concurrent processes to access the same subdevice,
> interfering each other. Would it possible to have a lock() method, as
> comedi has?

There is a lock mechanism but it is not exposed as it is in
comedi. The lock system is at the subdevice level: you cannot initiate
an instruction if a command is occuring (the reverse is true of
course). This is handled with a subdevice status bitfield atomically
accessed. Have a look at a4l_reserve_transfer() and tell me if I miss
something. 

> 
> Thanks. Cheers,
> -- 
> Daniele
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core

-- 
Alexis.

[Xenomai-core] Analogy: cmd_bits

[Stefan Schaal]

I tried the new cmd_bits function today to use commands to write to a DIO device on my NI6259 board (thanks a lot, Alexis, for starting this!). Unfortunately, cmd_bits terminates with an error:

root@domain.hid> ./cmd_bits -v -s 2 0xffffffff 0xffffffff
cmd_bits: device analogy0 opened (fd=0)
cmd_bits: basic descriptor retrieved
	 subdevices count = 14
	 read subdevice index = 0
	 write subdevice index = 1
cmd_bits: complex descriptor retrieved
cmd_bits: selected subdevice index = 2
cmd_bits: command successfully sent
cmd_bits: a4l_write failed (err=-2) (count=0)       
(I added a counter in the while loop in cmd_bits.c, and the error occurs immediately after the while loop is entered, i.e., count=0)

root@domain.hid> dmesg
[63462.716029] Analogy: a4l_write: idle subdevice

Any thoughts what may cause this error?

Best wishes,

-Stefan

Re: [Xenomai-core] Analogy: cmd_bits

[Alexis Berlemont]

Hi,

Stefan Schaal wrote:
> I tried the new cmd_bits function today to use commands to write to a DIO device on my NI6259 board (thanks a lot, Alexis, for starting this!). Unfortunately, cmd_bits terminates with an error:
> 
> root@domain.hid> ./cmd_bits -v -s 2 0xffffffff 0xffffffff
> cmd_bits: device analogy0 opened (fd=0)
> cmd_bits: basic descriptor retrieved
> 	 subdevices count = 14
> 	 read subdevice index = 0
> 	 write subdevice index = 1
> cmd_bits: complex descriptor retrieved
> cmd_bits: selected subdevice index = 2
> cmd_bits: command successfully sent
> cmd_bits: a4l_write failed (err=-2) (count=0)       
> (I added a counter in the while loop in cmd_bits.c, and the error occurs immediately after the while loop is entered, i.e., count=0)
> 
> root@domain.hid> dmesg
> [63462.716029] Analogy: a4l_write: idle subdevice

I noticed this bug. I am working on it. This test program disclosed an
annoying bug which needs some time to fix: a4l_async_write() returned
"idle subdevice" because the subdevice index is wrongly retrieved.

> 
> Any thoughts what may cause this error?
> 
> Best wishes,
> 
> -Stefan

-- 
Alexis.

Re: [Xenomai-core] Analogy: cancel ongoing commands when a device is closed

[Alexis Berlemont]

Hi,

Alexis Berlemont wrote:
> Hi,
> 
> Daniele Nicolodi wrote:
> > Alexis Berlemont wrote:
> > > Daniele Nicolodi wrote:
> > >> After fixing analogy to permit continuous acquisition, I discovered that
> > >> ongoing commands are not canceled when a device is closed (I obtain a
> > >> DMA buffer owerwrite warning in the kernel log when I abruptly terminate
> > >>  my acquisition program).
> > >>
> > >> I think this is quite a surprising behavior. I would expect that the
> > >> commands are canceled when there isn't a data consumer any more. Would
> > >> it be possible to cancel any ongoing command on device close? If there
> > >> is agreement on this, I can look into providing a patch.
> > >>
> > > The close should indeed stop any occurring acquisition. I implemented
> > > this behaviour. It is in my git repository.
> > 
> > Hi Alexis. I have been working with analogy from your git three and I
> > should say that the new behavior, in my use case, is worst than the
> > previous.
> > 
> > Now, when a device is closed, all accurring acquisition are terminated,
> > also the ones that haven't been started by the current process. While it
> > is possible to use at the same time two different subdevices, from two
> > different processes, now it is not possible to terminate one process and
> > leave the other one running. I think that the correct behavior would be
> > to terminate just the acquisitions started by the current process.
> > However, I have no idea on how difficult this would be.
> > 
> 

I just pushed into the branch analogy of my git repository what you
asked. Starting from now, the only asynchronous acquisition to be
cancelled will be the one which is related with the file descriptor to
be closed.

I reviewed the Analogy core to do so. You should not notice any API /
ABI breakage.

> We had two alternatives: either stopping nothing or cancelling "any
> ongoing command" related with the device. Cancelling only acquisitions
> initiated by a specific process implies the implementation of some
> tricky mechanism above the file approach (open, ioctl, close). I am
> afraid that we will create some complex code for an issue which should
> be solved by a suitable device file organization (maybe many dev files
> instead of a single one). 
> 
> I will have a look at what you asked but I cannot ensure anything, I
> have no clear solution in mind.
> 
> > This bring me also to the fact that there isn't currently a way to
> > prevent two concurrent processes to access the same subdevice,
> > interfering each other. Would it possible to have a lock() method, as
> > comedi has?
> 
> There is a lock mechanism but it is not exposed as it is in
> comedi. The lock system is at the subdevice level: you cannot initiate
> an instruction if a command is occuring (the reverse is true of
> course). This is handled with a subdevice status bitfield atomically
> accessed. Have a look at a4l_reserve_transfer() and tell me if I miss
> something. 
> 
> > 
> > Thanks. Cheers,
> > -- 
> > Daniele
> > 
> > _______________________________________________
> > Xenomai-core mailing list
> > Xenomai-core@domain.hid
> > https://mail.gna.org/listinfo/xenomai-core
> 
> -- 
> Alexis.

-- 
Alexis.