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:
signature.asc
Description: OpenPGP digital signature
