Mauro, Thanks. (Resending in plain text as last email was rejected by email list). I'll look at the patch, and let you know if that helps. I'll send out the application tomorrow as I'm not on my dev machine right now. -Trevor On Sun, May 11, 2014 at 10:58 AM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote: > Hi Trevor, > > Em Fri, 9 May 2014 11:19:49 -0400 > Trevor Anonymous <trevor.forums@xxxxxxxxx> escreveu: > >> Hello all, >> >> I have written a simple application to capture RF QAM transport >> streams with the Hauppauge 950Q, and save to a file. This is >> essentially the same as dvbstream, but with unnecessary stuff removed >> (and I have verified this bug using dvbstream as well): >> - tune using frontend device >> - demux device: DMX_SET_PES_FILTER on pid 8192 with DMX_OUT_TS_TAP output. >> - Read from dvr device, save to file. >> - Interrupt app using alarm() and stop pes filter, close devices. >> >> >> This works as expected. The problem is after running this a bunch of >> times (sometimes 15-20+), the device seems to eventually get into a >> bad state, and nothing is available to read on the dvr device. The >> lockup never seems to happen while reading data (i.e., either data >> comes and the app works completely, or the app reads 0 bytes). When >> this happens, all the tuning/demod locks look good, and everything >> appears to be working -- there just isn't data ready to read from the >> dvr device. >> >> When it gets into a bad state, I have to physically remove/reinsert >> the 950Q device or otherwise reset the device (e.g., usb reset - >> USBDEVFS_RESET ioctl). > > Yes, I noticed a similar issue with last devel Kernel. I suspect > that the culprit could be due to a sheduled work that fixes a > hardware bug. Such scheduled work task should be cancelled when > the device is closed or the channel is changed. This is likely > a partial fix for it (untested): > https://patchwork.linuxtv.org/patch/23860/ > > It makes sure that the thread is canceled when a new set frontend > ioctl is sent. Yet, this patch won't solve your specific problem. > > I suspect that the right approach would be to also call > cancel_work_sync(&dev->restart_streaming) on all other places > where stop_urb_transfer() is called. > > Btw, could you share your small test application? That would > help us to test the bug locally and work on a patch. > >> >> Has anyone seen this issue before? >> >> I am running Fedora 19 with 3.13.9 kernel. Hardware is: >> - au0828, au8522, xc5000 (with dvb-fe-xc5000c-4.1.30.7.fw) >> >> >> Thanks, >> -Trevor >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
