The new functionality to debug an RT thread in RTL3.0 is GREAT. It has helped us clean up several stubborn bugs in our code. Problem is, there does not seem to be a way for us to programmatically detect whether our RT thread has caused an exception, and is halted waiting for us to debug it. The RT thread is started remotely from a GUI on a separate machine, so the users never interact with the console on the "host" machine. If the thread crashes, all the users know is that the host has "locked up". In response to this, they click the STOP button in the GUI which causes another remote access to attempt to unload our RT module (procedure somewhat simplified). Our cleanup_module function contains a pthread_join() to clean up after the RT thread. When pthread_join is executed on a stopped thread, kernel deadlock occurs. Is there a handler that we can use to detect when RTL has halted waiting in a debug situation? It would be nice to signal our non-RT process (via FIFO) to not attempt to unload the module in this case so that we could debug it. I would rather not do a select() on the FIFO read on the NRT side to implement a timeout, if at all possible. We are using RTL3.0-pre7 w kernel 2.2.17. Kernel compled with SMP, using an Intel GX+ SMP MB with only 1 CPU installed. Thanks. --- Michael M. Morrison VP/Chief Technical Officer Hyperion Technologies, Inc. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
