Sorry for the continued noise, but this bug/crash is proving quite difficult to nail down.

Currently, I'm setting the interval for input_polldev to 10 ms. However, with video data being retrieved at the same time, it's quite possible that one iteration of poll() will take longer than that. Could this ultimately be the reason? What happens if a new poll() call is scheduled before the previous one completes?

Best, Florian

On March 23, 2015 4:47:19 PM CET, Florian Echtler [off-list ref] wrote:

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:

quoted

Hello everyone,

now that I'm using the newly merged sur40 video driver in a

development

quoted

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

quoted

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

quoted

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

quoted

for a lock due to the video functions and that causes the lockup, but

I

quoted

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 PDP-11