Hi Florian, On 5/21/21 9:34 AM, Florian Echtler wrote: > Hello everyone, > > we came across a regression in the V4L2 part of the sur40 driver. I've > been out of the loop with V4L2 development for some time, so I'd > appreciate any bit of input for debugging this. > > When trying to read from the associated video device, the following > stacktrace gets dumped by the kernel: > > [55921.426292] CPU: 1 PID: 304262 Comm: guvcview Tainted: G E > 5.13.0-rc2+ #1 > [55921.426296] Hardware name: Samsung SUR40/SDNE-R78BA2-20, BIOS > SDNE-R78BA2-2000 02/23/2012 > [55921.426297] RIP: 0010:dma_map_sg_attrs+0x37/0x50 > [55921.426301] Code: 85 c0 48 0f 44 05 b9 e3 d9 01 83 f9 02 77 19 48 83 > bf 40 02 00 00 00 74 11 48 85 c0 75 11 e8 50 18 00 00 85 c0 78 13 c3 0f > 0b <0f> 0b 31 c0 c3 48 8b 40 50 e8 ab f6 ae 00 eb e9 0f 0b 0f 1f 80 00 > [55921.426303] RSP: 0018:ffffad8a81a4bc38 EFLAGS: 00010246 > [55921.426306] RAX: ffffffff8ee0a140 RBX: 0000000000002dc0 RCX: > 0000000000000002 > [55921.426307] RDX: 0000000000000007 RSI: ffff88fd05ce8100 RDI: > ffff88fe0c026830 > [55921.426309] RBP: 000000000000007f R08: 0000000000000020 R09: > 0000000000000000 > [55921.426310] R10: 0000000000000000 R11: ffffd73b80000000 R12: > ffff88fe04748880 > [55921.426311] R13: 000000000007f000 R14: 0000000000000000 R15: > 0000000000000000 > [55921.426313] FS: 00007fc2fb796440(0000) GS:ffff88fe33d00000(0000) > knlGS:0000000000000000 > [55921.426315] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [55921.426316] CR2: 00007fc2fa9d6000 CR3: 000000000cfee000 CR4: > 00000000000006e0 > [55921.426318] Call Trace: > [55921.426322] vb2_dma_sg_alloc+0x1a2/0x2a0 [videobuf2_dma_sg] > [55921.426329] __vb2_queue_alloc+0x177/0x3c0 [videobuf2_common] > [55921.426337] vb2_core_reqbufs+0x237/0x3b0 [videobuf2_common] > [55921.426344] vb2_ioctl_reqbufs+0x77/0xb0 [videobuf2_v4l2] > [55921.426351] __video_do_ioctl+0x39e/0x3d0 [videodev] > [55921.426379] video_usercopy+0x177/0x750 [videodev] > [55921.426393] ? v4l_print_control+0x20/0x20 [videodev] > [55921.426408] v4l2_ioctl+0x48/0x50 [videodev] > [55921.426422] __x64_sys_ioctl+0x83/0xb0 > [55921.426426] do_syscall_64+0x40/0xb0 > [55921.426429] entry_SYSCALL_64_after_hwframe+0x44/0xae > [55921.426432] RIP: 0033:0x7fc3050a29b9 > [55921.426435] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 > 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f > 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a7 54 0c 00 f7 d8 64 89 01 48 > [55921.426437] RSP: 002b:00007ffcb50d6a28 EFLAGS: 00000246 ORIG_RAX: > 0000000000000010 > [55921.426439] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: > 00007fc3050a29b9 > [55921.426440] RDX: 0000563371288e90 RSI: 00000000c0145608 RDI: > 0000000000000004 > [55921.426442] RBP: 00000000c0145608 R08: 0000000000000000 R09: > 0000000000000000 > [55921.426443] R10: 00007fc304fa5020 R11: 0000000000000246 R12: > 0000000000000004 > [55921.426444] R13: 0000000000000000 R14: 00007fc304fa5020 R15: > 0000563371288e90 > [55921.426447] ---[ end trace fd6bcb1bcbdb4e65 ]--- > > In addition, v4l2-compliance reports some failures regarding buffer > ioctls (see attachment). It looks like the reqbufs call fails (probably in the same spot as in the backtrace above), so the failures after that are the result of that initial failure. > > I can't pinpoint any recent commits to the driver itself that might have > caused this, so I assume it's related to a change in the framework itself. I'm not aware of any relevant changes in the media framework either. If you can bisect, then that would be great. There isn't a lot of useful information in the backtrace. Regards, Hans > > Any suggestions very much appreciated! > > Best, Florian
