Re: [PATCH] cx23885/vb2 regression: please test this patch
On Sun, 2015-01-18 at 11:40 +0100, Hans Verkuil wrote: > On 01/18/2015 09:54 AM, Jurgen Kramer wrote: > > I have been running the original code (because of issues with the patch) > > for a while with some added printks. This morning I found this NULL > > pointer derefence: > > That's what my patch fixes, so that's no surprise that you get this. > > I don't understand why you have issues with the patch, very weird. I just retested with your patch using mplayer instead of mythtv. It played for a few seconds then it froze and the mplayer process is not killable. Can you sent my your version of patched videobuf2-core.c? I had to hand patch (patch did not apply cleanly). Maybe I botched something. Regards, Jurgen > Regards, > > Hans > > > > > [47772.121968] DEBUG: vb2_thread_stop entered > > [47772.122014] BUG: unable to handle kernel NULL pointer dereference at > > (null) > > [47772.122042] vb2: counters for queue 880407ee9828: UNBALANCED! > > [47772.122043] vb2: setup: 1 start_streaming: 1 stop_streaming: 1 > > [47772.122043] vb2: wait_prepare: 249333 wait_finish: 249334 > > [47772.122083] IP: [] cx23885_buf_prepare+0x6c/0xd0 > > [cx23885] > > [47772.122102] PGD 0 > > [47772.122107] Oops: [#1] SMP > > [47772.122116] Modules linked in: cfg80211 rfkill > > nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT > > xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter > > ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 > > ip6table_mangle ip6table_security ip6table_raw ip6table_filter > > ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 > > nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) > > si2157(OE) si2168(OE) i2c_mux cx25840(OE) cx23885(OE) altera_ci(OE) > > tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) videobuf2_core(OE) > > videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq snd_seq_device snd_pcm > > snd_timer snd soundcore tveeprom(OE) cx2341x(OE) dvb_core(OE) > > rc_core(OE) v4l2_common(OE) videodev(OE) raid456 async_raid6_recov > > async_memcpy > > [47772.122321] async_pq async_xor xor async_tx raid6_pq media(OE) > > mxm_wmi intel_rapl x86_pkg_temp_thermal coretemp kvm_intel kvm serio_raw > > shpchp mei_me mei i2c_i801 crct10dif_pclmul crc32_pclmul crc32c_intel > > ghash_clmulni_intel microcode dw_dmac wmi dw_dmac_core tpm_tis tpm > > i2c_hid i2c_designware_platform i2c_designware_core acpi_pad nfsd > > auth_rpcgss nfs_acl lockd sunrpc e1000e i915 ptp pps_core i2c_algo_bit > > drm_kms_helper drm sdhci_acpi sdhci mmc_core video > > [47772.122472] CPU: 0 PID: 6151 Comm: vb2-cx23885[2] Tainted: G > > OE 3.17.8-200.fc20.x86_64 #1 > > [47772.122492] Hardware name: To Be Filled By O.E.M. To Be Filled By > > O.E.M./Z97 Extreme4, BIOS P1.50 12/17/2014 > > [47772.122523] task: 8803dcfc9d70 ti: 8803652a8000 task.ti: > > 8803652a8000 > > [47772.122549] RIP: 0010:[] [] > > cx23885_buf_prepare+0x6c/0xd0 [cx23885] > > [47772.122573] RSP: 0018:8803652abdc8 EFLAGS: 00010246 > > [47772.122585] RAX: 5e00 RBX: 880036a6d600 RCX: > > 02f0 > > [47772.122609] RDX: 5e00 RSI: 88040608a3b8 RDI: > > 8804091f3000 > > [47772.122624] RBP: 8803652abdf0 R08: 0020 R09: > > > > [47772.122649] R10: 880407ee9828 R11: 880407ee9828 R12: > > 88040608a000 > > [47772.122663] R13: 5e00 R14: 880036a6c000 R15: > > > > [47772.122677] FS: () GS:88041fa0() > > knlGS: > > [47772.122693] CS: 0010 DS: ES: CR0: 80050033 > > [47772.122705] CR2: CR3: 01c14000 CR4: > > 001407f0 > > [47772.122720] DR0: DR1: DR2: > > > > [47772.123643] DR3: DR6: fffe0ff0 DR7: > > 0400 > > [47772.124605] Stack: > > [47772.125468] 88040608a000 88040608c458 88040608a000 > > > > [47772.126350] 880407ee9828 8803652abe00 a057cd69 > > 8803652abe30 > > [47772.127230] a04f183e 5e00 880407ee9828 > > 88040608c458 > > [47772.128129] Call Trace: > > [47772.129002] [] buffer_prepare+0x19/0x20 [cx23885] > > [47772.129916] [] __buf_prepare+0x27e/0x390 > > [videobuf2_core] > > [47772.130838] [] vb2_internal_qbuf+0x6b/0x210 > > [videobuf2_core] > > [47772.131722] [] vb2_thread+0x136/0x4d0 > > [videobuf2_core] > > [47772.132642] [] ? vb2_internal_qbuf+0x210/0x210 > > [videobuf2_core] > > [47772.133527] [] kthread+0xd8/0xf0 > > [47772.134400] [] ? kthread_create_on_node > > +0x190/0x190 > > [47772.135268] [] ret_from_fork+0x7c/0xb0 > > [47772.136134] [] ? kthread_create_on_node > > +0x190/0x190 > > [47772.137058] Code: 24 60 02 00 00 85 c0 75 3e 45 85 ed 75 4d 90 8b 8b > > f0 00 00 00 49 8b be 20 01 00 00 49 8d b4 24 b8 03 00 00 44 8b 83 f4 00 > > 00
Re: [PATCH] cx23885/vb2 regression: please test this patch
On 01/18/2015 09:54 AM, Jurgen Kramer wrote: > I have been running the original code (because of issues with the patch) > for a while with some added printks. This morning I found this NULL > pointer derefence: That's what my patch fixes, so that's no surprise that you get this. I don't understand why you have issues with the patch, very weird. Regards, Hans > > [47772.121968] DEBUG: vb2_thread_stop entered > [47772.122014] BUG: unable to handle kernel NULL pointer dereference at > (null) > [47772.122042] vb2: counters for queue 880407ee9828: UNBALANCED! > [47772.122043] vb2: setup: 1 start_streaming: 1 stop_streaming: 1 > [47772.122043] vb2: wait_prepare: 249333 wait_finish: 249334 > [47772.122083] IP: [] cx23885_buf_prepare+0x6c/0xd0 > [cx23885] > [47772.122102] PGD 0 > [47772.122107] Oops: [#1] SMP > [47772.122116] Modules linked in: cfg80211 rfkill > nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT > xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter > ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 > ip6table_mangle ip6table_security ip6table_raw ip6table_filter > ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 > nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) > si2157(OE) si2168(OE) i2c_mux cx25840(OE) cx23885(OE) altera_ci(OE) > tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) videobuf2_core(OE) > videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq snd_seq_device snd_pcm > snd_timer snd soundcore tveeprom(OE) cx2341x(OE) dvb_core(OE) > rc_core(OE) v4l2_common(OE) videodev(OE) raid456 async_raid6_recov > async_memcpy > [47772.122321] async_pq async_xor xor async_tx raid6_pq media(OE) > mxm_wmi intel_rapl x86_pkg_temp_thermal coretemp kvm_intel kvm serio_raw > shpchp mei_me mei i2c_i801 crct10dif_pclmul crc32_pclmul crc32c_intel > ghash_clmulni_intel microcode dw_dmac wmi dw_dmac_core tpm_tis tpm > i2c_hid i2c_designware_platform i2c_designware_core acpi_pad nfsd > auth_rpcgss nfs_acl lockd sunrpc e1000e i915 ptp pps_core i2c_algo_bit > drm_kms_helper drm sdhci_acpi sdhci mmc_core video > [47772.122472] CPU: 0 PID: 6151 Comm: vb2-cx23885[2] Tainted: G > OE 3.17.8-200.fc20.x86_64 #1 > [47772.122492] Hardware name: To Be Filled By O.E.M. To Be Filled By > O.E.M./Z97 Extreme4, BIOS P1.50 12/17/2014 > [47772.122523] task: 8803dcfc9d70 ti: 8803652a8000 task.ti: > 8803652a8000 > [47772.122549] RIP: 0010:[] [] > cx23885_buf_prepare+0x6c/0xd0 [cx23885] > [47772.122573] RSP: 0018:8803652abdc8 EFLAGS: 00010246 > [47772.122585] RAX: 5e00 RBX: 880036a6d600 RCX: > 02f0 > [47772.122609] RDX: 5e00 RSI: 88040608a3b8 RDI: > 8804091f3000 > [47772.122624] RBP: 8803652abdf0 R08: 0020 R09: > > [47772.122649] R10: 880407ee9828 R11: 880407ee9828 R12: > 88040608a000 > [47772.122663] R13: 5e00 R14: 880036a6c000 R15: > > [47772.122677] FS: () GS:88041fa0() > knlGS: > [47772.122693] CS: 0010 DS: ES: CR0: 80050033 > [47772.122705] CR2: CR3: 01c14000 CR4: > 001407f0 > [47772.122720] DR0: DR1: DR2: > > [47772.123643] DR3: DR6: fffe0ff0 DR7: > 0400 > [47772.124605] Stack: > [47772.125468] 88040608a000 88040608c458 88040608a000 > > [47772.126350] 880407ee9828 8803652abe00 a057cd69 > 8803652abe30 > [47772.127230] a04f183e 5e00 880407ee9828 > 88040608c458 > [47772.128129] Call Trace: > [47772.129002] [] buffer_prepare+0x19/0x20 [cx23885] > [47772.129916] [] __buf_prepare+0x27e/0x390 > [videobuf2_core] > [47772.130838] [] vb2_internal_qbuf+0x6b/0x210 > [videobuf2_core] > [47772.131722] [] vb2_thread+0x136/0x4d0 > [videobuf2_core] > [47772.132642] [] ? vb2_internal_qbuf+0x210/0x210 > [videobuf2_core] > [47772.133527] [] kthread+0xd8/0xf0 > [47772.134400] [] ? kthread_create_on_node > +0x190/0x190 > [47772.135268] [] ret_from_fork+0x7c/0xb0 > [47772.136134] [] ? kthread_create_on_node > +0x190/0x190 > [47772.137058] Code: 24 60 02 00 00 85 c0 75 3e 45 85 ed 75 4d 90 8b 8b > f0 00 00 00 49 8b be 20 01 00 00 49 8d b4 24 b8 03 00 00 44 8b 83 f4 00 > 00 00 <49> 8b 17 45 31 c9 e8 c9 f0 ff ff 31 c0 5b 41 5c 41 5d 41 5e 41 > [47772.138917] RIP [] cx23885_buf_prepare+0x6c/0xd0 > [cx23885] > [47772.139841] RSP > [47772.140776] CR2: > [47772.146080] ---[ end trace 2c986045fea9fe0a ]--- > [47772.146236] DEBUG: vb2_thread_stop quit > > This happened only once normally it just prints: > [47179.170117] DEBUG: vb2_thread > [47400.670021] DEBUG: vb2_thread_stop entered > [47400.670105] DEBUG: vb2_thread_stop quit > [47401.012711] DEBUG: vb2_thread > [47456.200792] DEBUG: vb2_thread_
Re: [PATCH] cx23885/vb2 regression: please test this patch
I have been running the original code (because of issues with the patch) for a while with some added printks. This morning I found this NULL pointer derefence: [47772.121968] DEBUG: vb2_thread_stop entered [47772.122014] BUG: unable to handle kernel NULL pointer dereference at (null) [47772.122042] vb2: counters for queue 880407ee9828: UNBALANCED! [47772.122043] vb2: setup: 1 start_streaming: 1 stop_streaming: 1 [47772.122043] vb2: wait_prepare: 249333 wait_finish: 249334 [47772.122083] IP: [] cx23885_buf_prepare+0x6c/0xd0 [cx23885] [47772.122102] PGD 0 [47772.122107] Oops: [#1] SMP [47772.122116] Modules linked in: cfg80211 rfkill nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) si2157(OE) si2168(OE) i2c_mux cx25840(OE) cx23885(OE) altera_ci(OE) tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) videobuf2_core(OE) videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq snd_seq_device snd_pcm snd_timer snd soundcore tveeprom(OE) cx2341x(OE) dvb_core(OE) rc_core(OE) v4l2_common(OE) videodev(OE) raid456 async_raid6_recov async_memcpy [47772.122321] async_pq async_xor xor async_tx raid6_pq media(OE) mxm_wmi intel_rapl x86_pkg_temp_thermal coretemp kvm_intel kvm serio_raw shpchp mei_me mei i2c_i801 crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel microcode dw_dmac wmi dw_dmac_core tpm_tis tpm i2c_hid i2c_designware_platform i2c_designware_core acpi_pad nfsd auth_rpcgss nfs_acl lockd sunrpc e1000e i915 ptp pps_core i2c_algo_bit drm_kms_helper drm sdhci_acpi sdhci mmc_core video [47772.122472] CPU: 0 PID: 6151 Comm: vb2-cx23885[2] Tainted: G OE 3.17.8-200.fc20.x86_64 #1 [47772.122492] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme4, BIOS P1.50 12/17/2014 [47772.122523] task: 8803dcfc9d70 ti: 8803652a8000 task.ti: 8803652a8000 [47772.122549] RIP: 0010:[] [] cx23885_buf_prepare+0x6c/0xd0 [cx23885] [47772.122573] RSP: 0018:8803652abdc8 EFLAGS: 00010246 [47772.122585] RAX: 5e00 RBX: 880036a6d600 RCX: 02f0 [47772.122609] RDX: 5e00 RSI: 88040608a3b8 RDI: 8804091f3000 [47772.122624] RBP: 8803652abdf0 R08: 0020 R09: [47772.122649] R10: 880407ee9828 R11: 880407ee9828 R12: 88040608a000 [47772.122663] R13: 5e00 R14: 880036a6c000 R15: [47772.122677] FS: () GS:88041fa0() knlGS: [47772.122693] CS: 0010 DS: ES: CR0: 80050033 [47772.122705] CR2: CR3: 01c14000 CR4: 001407f0 [47772.122720] DR0: DR1: DR2: [47772.123643] DR3: DR6: fffe0ff0 DR7: 0400 [47772.124605] Stack: [47772.125468] 88040608a000 88040608c458 88040608a000 [47772.126350] 880407ee9828 8803652abe00 a057cd69 8803652abe30 [47772.127230] a04f183e 5e00 880407ee9828 88040608c458 [47772.128129] Call Trace: [47772.129002] [] buffer_prepare+0x19/0x20 [cx23885] [47772.129916] [] __buf_prepare+0x27e/0x390 [videobuf2_core] [47772.130838] [] vb2_internal_qbuf+0x6b/0x210 [videobuf2_core] [47772.131722] [] vb2_thread+0x136/0x4d0 [videobuf2_core] [47772.132642] [] ? vb2_internal_qbuf+0x210/0x210 [videobuf2_core] [47772.133527] [] kthread+0xd8/0xf0 [47772.134400] [] ? kthread_create_on_node +0x190/0x190 [47772.135268] [] ret_from_fork+0x7c/0xb0 [47772.136134] [] ? kthread_create_on_node +0x190/0x190 [47772.137058] Code: 24 60 02 00 00 85 c0 75 3e 45 85 ed 75 4d 90 8b 8b f0 00 00 00 49 8b be 20 01 00 00 49 8d b4 24 b8 03 00 00 44 8b 83 f4 00 00 00 <49> 8b 17 45 31 c9 e8 c9 f0 ff ff 31 c0 5b 41 5c 41 5d 41 5e 41 [47772.138917] RIP [] cx23885_buf_prepare+0x6c/0xd0 [cx23885] [47772.139841] RSP [47772.140776] CR2: [47772.146080] ---[ end trace 2c986045fea9fe0a ]--- [47772.146236] DEBUG: vb2_thread_stop quit This happened only once normally it just prints: [47179.170117] DEBUG: vb2_thread [47400.670021] DEBUG: vb2_thread_stop entered [47400.670105] DEBUG: vb2_thread_stop quit [47401.012711] DEBUG: vb2_thread [47456.200792] DEBUG: vb2_thread_stop entered [47456.200908] DEBUG: vb2_thread_stop quit [47456.544154] DEBUG: vb2_thread [47480.938606] DEBUG: vb2_thread_stop entered [47480.938711] DEBUG: vb2_thread_stop quit [47481.024019] DEBUG: vb2_thread [47708.823051] DEBUG: vb2_thread_stop entered [47708.823184] DEBUG: vb2_thread_stop quit [47709.166499] DEBUG: vb2_thread Regards, Jurgen -- To unsubscribe from this list: send the line "unsubscrib
Re: [PATCH] cx23885/vb2 regression: please test this patch
Hi Hans, I doubt that there is an issue with multiple frontends, at least not in all cases. I've got 4 DVBSky T982 adapters (2 frontends per card) runing without issues so far. They have a cx23885 and 2x si2168/2157 Regards, Tycho. Op 17-01-15 om 12:09 schreef Hans Verkuil: On 01/16/2015 08:05 PM, Raimonds Cicans wrote: On 16.01.2015 16:54, Hans Verkuil wrote: If you get the error again with a 3.18 or higher kernel and with my patch, then please copy-and-paste that message again. To be sure, I attached full dmesg. Thanks. This was with one frontend? And what was the exact sequence of commands used to replicate this? Sorry, but I need precise details of how you reproduce this, especially since I can't reproduce it. I'm pretty sure there are multiple issues here, one of them is fixed by my vb2 patch, but this page fault is almost certainly a separate problem. Based on past reports there is also a possible problem with multiple frontends, but I don't have hardware like that and even if I had I am not sure I would be able to test it properly. Besides, that issue seemed to be unrelated to the vb2 conversion. It's all pretty vague, though. 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 -- 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: [PATCH] cx23885/vb2 regression: please test this patch
On 17.01.2015 13:09, Hans Verkuil wrote: Thanks. This was with one frontend? And what was the exact sequence of commands used to replicate this? Sorry, but I need precise details of how you reproduce this, especially since I can't reproduce it. This test was run on first front end. I just started "w_scan -fs -s S13E0 -D0c -a 4" (which mean: do satellite channel scan using S13E0 initial transponder list on first DiSEqC port on adapter 4) and waited until error appeared in "dmesg --follow". It may take some time (for me in average 5-15 minutes) I'm pretty sure there are multiple issues here, one of them is fixed by my vb2 patch, but this page fault is almost certainly a separate problem. Based on past reports there is also a possible problem with multiple frontends, but I don't have hardware like that and even if I had I am not sure I would be able to test it properly. Besides, that issue seemed to be unrelated to the vb2 conversion. It's all pretty vague, though. IMHO: I also think problem is with multiple front ends, because on some usage patterns problem almost go away IMHO: page fault problem IS related to the vb2 conversion, because 1) I did not have this problem on kernel 3.13.10 2) during bisection this error appeared exactly on conversation commit Can we test multiple front ends version? Because you do not have hardware I propose to test it other way around: can you make patch which disables or ignores one front end on my hardware (TBS 6981)? Raimonds Cicans -- 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: [PATCH] cx23885/vb2 regression: please test this patch
On 01/16/2015 08:05 PM, Raimonds Cicans wrote: > On 16.01.2015 16:54, Hans Verkuil wrote: > >> If you get the error again with a 3.18 or higher kernel and with my patch, >> then please copy-and-paste that message again. > > To be sure, I attached full dmesg. Thanks. This was with one frontend? And what was the exact sequence of commands used to replicate this? Sorry, but I need precise details of how you reproduce this, especially since I can't reproduce it. I'm pretty sure there are multiple issues here, one of them is fixed by my vb2 patch, but this page fault is almost certainly a separate problem. Based on past reports there is also a possible problem with multiple frontends, but I don't have hardware like that and even if I had I am not sure I would be able to test it properly. Besides, that issue seemed to be unrelated to the vb2 conversion. It's all pretty vague, though. 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: [PATCH] cx23885/vb2 regression: please test this patch
On 01/16/2015 05:20 PM, Raimonds Cicans wrote: > On 16.01.2015 16:54, Hans Verkuil wrote: >> On 01/13/2015 06:55 PM, Raimonds Cicans wrote: >>> On 13.01.2015 16:01, Hans Verkuil wrote: Can you both test this patch? It should (I hope) solve the problems you both had with the cx23885 driver. >> Can you check that the function cx23885_risc_field in >> drivers/media/pci/cx23885/cx23885-core.c uses "sg = sg_next(sg);" >> instead of "sg++;"? > There is no sg++ in whole drivers/media/pci/cx23885/ directory. >> To avoid confusion I would prefer that you test with a 3.18 or higher kernel >> and please state which kernel version you use and whether you used the >> media_build system or a specific git repo to build the drivers. > kernel: Gentoo Hardened kernel 3.18.1 (hardened part turned off) > media_build: pure original media_build > media tree: https://github.com/ljalves/linux_media (original linux-media > plus some > new out of kernel TBS drivers (from this tree I need TBS6285 driver)) >> I'm also interested if you can reproduce it using just command-line >> tools (and let me know what it is you do). > For tests I use only command line tools: w_scan & dvb-fe-tool > > Tests: > 1) w_scan on first front end then after 5-10 seconds w_scan on other > 2) w_scan on second front end then after 5-10 seconds w_scan on first > 3) "dvb-fe-tool -d DVBS" on first front end then after 5-10 seconds > w_scan on second front end then after 5-10 seconds w_scan on first > 4) "dvb-fe-tool -d DVBS" on second front end then after 5-10 seconds > w_scan on first front end then after 5-10 seconds w_scan on second > > w_scan run on both front ends simultaneously. > > > > Use only one DVB adapter, not both. > > Do you mean one card or one front end? One frontend. 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: [PATCH] cx23885/vb2 regression: please test this patch
On 01/16/2015 05:48 PM, Luis Alves wrote: > Hans, > > There is another guy having issues with TBS8820 card (uses cx88 and cx24116) > > His syslog: > http://paste.ubuntu.com/9284564/ > > The stackdump makes me believe that the issue also appeared since > "[media] cx88: convert to vb2" > (still to confirm) He needs to upgrade to a newer media_build version. This is a cx88 bug that's fixed here: http://www.spinics.net/lists/linux-media/msg84255.html Regards, Hans > > Regards, > Luis > > > On Fri, Jan 16, 2015 at 4:20 PM, Raimonds Cicans wrote: >> On 16.01.2015 16:54, Hans Verkuil wrote: >>> >>> On 01/13/2015 06:55 PM, Raimonds Cicans wrote: On 13.01.2015 16:01, Hans Verkuil wrote: > > Can you both test this patch? It should (I hope) solve the problems you > both had with the cx23885 driver. > >>> Can you check that the function cx23885_risc_field in >>> drivers/media/pci/cx23885/cx23885-core.c uses "sg = sg_next(sg);" >>> instead of "sg++;"? >> >> There is no sg++ in whole drivers/media/pci/cx23885/ directory. >>> >>> To avoid confusion I would prefer that you test with a 3.18 or higher >>> kernel >>> and please state which kernel version you use and whether you used the >>> media_build system or a specific git repo to build the drivers. >> >> kernel: Gentoo Hardened kernel 3.18.1 (hardened part turned off) >> media_build: pure original media_build >> media tree: https://github.com/ljalves/linux_media (original linux-media >> plus some >> new out of kernel TBS drivers (from this tree I need TBS6285 driver)) >>> >>> I'm also interested if you can reproduce it using just command-line tools >>> (and let me know what it is you do). >> >> For tests I use only command line tools: w_scan & dvb-fe-tool >> >> Tests: >> 1) w_scan on first front end then after 5-10 seconds w_scan on other >> 2) w_scan on second front end then after 5-10 seconds w_scan on first >> 3) "dvb-fe-tool -d DVBS" on first front end then after 5-10 seconds w_scan >> on second front end then after 5-10 seconds w_scan on first >> 4) "dvb-fe-tool -d DVBS" on second front end then after 5-10 seconds w_scan >> on first front end then after 5-10 seconds w_scan on second >> >> w_scan run on both front ends simultaneously. >> >> >>> Use only one DVB adapter, not both. >> >> Do you mean one card or one front end? >> >> >> >> Raimonds Cicans >> >> -- >> 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 > -- > 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 > -- 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: [PATCH] cx23885/vb2 regression: please test this patch
Hans, There is another guy having issues with TBS8820 card (uses cx88 and cx24116) His syslog: http://paste.ubuntu.com/9284564/ The stackdump makes me believe that the issue also appeared since "[media] cx88: convert to vb2" (still to confirm) Regards, Luis On Fri, Jan 16, 2015 at 4:20 PM, Raimonds Cicans wrote: > On 16.01.2015 16:54, Hans Verkuil wrote: >> >> On 01/13/2015 06:55 PM, Raimonds Cicans wrote: >>> >>> On 13.01.2015 16:01, Hans Verkuil wrote: Can you both test this patch? It should (I hope) solve the problems you both had with the cx23885 driver. >> Can you check that the function cx23885_risc_field in >> drivers/media/pci/cx23885/cx23885-core.c uses "sg = sg_next(sg);" >> instead of "sg++;"? > > There is no sg++ in whole drivers/media/pci/cx23885/ directory. >> >> To avoid confusion I would prefer that you test with a 3.18 or higher >> kernel >> and please state which kernel version you use and whether you used the >> media_build system or a specific git repo to build the drivers. > > kernel: Gentoo Hardened kernel 3.18.1 (hardened part turned off) > media_build: pure original media_build > media tree: https://github.com/ljalves/linux_media (original linux-media > plus some > new out of kernel TBS drivers (from this tree I need TBS6285 driver)) >> >> I'm also interested if you can reproduce it using just command-line tools >> (and let me know what it is you do). > > For tests I use only command line tools: w_scan & dvb-fe-tool > > Tests: > 1) w_scan on first front end then after 5-10 seconds w_scan on other > 2) w_scan on second front end then after 5-10 seconds w_scan on first > 3) "dvb-fe-tool -d DVBS" on first front end then after 5-10 seconds w_scan > on second front end then after 5-10 seconds w_scan on first > 4) "dvb-fe-tool -d DVBS" on second front end then after 5-10 seconds w_scan > on first front end then after 5-10 seconds w_scan on second > > w_scan run on both front ends simultaneously. > > >> Use only one DVB adapter, not both. > > Do you mean one card or one front end? > > > > Raimonds Cicans > > -- > 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 -- 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: [PATCH] cx23885/vb2 regression: please test this patch
On Fri, 2015-01-16 at 15:58 +0100, Hans Verkuil wrote: > On 01/15/2015 05:32 PM, Jurgen Kramer wrote: > > Hi Hans, > > > > On Tue, 2015-01-13 at 17:59 +0100, Jurgen Kramer wrote: > >> Hi Hans, > >> On Tue, 2015-01-13 at 15:01 +0100, Hans Verkuil wrote: > >>> Hi Raimonds, Jurgen, > >>> > >>> Can you both test this patch? It should (I hope) solve the problems you > >>> both had with the cx23885 driver. > >>> > >>> This patch fixes a race condition in the vb2_thread that occurs when > >>> the thread is stopped. The crucial fix is calling kthread_stop much > >>> earlier in vb2_thread_stop(). But I also made the vb2_thread more > >>> robust. > >> > >> Thanks. Will test your patch and report back. > > I have tested the patch, unfortunately results are not positive. > > With the patch MythTV has issues with the tuners. Live TV no longer > > works and eventually mythbackend hangs. Reverting the patch brings > > everything back to a working state. > > Which kernel version are you using? Do you use media_build to install > the drivers or do you use a git repository? Do you see any kernel messages? I am on 3.17.7 (F20 x86-64) with current media_build (git://linuxtv.org/media_build.git) There were no kernel messages indicating failure, same goes for mythbackend. > Do you get problems with e.g. mplayer or vlc or another GUI tool as well? I have only tested it with MythTV. I'll give a w_scan and mplayer a try to see if that combo gives working TV output. Regards, Jurgen -- 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: [PATCH] cx23885/vb2 regression: please test this patch
On 16.01.2015 16:54, Hans Verkuil wrote: On 01/13/2015 06:55 PM, Raimonds Cicans wrote: On 13.01.2015 16:01, Hans Verkuil wrote: Can you both test this patch? It should (I hope) solve the problems you both had with the cx23885 driver. Can you check that the function cx23885_risc_field in drivers/media/pci/cx23885/cx23885-core.c uses "sg = sg_next(sg);" instead of "sg++;"? There is no sg++ in whole drivers/media/pci/cx23885/ directory. To avoid confusion I would prefer that you test with a 3.18 or higher kernel and please state which kernel version you use and whether you used the media_build system or a specific git repo to build the drivers. kernel: Gentoo Hardened kernel 3.18.1 (hardened part turned off) media_build: pure original media_build media tree: https://github.com/ljalves/linux_media (original linux-media plus some new out of kernel TBS drivers (from this tree I need TBS6285 driver)) I'm also interested if you can reproduce it using just command-line tools (and let me know what it is you do). For tests I use only command line tools: w_scan & dvb-fe-tool Tests: 1) w_scan on first front end then after 5-10 seconds w_scan on other 2) w_scan on second front end then after 5-10 seconds w_scan on first 3) "dvb-fe-tool -d DVBS" on first front end then after 5-10 seconds w_scan on second front end then after 5-10 seconds w_scan on first 4) "dvb-fe-tool -d DVBS" on second front end then after 5-10 seconds w_scan on first front end then after 5-10 seconds w_scan on second w_scan run on both front ends simultaneously. > Use only one DVB adapter, not both. Do you mean one card or one front end? Raimonds Cicans -- 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: [PATCH] cx23885/vb2 regression: please test this patch
On 01/15/2015 05:32 PM, Jurgen Kramer wrote: > Hi Hans, > > On Tue, 2015-01-13 at 17:59 +0100, Jurgen Kramer wrote: >> Hi Hans, >> On Tue, 2015-01-13 at 15:01 +0100, Hans Verkuil wrote: >>> Hi Raimonds, Jurgen, >>> >>> Can you both test this patch? It should (I hope) solve the problems you >>> both had with the cx23885 driver. >>> >>> This patch fixes a race condition in the vb2_thread that occurs when >>> the thread is stopped. The crucial fix is calling kthread_stop much >>> earlier in vb2_thread_stop(). But I also made the vb2_thread more >>> robust. >> >> Thanks. Will test your patch and report back. > I have tested the patch, unfortunately results are not positive. > With the patch MythTV has issues with the tuners. Live TV no longer > works and eventually mythbackend hangs. Reverting the patch brings > everything back to a working state. Which kernel version are you using? Do you use media_build to install the drivers or do you use a git repository? Do you see any kernel messages? Do you get problems with e.g. mplayer or vlc or another GUI tool as well? This doesn't really make sense to me why this would fail. Regards, Hans > > Regards, > Jurgen > >> >> >> -- >> 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 >> > > > -- > 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 > -- 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: [PATCH] cx23885/vb2 regression: please test this patch
On 01/13/2015 06:55 PM, Raimonds Cicans wrote: > On 13.01.2015 16:01, Hans Verkuil wrote: >> Hi Raimonds, Jurgen, >> >> Can you both test this patch? It should (I hope) solve the problems you >> both had with the cx23885 driver. >> >> This patch fixes a race condition in the vb2_thread that occurs when >> the thread is stopped. The crucial fix is calling kthread_stop much >> earlier in vb2_thread_stop(). But I also made the vb2_thread more >> robust. > > With this patch I am unable to get any error except first > (AMD-Vi: Event logged [IO_PAGE_FAULT...). > But I am not convinced, because before patch I get > first error much often and earlier than almost any other error, > so it may be just "bad luck" and other errors do not > appear because first error appear earlier. No, the first error and the others errors are unrelated. Can you check that the function cx23885_risc_field in drivers/media/pci/cx23885/cx23885-core.c uses "sg = sg_next(sg);" instead of "sg++;"? See also the original patch: https://patchwork.linuxtv.org/patch/27071/ To avoid confusion I would prefer that you test with a 3.18 or higher kernel and please state which kernel version you use and whether you used the media_build system or a specific git repo to build the drivers. > > BTW question about RISC engine: > what kind of memory use RISC engine to store > DMA programs (code)? Internal SRAM or host's? Internal SRAM. > I ask because "cx23885[0]: mpeg risc op code error" > error message storm after first message looks like > RISC engine used host's memory when this memory > was unmapped. That's why I need to know whether sg_next is used or not. Because if that's not the case, then that explains the error. If you get the error again with a 3.18 or higher kernel and with my patch, then please copy-and-paste that message again. I'm also interested if you can reproduce it using just command-line tools (and let me know what it is you do). Use only one DVB adapter, not both. 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: [PATCH] cx23885/vb2 regression: please test this patch
Hi Hans, On Tue, 2015-01-13 at 17:59 +0100, Jurgen Kramer wrote: > Hi Hans, > On Tue, 2015-01-13 at 15:01 +0100, Hans Verkuil wrote: > > Hi Raimonds, Jurgen, > > > > Can you both test this patch? It should (I hope) solve the problems you > > both had with the cx23885 driver. > > > > This patch fixes a race condition in the vb2_thread that occurs when > > the thread is stopped. The crucial fix is calling kthread_stop much > > earlier in vb2_thread_stop(). But I also made the vb2_thread more > > robust. > > Thanks. Will test your patch and report back. I have tested the patch, unfortunately results are not positive. With the patch MythTV has issues with the tuners. Live TV no longer works and eventually mythbackend hangs. Reverting the patch brings everything back to a working state. Regards, Jurgen > > > -- > 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 > -- 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: [PATCH] cx23885/vb2 regression: please test this patch
On 13.01.2015 19:55, Raimonds Cicans wrote: On 13.01.2015 16:01, Hans Verkuil wrote: Hi Raimonds, Jurgen, Can you both test this patch? It should (I hope) solve the problems you both had with the cx23885 driver. This patch fixes a race condition in the vb2_thread that occurs when the thread is stopped. The crucial fix is calling kthread_stop much earlier in vb2_thread_stop(). But I also made the vb2_thread more robust. With this patch I am unable to get any error except first (AMD-Vi: Event logged [IO_PAGE_FAULT...). But I am not convinced, because before patch I get first error much often and earlier than almost any other error, so it may be just "bad luck" and other errors do not appear because first error appear earlier. I noticed that if I "initialize" card with commands: /usr/bin/dvb-fe-tool -a 4 -d DVBS /usr/bin/dvb-fe-tool -a 5 -d DVBS and then run load which starts on first front-end and only after some time on second, then I receive first error much later or do not receive at all (for example I was able to run VDR whole night without problems) Raimonds Cicans -- 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: [PATCH] cx23885/vb2 regression: please test this patch
On 13.01.2015 16:01, Hans Verkuil wrote: Hi Raimonds, Jurgen, Can you both test this patch? It should (I hope) solve the problems you both had with the cx23885 driver. This patch fixes a race condition in the vb2_thread that occurs when the thread is stopped. The crucial fix is calling kthread_stop much earlier in vb2_thread_stop(). But I also made the vb2_thread more robust. With this patch I am unable to get any error except first (AMD-Vi: Event logged [IO_PAGE_FAULT...). But I am not convinced, because before patch I get first error much often and earlier than almost any other error, so it may be just "bad luck" and other errors do not appear because first error appear earlier. BTW question about RISC engine: what kind of memory use RISC engine to store DMA programs (code)? Internal SRAM or host's? I ask because "cx23885[0]: mpeg risc op code error" error message storm after first message looks like RISC engine used host's memory when this memory was unmapped. Raimonds Cicans -- 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: [PATCH] cx23885/vb2 regression: please test this patch
Hi Hans, On Tue, 2015-01-13 at 15:01 +0100, Hans Verkuil wrote: > Hi Raimonds, Jurgen, > > Can you both test this patch? It should (I hope) solve the problems you > both had with the cx23885 driver. > > This patch fixes a race condition in the vb2_thread that occurs when > the thread is stopped. The crucial fix is calling kthread_stop much > earlier in vb2_thread_stop(). But I also made the vb2_thread more > robust. Thanks. Will test your patch and report back. Regards, Jurgen -- 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
[PATCH] cx23885/vb2 regression: please test this patch
Hi Raimonds, Jurgen,
Can you both test this patch? It should (I hope) solve the problems you
both had with the cx23885 driver.
This patch fixes a race condition in the vb2_thread that occurs when
the thread is stopped. The crucial fix is calling kthread_stop much
earlier in vb2_thread_stop(). But I also made the vb2_thread more
robust.
Regards,
Hans
Signed-off-by: Hans Verkuil
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index d09a891..bc08a82 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -3146,27 +3146,26 @@ static int vb2_thread(void *data)
prequeue--;
} else {
call_void_qop(q, wait_finish, q);
- ret = vb2_internal_dqbuf(q, &fileio->b, 0);
+ if (!threadio->stop)
+ ret = vb2_internal_dqbuf(q, &fileio->b, 0);
call_void_qop(q, wait_prepare, q);
dprintk(5, "file io: vb2_dqbuf result: %d\n", ret);
}
- if (threadio->stop)
- break;
- if (ret)
+ if (ret || threadio->stop)
break;
try_to_freeze();
vb = q->bufs[fileio->b.index];
if (!(fileio->b.flags & V4L2_BUF_FLAG_ERROR))
- ret = threadio->fnc(vb, threadio->priv);
- if (ret)
- break;
+ if (threadio->fnc(vb, threadio->priv))
+ break;
call_void_qop(q, wait_finish, q);
if (set_timestamp)
v4l2_get_timestamp(&fileio->b.timestamp);
- ret = vb2_internal_qbuf(q, &fileio->b);
+ if (!threadio->stop)
+ ret = vb2_internal_qbuf(q, &fileio->b);
call_void_qop(q, wait_prepare, q);
- if (ret)
+ if (ret || threadio->stop)
break;
}
@@ -3235,11 +3234,11 @@ int vb2_thread_stop(struct vb2_queue *q)
threadio->stop = true;
vb2_internal_streamoff(q, q->type);
call_void_qop(q, wait_prepare, q);
+ err = kthread_stop(threadio->thread);
q->fileio = NULL;
fileio->req.count = 0;
vb2_reqbufs(q, &fileio->req);
kfree(fileio);
- err = kthread_stop(threadio->thread);
threadio->thread = NULL;
kfree(threadio);
q->fileio = NULL;
--
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
