Re: [sur40] Debugging a race condition?

[Florian Echtler <floe@butterbrot.org>]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]