RE: buffer delivery stops with cx23885
041ad449683bb2d54a7f082d78ec15bbc958a175 introduced stats gathering into the dib7000p code which seems to generate a lot more i2c traffic which would exacerbate the problem, if one existed. The timing (May/June) very roughly matches what I remember too. When my recording stops, so do the Next all layers stats available in... messages, although that could be for other reasons. Anyway, I'll comment out the call to dib7000p_get_stats and see if it makes a difference. That didn't help. Having chmod 'd /dev/dvb/adapter1 so that mythtv can't open the second tuner, things have been absolutely solid for a week. As soon as I let mythtv access the second tuner it hangs almost immediately. Based on a bunch of printk's I added, the tuner loses sync/lock which would explain why buffer delivery stops. I had been looking in the wrong place. I can't see anything happening when this happens though, it doesn't seem to coincide with gathering stats or anything but I can't be completely sure. Other things I have observed when things stop working are: DiB7000P: i2c read error (often) DiB0070 I2C read failed (less often) DiB0070 I2C write failed (less often) NMI: PCI system error (SERR) for reason b1 on CPU 0. (rarely) Where could the two tuners be treading on each other? Thanks James
RE: buffer delivery stops with cx23885
I'll test out the downgrade to 73d8102298719863d54264f62521362487f84256 just to be sure, then see if I can take it further back. 73d8102298719863d54264f62521362487f84256 still breaks for me, so it's definitely not related to the conversion. Any hints on what I can do to figure out what layer it's stalling at? Thanks James
Re: buffer delivery stops with cx23885
On 09/22/2014 10:30 AM, James Harper wrote: I'll test out the downgrade to 73d8102298719863d54264f62521362487f84256 just to be sure, then see if I can take it further back. 73d8102298719863d54264f62521362487f84256 still breaks for me, so it's definitely not related to the conversion. Good. Any hints on what I can do to figure out what layer it's stalling at? I have no idea. I would do a git bisect to try and narrow it down. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: buffer delivery stops with cx23885
Any hints on what I can do to figure out what layer it's stalling at? I have no idea. I would do a git bisect to try and narrow it down. Problem with the bisect is that I can't be sure what version it actually worked on. It certainly predates when my patch for my card was committed. I have a hunch that it might be the two tuners stomping on each other, possibly in the i2c code. Sometimes recording just stops, other times I get i2c errors. With one tuner disabled in MythTV I can't seem to reproduce the problem anymore. I haven't let it run for long enough to be sure, but it normally would have crashed by now. James
Re: buffer delivery stops with cx23885
On 09/22/2014 11:46 AM, James Harper wrote: Any hints on what I can do to figure out what layer it's stalling at? I have no idea. I would do a git bisect to try and narrow it down. Problem with the bisect is that I can't be sure what version it actually worked on. It certainly predates when my patch for my card was committed. I have a hunch that it might be the two tuners stomping on each other, possibly in the i2c code. Sometimes recording just stops, other times I get i2c errors. Is that two tuners in the same device, or two tuners in different devices? Hans With one tuner disabled in MythTV I can't seem to reproduce the problem anymore. I haven't let it run for long enough to be sure, but it normally would have crashed by now. James -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: buffer delivery stops with cx23885
Any hints on what I can do to figure out what layer it's stalling at?
I have no idea. I would do a git bisect to try and narrow it down.
Problem with the bisect is that I can't be sure what version it actually
worked on. It certainly predates when my patch for my card was committed.
I have a hunch that it might be the two tuners stomping on each other,
possibly in the i2c code. Sometimes recording just stops, other times I get
i2c
errors.
Is that two tuners in the same device, or two tuners in different devices?
DViCO FusionHDTV DVB-T Dual Express2
2 tuners on one card
James
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: buffer delivery stops with cx23885
Mauro, On 09/22/2014 11:58 AM, James Harper wrote: Any hints on what I can do to figure out what layer it's stalling at? I have no idea. I would do a git bisect to try and narrow it down. Problem with the bisect is that I can't be sure what version it actually worked on. It certainly predates when my patch for my card was committed. I have a hunch that it might be the two tuners stomping on each other, possibly in the i2c code. Sometimes recording just stops, other times I get i2c errors. Is that two tuners in the same device, or two tuners in different devices? DViCO FusionHDTV DVB-T Dual Express2 2 tuners on one card Any idea if there were changes or are issues with i2c access when there are two tuners in the same device? That's not really my expertise but you might know something about that. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: buffer delivery stops with cx23885
Is that two tuners in the same device, or two tuners in different devices?
DViCO FusionHDTV DVB-T Dual Express2
2 tuners on one card
Any idea if there were changes or are issues with i2c access when there are
two tuners in the same device?
That's not really my expertise but you might know something about that.
041ad449683bb2d54a7f082d78ec15bbc958a175 introduced stats gathering into the
dib7000p code which seems to generate a lot more i2c traffic which would
exacerbate the problem, if one existed. The timing (May/June) very roughly
matches what I remember too. When my recording stops, so do the Next all
layers stats available in... messages, although that could be for other
reasons.
Anyway, I'll comment out the call to dib7000p_get_stats and see if it makes a
difference.
James
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
RE: buffer delivery stops with cx23885
And important for me, because if it IS related to the vb2 conversion then I
need to know asap.
Might take a few days to be completely sure. I've wondered if it's something
to do with the signal too (maybe some bug when signal error occurs?). So
many variables :(
I can reasonably reliably reproduce the problem using dvbstream. strace output
below. It looks pretty much as you'd expect - poll returning normally up until
it doesn't anymore.
I'll test out the downgrade to 73d8102298719863d54264f62521362487f84256 just to
be sure, then see if I can take it further back.
James
poll([{fd=7, events=POLLIN|POLLPRI}], 1, 500) = 1 ([{fd=7,
revents=POLLIN|POLLPRI}])
accept(0, 0x712e20, [0])= -1 ENOTSOCK (Socket operation on
non-socket)
read(7,
G\v\30\37\252V\317\373\21\377\35\265\6\200Z\200\34\24\342\337bw\237\265\314,:!`\n\370\4...,
188) = 188
write(3,
G\v\30\37\252V\317\373\21\377\35\265\6\200Z\200\34\24\342\337bw\237\265\314,:!`\n\370\4...,
188) = 188
poll([{fd=7, events=POLLIN|POLLPRI}], 1, 500) = 1 ([{fd=7,
revents=POLLIN|POLLPRI}])
accept(0, 0x712e20, [0])= -1 ENOTSOCK (Socket operation on
non-socket)
read(7,
G\v\30\20\f0n!\200\301\10)@),\261\241\330\242\213\376\f\345\223\21\202@N\2b\224i...,
188) = 188
write(3,
G\v\30\20\f0n!\200\301\10)@),\261\241\330\242\213\376\f\345\223\21\202@N\2b\224i...,
188) = 188
poll([{fd=7, events=POLLIN|POLLPRI}], 1, 500) = 1 ([{fd=7,
revents=POLLIN|POLLPRI}])
accept(0, 0x712e20, [0])= -1 ENOTSOCK (Socket operation on
non-socket)
read(7,
G\v\30\21%\35]\356\rv\372+\0222\34\233\312v,\230\371\363\204s\205RQ\334\243\21\337\223...,
188) = 188
write(3,
G\v\30\21%\35]\356\rv\372+\0222\34\233\312v,\230\371\363\204s\205RQ\334\243\21\337\223...,
188) = 188
poll([{fd=7, events=POLLIN|POLLPRI}], 1, 500) = 0 (Timeout)
accept(0, 0x712e20, [0])= -1 ENOTSOCK (Socket operation on
non-socket)
read(7, 0x77145120, 188)= -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=7, events=POLLIN|POLLPRI}], 1, 500) = 0 (Timeout)
accept(0, 0x712e20, [0])= -1 ENOTSOCK (Socket operation on
non-socket)
read(7, 0x77145120, 188)= -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=7, events=POLLIN|POLLPRI}], 1, 500) = 0 (Timeout)
accept(0, 0x712e20, [0])= -1 ENOTSOCK (Socket operation on
non-socket)
Re: buffer delivery stops with cx23885
On 09/20/2014 05:32 AM, James Harper wrote: My cx23885 based DViCO FusionHDTV DVB-T Dual Express2 (I submitted a patch for this a little while ago) has been working great but over the last few months it has started playing up. Nothing has really changed that I can put my finger on. Basically mythtv stops recording after a few minutes sometimes. Rarely when this happens I see some i2c errors but mostly not. With cx23885 debug options turned on (debug=9 vbi_debug=9 v4l_debug=9 video_debug=9 irq_debug=9 ci_dbg=9) it seems like the card just stops delivering buffers (see dmesg output following). If I stop mythtv, all the buffers are cancelled (cx23885_stop_dma()) etc, and then restarting mythtv will get the recording going again, for a short time (minutes). Any suggestions to where I could start looking? Is it possible that my card itself is broken? (apart from this it's flawless). I see nothing wrong in the log, but you can try to use the current media_tree code. The cx23885's DMA engine has effectively been rewritten there, simplifying the control flow. See here for instructions on how to get and install that code: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers Regards, Hans James root@server:~# dmesg [ 3552.057910] cx23885[0]: vida_status: 0x vida_mask: 0x count: 0x0 [ 3552.057912] cx23885[0]: audint_status: 0x audint_mask: 0x count: 0x0 [ 3552.057913] cx23885[0]: ts1_status: 0x ts1_mask: 0x count: 0x24ee [ 3552.057915] cx23885[0]: ts2_status: 0x ts2_mask: 0x count: 0xc7f [ 3552.057948] cx23885[0]: cx23885_buf_prepare: 880052abd800 [ 3552.057954] cx23885[0]: [880052abd800/30] cx23885_buf_queue - append to active [ 3552.066217] cx23885[0]: pci_status: 0xc004 pci_mask: 0x1f06 [ 3552.066220] cx23885[0]: vida_status: 0x vida_mask: 0x count: 0x0 [ 3552.066222] cx23885[0]: audint_status: 0x audint_mask: 0x count: 0x0 [ 3552.066223] cx23885[0]: ts1_status: 0x ts1_mask: 0x count: 0x24ee [ 3552.066225] cx23885[0]: ts2_status: 0x0001 ts2_mask: 0x count: 0xc80 [ 3552.066227] cx23885[0]: (PCI_MSK_VID_C 0x0004) [ 3552.066228] cx23885[0]: (RISCI10x0001) [ 3552.066232] cx23885[0]: [8800c29a9000/31] wakeup reg=3200 buf=3200 [ 3552.066260] cx23885[0]: pci_status: 0x4000 pci_mask: 0x1f06 [ 3552.066262] cx23885[0]: vida_status: 0x vida_mask: 0x count: 0x0 [ 3552.066264] cx23885[0]: audint_status: 0x audint_mask: 0x count: 0x0 [ 3552.066266] cx23885[0]: ts1_status: 0x ts1_mask: 0x count: 0x24ee [ 3552.066268] cx23885[0]: ts2_status: 0x ts2_mask: 0x count: 0xc80 [ 3552.066270] cx23885[0]: cx23885_buf_prepare: 8800c29a9000 [ 3552.066274] cx23885[0]: [8800c29a9000/31] cx23885_buf_queue - append to active [ 3552.074568] cx23885[0]: pci_status: 0xc004 pci_mask: 0x1f06 [ 3552.074570] cx23885[0]: vida_status: 0x vida_mask: 0x count: 0x0 [ 3552.074572] cx23885[0]: audint_status: 0x audint_mask: 0x count: 0x0 [ 3552.074574] cx23885[0]: ts1_status: 0x ts1_mask: 0x count: 0x24ee [ 3552.074576] cx23885[0]: ts2_status: 0x0001 ts2_mask: 0x count: 0xc81 [ 3552.074577] cx23885[0]: (PCI_MSK_VID_C 0x0004) [ 3552.074579] cx23885[0]: (RISCI10x0001) [ 3552.074582] cx23885[0]: [88004c829c00/0] wakeup reg=3201 buf=3201 [ 3552.074609] cx23885[0]: pci_status: 0x4000 pci_mask: 0x1f06 [ 3552.074611] cx23885[0]: vida_status: 0x vida_mask: 0x count: 0x0 [ 3552.074613] cx23885[0]: audint_status: 0x audint_mask: 0x count: 0x0 [ 3552.074615] cx23885[0]: ts1_status: 0x ts1_mask: 0x count: 0x24ee [ 3552.074617] cx23885[0]: ts2_status: 0x ts2_mask: 0x count: 0xc81 [ 3552.074649] cx23885[0]: cx23885_buf_prepare: 88004c829c00 [ 3552.074653] cx23885[0]: [88004c829c00/0] cx23885_buf_queue - append to active [ 3552.082919] cx23885[0]: pci_status: 0xc004 pci_mask: 0x1f06 [ 3552.082922] cx23885[0]: vida_status: 0x vida_mask: 0x count: 0x0 [ 3552.082924] cx23885[0]: audint_status: 0x audint_mask: 0x count: 0x0 [ 3552.082925] cx23885[0]: ts1_status: 0x ts1_mask: 0x count: 0x24ee [ 3552.082927] cx23885[0]: ts2_status: 0x0001 ts2_mask: 0x count: 0xc82 [ 3552.082929] cx23885[0]: (PCI_MSK_VID_C 0x0004) [ 3552.082930] cx23885[0]: (RISCI10x0001) [ 3552.082934] cx23885[0]: [88004282a800/1] wakeup reg=3202 buf=3202 [ 3552.082962] cx23885[0]: pci_status: 0x4000 pci_mask: 0x1f06 [ 3552.082965] cx23885[0]: vida_status: 0x vida_mask: 0x
RE: buffer delivery stops with cx23885
On 09/20/2014 05:32 AM, James Harper wrote: My cx23885 based DViCO FusionHDTV DVB-T Dual Express2 (I submitted a patch for this a little while ago) has been working great but over the last few months it has started playing up. Nothing has really changed that I can put my finger on. Basically mythtv stops recording after a few minutes sometimes. Rarely when this happens I see some i2c errors but mostly not. With cx23885 debug options turned on (debug=9 vbi_debug=9 v4l_debug=9 video_debug=9 irq_debug=9 ci_dbg=9) it seems like the card just stops delivering buffers (see dmesg output following). If I stop mythtv, all the buffers are cancelled (cx23885_stop_dma()) etc, and then restarting mythtv will get the recording going again, for a short time (minutes). Any suggestions to where I could start looking? Is it possible that my card itself is broken? (apart from this it's flawless). I see nothing wrong in the log, but you can try to use the current media_tree code. The cx23885's DMA engine has effectively been rewritten there, simplifying the control flow. Oops I should have mentioned that. I'm using Debian Jessie with 3.16 kernel and already using the latest v4l as per link you sent (my DViCO FusionHDTV DVB-T Dual Express2 patch is in 3.17 I think, but that's not in Debian yet). I think it only broke since the rewrite. Before that it seemed to be bulletproof. That was why I asked about the patch just before - I can't tell yet if the driver stops supplying data or if mythtv stops asking for data. If there was something funny about the poll loop then that could cause it. I suppose I can try and go back to an older version of the code and see what happens? Would the bug fixed by your fix VBI/poll regression patch cause intermittent stalls, or would the application that relied on the missing behaviour simply not work at all? In any case I've just applied the patch and about to reboot. Thanks James
Re: buffer delivery stops with cx23885
Em Sat, 20 Sep 2014 09:26:23 + James Harper ja...@ejbdigital.com.au escreveu: On 09/20/2014 05:32 AM, James Harper wrote: My cx23885 based DViCO FusionHDTV DVB-T Dual Express2 (I submitted a patch for this a little while ago) has been working great but over the last few months it has started playing up. Nothing has really changed that I can put my finger on. Basically mythtv stops recording after a few minutes sometimes. Rarely when this happens I see some i2c errors but mostly not. With cx23885 debug options turned on (debug=9 vbi_debug=9 v4l_debug=9 video_debug=9 irq_debug=9 ci_dbg=9) it seems like the card just stops delivering buffers (see dmesg output following). Well, running the driver with all debugs enabled is a bad idea. The printk mechanism on the Kernel is synchronous (currently - there are some proposals to change it), so it will cause delays. That's specially bad if you're using a serial console (not sure if this is your case). If I stop mythtv, all the buffers are cancelled (cx23885_stop_dma()) etc, and then restarting mythtv will get the recording going again, for a short time (minutes). Any suggestions to where I could start looking? Is it possible that my card itself is broken? (apart from this it's flawless). I see nothing wrong in the log, but you can try to use the current media_tree code. The cx23885's DMA engine has effectively been rewritten there, simplifying the control flow. Oops I should have mentioned that. I'm using Debian Jessie with 3.16 kernel and already using the latest v4l as per link you sent (my DViCO FusionHDTV DVB-T Dual Express2 patch is in 3.17 I think, but that's not in Debian yet). I think it only broke since the rewrite. Before that it seemed to be bulletproof. That was why I asked about the patch just before - I can't tell yet if the driver stops supplying data or if mythtv stops asking for data. If there was something funny about the poll loop then that could cause it. I suppose I can try and go back to an older version of the code and see what happens? Would the bug fixed by your fix VBI/poll regression patch cause intermittent stalls, or would the application that relied on the missing behaviour simply not work at all? Yes, it may affect. In any case I've just applied the patch and about to reboot. Thanks James -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: buffer delivery stops with cx23885
On 09/20/2014 11:26 AM, James Harper wrote: On 09/20/2014 05:32 AM, James Harper wrote: My cx23885 based DViCO FusionHDTV DVB-T Dual Express2 (I submitted a patch for this a little while ago) has been working great but over the last few months it has started playing up. Nothing has really changed that I can put my finger on. Basically mythtv stops recording after a few minutes sometimes. Rarely when this happens I see some i2c errors but mostly not. With cx23885 debug options turned on (debug=9 vbi_debug=9 v4l_debug=9 video_debug=9 irq_debug=9 ci_dbg=9) it seems like the card just stops delivering buffers (see dmesg output following). If I stop mythtv, all the buffers are cancelled (cx23885_stop_dma()) etc, and then restarting mythtv will get the recording going again, for a short time (minutes). Any suggestions to where I could start looking? Is it possible that my card itself is broken? (apart from this it's flawless). I see nothing wrong in the log, but you can try to use the current media_tree code. The cx23885's DMA engine has effectively been rewritten there, simplifying the control flow. Oops I should have mentioned that. I'm using Debian Jessie with 3.16 kernel and already using the latest v4l as per link you sent (my DViCO FusionHDTV DVB-T Dual Express2 patch is in 3.17 I think, but that's not in Debian yet). Ah, yes, that's rather important information :-) I'll try to reproduce it. How often does it happen? I've setup a test where I just keep streaming to see if I can reproduce it. I think it only broke since the rewrite. Before that it seemed to be bulletproof. That was why I asked about the patch just before - I can't tell yet if the driver stops supplying data or if mythtv stops asking for data. If there was something funny about the poll loop then that could cause it. I suppose I can try and go back to an older version of the code and see what happens? Can you test with the media_tree.git master branch, but going back to commit 73d8102298719863d54264f62521362487f84256? That has the cx23885 that has not yet been converted to vb2. Test with that for a while to see if that works without problems. Then go back to the HEAD of the master branch and try again. If it breaks, then I may have to revert the cx23885 vb2 changes until I figure out what's wrong. Regards, Hans Would the bug fixed by your fix VBI/poll regression patch cause intermittent stalls, or would the application that relied on the missing behaviour simply not work at all? In any case I've just applied the patch and about to reboot. Thanks James -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: buffer delivery stops with cx23885
Oops I should have mentioned that. I'm using Debian Jessie with 3.16 kernel and already using the latest v4l as per link you sent (my DViCO FusionHDTV DVB-T Dual Express2 patch is in 3.17 I think, but that's not in Debian yet). Ah, yes, that's rather important information :-) I'll try to reproduce it. How often does it happen? I've setup a test where I just keep streaming to see if I can reproduce it. Happens within 5 minutes some nights (and reliably within 1 minute when I was testing with all the printk turned on), then not for hours other nights. Right now it hasn't crashed since I applied the VBI/poll regression patch (my kids are recording a few movies so I think I'd be in trouble if I tinkered with it any more tonight :) That's a fairly common pattern though - plays up when the kids are recording their afternoon shows when they get home from school, but then is often fairly stable after around 8pm when movies start. I can't really make sense of it. Someone mentioned seeing a few oddities when mythtv was busy downloading EIT guide but I can see when that happens and there isn't a correlation. I think it only broke since the rewrite. Before that it seemed to be bulletproof. That was why I asked about the patch just before - I can't tell yet if the driver stops supplying data or if mythtv stops asking for data. If there was something funny about the poll loop then that could cause it. I suppose I can try and go back to an older version of the code and see what happens? Can you test with the media_tree.git master branch, but going back to commit 73d8102298719863d54264f62521362487f84256? That has the cx23885 that has not yet been converted to vb2. Test with that for a while to see if that works without problems. Then go back to the HEAD of the master branch and try again. If it breaks, then I may have to revert the cx23885 vb2 changes until I figure out what's wrong. I was looking through the patches and saw a date of August 14 on the cx23885 to vb2 patch and thought that could have been around when it started breaking, but then the 73d8102298719863d54264f62521362487f84256 is dated September 3 and I'm pretty sure it had started playing up before then. About what date would I have seen the 453afdd9ce33293f640e84dc17e5f366701516e8 cx23885: convert to vb2 patch? In any case it should be easy enough to revert and build so I'll do that tomorrow once I can prove it still fails with the current regression patch applied. Thanks for your time! James
Re: buffer delivery stops with cx23885
On 09/20/2014 12:30 PM, James Harper wrote: Oops I should have mentioned that. I'm using Debian Jessie with 3.16 kernel and already using the latest v4l as per link you sent (my DViCO FusionHDTV DVB-T Dual Express2 patch is in 3.17 I think, but that's not in Debian yet). Ah, yes, that's rather important information :-) I'll try to reproduce it. How often does it happen? I've setup a test where I just keep streaming to see if I can reproduce it. Happens within 5 minutes some nights (and reliably within 1 minute when I was testing with all the printk turned on), then not for hours other nights. Right now it hasn't crashed since I applied the VBI/poll regression patch (my kids are recording a few movies so I think I'd be in trouble if I tinkered with it any more tonight :) That's a fairly common pattern though - plays up when the kids are recording their afternoon shows when they get home from school, but then is often fairly stable after around 8pm when movies start. I can't really make sense of it. Someone mentioned seeing a few oddities when mythtv was busy downloading EIT guide but I can see when that happens and there isn't a correlation. I think it only broke since the rewrite. Before that it seemed to be bulletproof. That was why I asked about the patch just before - I can't tell yet if the driver stops supplying data or if mythtv stops asking for data. If there was something funny about the poll loop then that could cause it. I suppose I can try and go back to an older version of the code and see what happens? Can you test with the media_tree.git master branch, but going back to commit 73d8102298719863d54264f62521362487f84256? That has the cx23885 that has not yet been converted to vb2. Test with that for a while to see if that works without problems. Then go back to the HEAD of the master branch and try again. If it breaks, then I may have to revert the cx23885 vb2 changes until I figure out what's wrong. I was looking through the patches and saw a date of August 14 on the cx23885 to vb2 patch and thought that could have been around when it started breaking, but then the 73d8102298719863d54264f62521362487f84256 is dated September 3 and I'm pretty sure it had started playing up before then. About what date would I have seen the 453afdd9ce33293f640e84dc17e5f366701516e8 cx23885: convert to vb2 patch? That patch was merged in the master branch September 8. If you've seen it earlier, then it may not be related to vb2 after all. If it is polling related, then it might be commit 9241650d62f79a3da01f1d5e8ebd195083330b75 (Don't return POLLERR during transient buffer underruns) which was added to the master branch on July 17th and was merged for 3.17. Or it could be something entirely different. You could try reverting that commit and see if that helps. In any case it should be easy enough to revert and build so I'll do that tomorrow once I can prove it still fails with the current regression patch applied. Which patch are you using? There have been several versions posted. This is the one you should use: https://patchwork.linuxtv.org/patch/25992/ Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: buffer delivery stops with cx23885
On 09/20/2014 01:05 PM, James Harper wrote: I was looking through the patches and saw a date of August 14 on the cx23885 to vb2 patch and thought that could have been around when it started breaking, but then the 73d8102298719863d54264f62521362487f84256 is dated September 3 and I'm pretty sure it had started playing up before then. About what date would I have seen the 453afdd9ce33293f640e84dc17e5f366701516e8 cx23885: convert to vb2 patch? That patch was merged in the master branch September 8. If you've seen it earlier, then it may not be related to vb2 after all. I'd say not. If it is polling related, then it might be commit 9241650d62f79a3da01f1d5e8ebd195083330b75 (Don't return POLLERR during transient buffer underruns) which was added to the master branch on July 17th and was merged for 3.17. Or it could be something entirely different. You could try reverting that commit and see if that helps. That sounds plausible wrt timeframe, but if cx23885 only started using vb2 after Sept 8 then it couldn't have affected me before then right? You are right about that. You are using DVB right? Not analog video? (Just to be 100% certain). In any case it should be easy enough to revert and build so I'll do that tomorrow once I can prove it still fails with the current regression patch applied. Which patch are you using? There have been several versions posted. This is the one you should use: https://patchwork.linuxtv.org/patch/25992/ That's the one I applied - you can even see my questions below in that link :) Based on what you have said I think that's not going to solve anything for me though. If you are streaming DVB, then that patch has no effect since the vb2_poll call will never be called for DVB anyway, so that can be ruled out. So I guess my plan is: . Revert to 73d8102298719863d54264f62521362487f84256 and test (not likely to fix but easy to test) And important for me, because if it IS related to the vb2 conversion then I need to know asap. My own streaming test is still running strong (not using MythTV BTW). . Revert to sometime around June when I submitted my patch for Fusion Dual Express 2 driver when I know it was reliable and test Other possibilities are: . MythTV bug . Defective card Time to google a command line dvb stream to rule out mythtv I guess... Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: buffer delivery stops with cx23885
I was looking through the patches and saw a date of August 14 on the cx23885 to vb2 patch and thought that could have been around when it started breaking, but then the 73d8102298719863d54264f62521362487f84256 is dated September 3 and I'm pretty sure it had started playing up before then. About what date would I have seen the 453afdd9ce33293f640e84dc17e5f366701516e8 cx23885: convert to vb2 patch? That patch was merged in the master branch September 8. If you've seen it earlier, then it may not be related to vb2 after all. I'd say not. If it is polling related, then it might be commit 9241650d62f79a3da01f1d5e8ebd195083330b75 (Don't return POLLERR during transient buffer underruns) which was added to the master branch on July 17th and was merged for 3.17. Or it could be something entirely different. You could try reverting that commit and see if that helps. That sounds plausible wrt timeframe, but if cx23885 only started using vb2 after Sept 8 then it couldn't have affected me before then right? In any case it should be easy enough to revert and build so I'll do that tomorrow once I can prove it still fails with the current regression patch applied. Which patch are you using? There have been several versions posted. This is the one you should use: https://patchwork.linuxtv.org/patch/25992/ That's the one I applied - you can even see my questions below in that link :) Based on what you have said I think that's not going to solve anything for me though. So I guess my plan is: . Revert to 73d8102298719863d54264f62521362487f84256 and test (not likely to fix but easy to test) . Revert to sometime around June when I submitted my patch for Fusion Dual Express 2 driver when I know it was reliable and test Other possibilities are: . MythTV bug . Defective card Time to google a command line dvb stream to rule out mythtv I guess... Thanks James
RE: buffer delivery stops with cx23885
That sounds plausible wrt timeframe, but if cx23885 only started using vb2 after Sept 8 then it couldn't have affected me before then right? You are right about that. You are using DVB right? Not analog video? (Just to be 100% certain). Yes. Australia mostly has no analog anymore. That's the one I applied - you can even see my questions below in that link :) Based on what you have said I think that's not going to solve anything for me though. If you are streaming DVB, then that patch has no effect since the vb2_poll call will never be called for DVB anyway, so that can be ruled out. Ok So I guess my plan is: . Revert to 73d8102298719863d54264f62521362487f84256 and test (not likely to fix but easy to test) And important for me, because if it IS related to the vb2 conversion then I need to know asap. Might take a few days to be completely sure. I've wondered if it's something to do with the signal too (maybe some bug when signal error occurs?). So many variables :( James
