Additional note: this happens almost never with the original code using
dma-contig, which is why I didn't catch it during testing. I've now
switched back and forth between the two versions multiple times, and
it's definitely a lot less stable with dma-sg and usb_sg_init/_wait.
Maybe that can help somebody in narrowing down the reason of the problem?

Best, Florian

On 23.03.2015 12:57, Florian Echtler wrote:

Hello everyone,

now that I'm using the newly merged sur40 video driver in a development
environment, I've noticed that a custom V4L2 application we've been
using in our lab will sometimes trigger a hard lockup of the machine
(_nothing_ works anymore, no VT switching, no network, not even Magic
SysRq).

This doesn't happen with plain old cheese or v4l2-compliance, only with
our custom application and only under X11, i.e. as far as I can tell,
when the input device is being polled at the same time. However, I have
a really hard time tracking this down, as even SysRq doesn't work
anymore. A console continuously dumping dmesg or strace of our tool
didn't really help, either.

I assume that somehow the input_polldev thread is put to sleep/waiting
for a lock due to the video functions and that causes the lockup, but I
can't really tell where that might happen. Can somebody with better
knowledge of the internals give some suggestions?

Thanks & best regards, Florian

-- 
SENT FROM MY DEC VT50 TERMINAL