tapasco icon indicating copy to clipboard operation
tapasco copied to clipboard

[libtapasco] Exclusive Access and DMA Buffer allocation wear off after one failed attempt

Open zyno42 opened this issue 3 years ago • 7 comments

When I'm having one Host application running with exclusive access (in this case tapasco-debug in Debug Mode) and then start another runtime application which tries to acquire exclusive access to the same device this results in the following errors in the first two attempts but then from the third attempt on it succeeds.

$ cargo run --
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
     Running `target/debug/tapasco_runtime`
An error occurred: Failed to initialize TLKM object: Could not create device: DMA Error: Could not allocate DMA buffer EMFILE: Too many open files
$ cargo run --
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/tapasco_runtime`
An error occurred: Failed to decode TLKM device: Could not acquire desired mode TlkmAccessExclusive for device 0: EBUSY: Device or resource busy
$ cargo run --
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/tapasco_runtime`

The first error comes from libtapasco allocating all 32 DMA Buffers from TLKM at initialization time which also happens only once.

zyno42 avatar Aug 16 '21 17:08 zyno42

Could you run the driver in debug mode and post the corresponding dmesg output?

jahofmann avatar Aug 16 '21 18:08 jahofmann

Sure. This is the corresponding log:

dmesg_tapasco_issue_296.log

zyno42 avatar Aug 17 '21 07:08 zyno42

It might be enough to add a new DMAControl implementation in https://github.com/esa-tu-darmstadt/tapasco/blob/master/runtime/libtapasco/src/dma.rs that simply does nothing and use that by at https://github.com/esa-tu-darmstadt/tapasco/blob/8f77c7ccb99214d6f1c1b3560eeb16bbe199e53c/runtime/libtapasco/src/device.rs#L356 and https://github.com/esa-tu-darmstadt/tapasco/blob/8f77c7ccb99214d6f1c1b3560eeb16bbe199e53c/runtime/libtapasco/src/device.rs#L389 and https://github.com/esa-tu-darmstadt/tapasco/blob/8f77c7ccb99214d6f1c1b3560eeb16bbe199e53c/runtime/libtapasco/src/device.rs#L400

Lastly, the correct DMA engine has to be loaded and unloaded in https://github.com/esa-tu-darmstadt/tapasco/blob/8f77c7ccb99214d6f1c1b3560eeb16bbe199e53c/runtime/libtapasco/src/device.rs#L484

Otherwise the DMA engine is initialized even for monitor only applications.

jahofmann avatar Aug 17 '21 07:08 jahofmann

Thank you for your suggestions. I've seen through them and I think I haven't stated the problem clearly enough:

The problem is that if a device is exclusively acquired, another application receives the correct EBUSY error only once.

zyno42 avatar Aug 30 '21 14:08 zyno42

I've implemented your suggestions. However, this produces another error message when tapasco-debug runs in monitor mode and another host application runs in exclusive mode: Failed to initialize TLKM object: Could not create device: Scheduler Error: PE Error: Error during interrupt handling: Could not register eventfd with driver: EFAULT: Bad address

As in the previous implementation this error wears off after one retry.

zyno42 avatar Sep 06 '21 16:09 zyno42

I fear this is a similar problem. When the PEs are created, the runtime will also allocate and register eventfd for interrupt handling. This step needs to be postponed until the access mode is exclusive as monitoring apps should not receive the interrupts.

There are also some guards needed around the wait for PE functions to avoid deadlocks if the interrupts have not been set.

This should make the runtime play fine with the driver, but all these checks should also be in the driver so it does not simply crash if "held wrong". In any case this is more for future reference than your work ;)

jahofmann avatar Sep 06 '21 17:09 jahofmann

Might be fixed in #328?

cahz avatar Mar 22 '23 10:03 cahz