* [Xenomai-core] Analogy: cancel ongoing commands when a device is closed @ 2010-03-18 16:50 Daniele Nicolodi 2010-03-19 0:05 ` Alexis Berlemont 0 siblings, 1 reply; 7+ messages in thread From: Daniele Nicolodi @ 2010-03-18 16:50 UTC (permalink / raw) To: xenomai 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-core] Analogy: cancel ongoing commands when a device is closed 2010-03-18 16:50 [Xenomai-core] Analogy: cancel ongoing commands when a device is closed Daniele Nicolodi @ 2010-03-19 0:05 ` Alexis Berlemont 2010-03-29 18:40 ` Daniele Nicolodi 0 siblings, 1 reply; 7+ messages in thread From: Alexis Berlemont @ 2010-03-19 0:05 UTC (permalink / raw) To: Daniele Nicolodi; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-core] Analogy: cancel ongoing commands when a device is closed 2010-03-19 0:05 ` Alexis Berlemont @ 2010-03-29 18:40 ` Daniele Nicolodi 2010-04-05 21:54 ` Alexis Berlemont 0 siblings, 1 reply; 7+ messages in thread From: Daniele Nicolodi @ 2010-03-29 18:40 UTC (permalink / raw) To: Alexis Berlemont; +Cc: xenomai 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-core] Analogy: cancel ongoing commands when a device is closed 2010-03-29 18:40 ` Daniele Nicolodi @ 2010-04-05 21:54 ` Alexis Berlemont 2010-04-23 20:39 ` [Xenomai-core] Analogy: cmd_bits Stefan Schaal 2010-06-24 23:04 ` [Xenomai-core] Analogy: cancel ongoing commands when a device is closed Alexis Berlemont 0 siblings, 2 replies; 7+ messages in thread From: Alexis Berlemont @ 2010-04-05 21:54 UTC (permalink / raw) To: Daniele Nicolodi; +Cc: Alexis Berlemont, xenomai 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Xenomai-core] Analogy: cmd_bits 2010-04-05 21:54 ` Alexis Berlemont @ 2010-04-23 20:39 ` Stefan Schaal 2010-04-24 22:20 ` Alexis Berlemont 2010-06-24 23:04 ` [Xenomai-core] Analogy: cancel ongoing commands when a device is closed Alexis Berlemont 1 sibling, 1 reply; 7+ messages in thread From: Stefan Schaal @ 2010-04-23 20:39 UTC (permalink / raw) To: xenomai; +Cc: Peter Pastor Sampedro 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-core] Analogy: cmd_bits 2010-04-23 20:39 ` [Xenomai-core] Analogy: cmd_bits Stefan Schaal @ 2010-04-24 22:20 ` Alexis Berlemont 0 siblings, 0 replies; 7+ messages in thread From: Alexis Berlemont @ 2010-04-24 22:20 UTC (permalink / raw) To: Stefan Schaal; +Cc: Peter Pastor Sampedro, xenomai 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-core] Analogy: cancel ongoing commands when a device is closed 2010-04-05 21:54 ` Alexis Berlemont 2010-04-23 20:39 ` [Xenomai-core] Analogy: cmd_bits Stefan Schaal @ 2010-06-24 23:04 ` Alexis Berlemont 1 sibling, 0 replies; 7+ messages in thread From: Alexis Berlemont @ 2010-06-24 23:04 UTC (permalink / raw) To: Daniele Nicolodi; +Cc: Alexis Berlemont, xenomai 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-06-24 23:04 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-03-18 16:50 [Xenomai-core] Analogy: cancel ongoing commands when a device is closed Daniele Nicolodi 2010-03-19 0:05 ` Alexis Berlemont 2010-03-29 18:40 ` Daniele Nicolodi 2010-04-05 21:54 ` Alexis Berlemont 2010-04-23 20:39 ` [Xenomai-core] Analogy: cmd_bits Stefan Schaal 2010-04-24 22:20 ` Alexis Berlemont 2010-06-24 23:04 ` [Xenomai-core] Analogy: cancel ongoing commands when a device is closed Alexis Berlemont
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.