Thread stuck in ioctl

["Jüri Põldre" <jyri.poldre@artecdesign.com>]

Hello,

DVB hardware platform is using ioctl based interface to engage kernel calls 
from userspace. The code base is rather large and extends inside kernel to 
two separate processors - one for video and another for audio decoding. 
During bad signal quality one of these calls locks up causing userspace 
thread to do the same. After some time watchdog resets device.
Although it is possible to add debug printouts to this interface doing so 
would cause a lot of traffic and also shift process timings.  Embedded 
platforms are relatively slow and lot of debug info chokes them pretty fast.
It would be very helpful to print backtrace of stuck thread.
It is possible to start gdb debugging in non-stop mode. After ioctl locks 
switch to locked thread with "thread nr" command works but nothing can be 
done as it is running. Stopping thread with "interrupt" command does not 
succeed because breakpoint in thread is never reached causing gdb to wait 
forever.
Scheduler should be aware of locked thread environment. Can you tell me if 
this is fundamental issue or can it be overcome? It is ok that program 
cannot be debugged further,  only information about stuck thread backtrace 
is required.

HW platform MIPS32r2 300 MHz, Linux 2.6.18, gdb 7.2

Sincerely,
JĆ¼ri PƵldre.