Unexplained module resets

We’ve been investigating WP76xx module crashes that started after we disabled SMACK (a requirement for our application) but so far haven’t been able to identify the cause. We’ve disabled SMACK using both the menuconfig utility and following this solution , but it makes no difference how we disable it. The resets seem possibly associated with UART activity since isolating and disabling it seems to stop them (though that’s a little unclear) but we’re not sure that’s the real cause as it doesn’t make much sense how such a basic feature could cause them. I suppose the serial input buffer could be overflowing somehow but hardware flow control is enabled (and working as we looked into that) so suspect that’s not the real issue. Re-enabling SMACK does stop them.

The other odd thing is the reset cause is listed LE_INFO_RESET_USER, yet we are certainly not requesting resets or rebooting the modules in code. We’ve run “logread -f” and watched while they happen to look for anything being reported before the resets but there’s nothing. Looking for any suggestions on how to track down the cause. Unfortunately requests to Sierra for assistance fall on deaf ears, as usual.

Will changing lower baud rate in uart help?
Did you use sandbox feature?
Did you set faultaction in .adef file?
Is there any kernel message in uart2 console when crash?

Definitely some strange UART behavior going on. With SMACK enabled setting the baud rate fails with LE_UNSUPPORTED. With SMACK disabled setting it appears to succeed (it returns LE_OK) but I don’t think it does anything. If we don’t set it at all but vary the rate at which we send to the port the rate seems to autosynch (after a module reboot), since we can read the input and it’s not garbled, even though Legato always reports 115200 (the default) regardless the actual rate. Anyway it still resets with LE_USER_REQUESTED with SMACK disabled regardless of the rate. Seems like there may be some incompatibilty with disabling SMACK and using the UART, something going on with the UART driver maybe.
We are unsandboxed.
Faultaction is set to restart the process.
Unfortunately we didn’t connect UART2 to anything and so can’t read console messages. Is there any other way to read kernel messages?

How about enable the sandbox function?
Also you can try faultaction to do nothing

Kernel msg is only on uart1 or uart2.
You might also see some message is dmesg via usb ecm port