04-24-2025 04:54 PM - edited 04-24-2025 04:57 PM
Hello All,
My setup includes a cRIO 9047 running NI RT Linux 24.8 (2024Q4) talking to 5 cDAQ 9189 chassis over ethernet using the daqmx command line tool (nidaqmxconfig) and the daqmx C Reference library. I have AO, AI, DI, and DO modules across the 5 cDAQs and the following task structure:
For each chassis:
In this setup I’ve encountered a few kernel panics in the NI kernel modules that trigger the cRIO to reboot itself.
The first kernel panic type is on Read or WriteDigitalLines calls when my DO or DI tasks have 3 or more C Series modules added to them at a time. This doesn’t always cause the kernel to panic, only after a few edge cases I’ve determined.
1. If I reboot the machine while I’m reading and writing from digital lines, without giving time to clean up tasks, it triggers the kernel panic the next time i try to create a task and read or write from those lines.
2. If I unreserve the chassis before I cleaned up the tasks and then try to re-reserve, create the tasks again, and complete IO, it panics.
The second kernel panic I’ve seen is when interfacing with the nidaqmxconfig tool. I’ve seen kernel panics most often on calls to `nidaqmxconfig --reset DEVICE_NAME` but we have also seen the issue with other commands in the tool (such as reserve). This doesn’t happen deterministically every call to the tool only on rare occurrences. I have been able to trigger this behavior multiple times when using the nidaqmxconfig tool after I reboot the cRIO while running IO and before cleaning up the tasks.
Attached is an example of the relevant information in each of the two kernel panics
Note, that I was able to prevent the first of the two kernel panics by reconfiguring the DI task and the DO task for each chassis into a separate task for each card. I’m not sure how this resolved the issue, but I’m wondering if its possible this is related to the fact we are using software timing for DI and DO. If its suggested we move to hardware timing, what is a good solution to emulate hardware single point outputs on cDAQS (as would be needed to write a PID controller). I was able to accomplish immediate reads using MostRecentSample for inputs, but a similar buffer position does not appear to exist for outputs.
As for the second panic, I have yet to find a mitigation for this. If anyone has seen similar issues before for either of the panics or has any path forward, I would really appreciate some advice as it is causing some pain.