Hi Sakari, Hans, Do either of you have any thoughts on whether I'm actually leaking any resources, or whether this is just a warning that doesn't have any practical implication since I'm tearing down the videobuf2 queue? I don't really care about the embedded use case - do you see any reason where at least for my local tree I cannot simply revert this patch until a real solution is found? Cheers, Devin On Mon, Jan 29, 2018 at 8:44 PM, Devin Heitmueller <dheitmueller@xxxxxxxxxxxxxx> wrote: > Hello Sakari, > > Thanks for taking the time to investigate. See comments inline. > > On Sun, Jan 28, 2018 at 5:23 PM, Sakari Ailus > <sakari.ailus@xxxxxxxxxxxxxxx> wrote: >> Hi Devin, >> >> On Sun, Jan 28, 2018 at 09:12:44AM -0500, Devin Heitmueller wrote: >>> Hello all, >>> >>> I recently updated to the latest kernel, and I am seeing the following >>> dumped to dmesg with both au0828 and em28xx based devices whenever I >>> exit tvtime (my kernel is compiled with CONFIG_VIDEO_ADV_DEBUG=y by >>> default): >> >> Thanks for reporting this. Would you be able to provide the full dmesg, >> with VB2 debug parameter set to 2? > > Output can be found at https://pastebin.com/nXS7MTJH > >> I can't immediately see how you'd get this, well, without triggering a >> kernel warning or two. The code is pretty complex though. > > If this is something I screwed up when I did the VB2 port for em28xx > several years ago, point me in the right direction and I'll see what I > can do. However given we're seeing it with multiple drivers, this > feels like some subtle issue inside videobuf2. > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com
