Re: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
On 04.02.2015 21:53, Raimonds Cicans wrote: On 04.02.2015 18:19, Hans Verkuil wrote: On 02/04/2015 05:06 PM, Jurgen Kramer wrote: Hi Hans, On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote: Raimonds and Jurgen, Can you both test with the following patch applied to the driver: Raimond, do you still see the AMD iommu faults with this patch? I have limited access to this box at workdays. I will try to test your patch tomorrow. Unfortunately I still see AMD iommu faults. Test environment: kernel: 3.18.1 (I was unable to compile drivers on kernel 3.13.10) media tree: pure main media tree + your patch test: 1) warm reboot 2) run command w_scan -fs -s S13E0 -D0c -a X where X - receiver's number Tests were run on single receiver Observations: 1) Tests were run three times on first receiver and three times on second. Only one test from three failed on first receiver. All tests failed on second receiver. 2) I have feeling that with your patch faults on first receiver appear less often but this may be pure luck or placebo. 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: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
On 04.02.2015 18:19, Hans Verkuil wrote: On 02/04/2015 05:06 PM, Jurgen Kramer wrote: Hi Hans, On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote: Raimonds and Jurgen, Can you both test with the following patch applied to the driver: Raimond, do you still see the AMD iommu faults with this patch? I have limited access to this box at workdays. I will try to test your patch tomorrow. 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: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
On 29.01.2015 14:12, Hans Verkuil wrote: On 01/29/15 12:51, Raimonds Cicans wrote: On 29.01.2015 09:33, Hans Verkuil wrote: On 01/11/2015 10:33 AM, Raimonds Cicans wrote: I contacted you because I am hit by regression caused by your commit: 453afdd [media] cx23885: convert to vb2 My system: AMD Athlon(tm) II X2 240e Processor on Asus M5A97 LE R2.0 motherboard TBS6981 card (Dual DVB-S/S2 PCIe receiver, cx23885 in kernel driver) After upgrade from kernel 3.13.10 (do not have commit) to 3.17.7 (have commit) I started receiving following IOMMU related messages: 1) AMD-Vi: Event logged [IO_PAGE_FAULT device=0a:00.0 domain=0x001d address=0x0637c000 flags=0x] where device=0a:00.0 is TBS6981 card As far as I can tell this has nothing to do with the cx23885 driver but is a bug in the amd iommu/BIOS. See e.g.: https://bbs.archlinux.org/viewtopic.php?pid=1309055 I managed to reproduce the Intel equivalent if I enable CONFIG_IOMMU_SUPPORT. Most likely due to broken BIOS/ACPI/whatever information that's read by the kernel. I would recommend disabling this kernel option. Maybe... But on other hand this did not happen on old kernel with old driver. And when I did bisection on old kernel + media tree I started to receive this message only on new driver. Was CONFIG_IOMMU_SUPPORT enabled in the old kernel? zgrep CONFIG_IOMMU_SUPPORT /proc/config.gz CONFIG_IOMMU_SUPPORT=y 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: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
On 29.01.2015 09:33, Hans Verkuil wrote: On 01/11/2015 10:33 AM, Raimonds Cicans wrote: I contacted you because I am hit by regression caused by your commit: 453afdd [media] cx23885: convert to vb2 My system: AMD Athlon(tm) II X2 240e Processor on Asus M5A97 LE R2.0 motherboard TBS6981 card (Dual DVB-S/S2 PCIe receiver, cx23885 in kernel driver) After upgrade from kernel 3.13.10 (do not have commit) to 3.17.7 (have commit) I started receiving following IOMMU related messages: 1) AMD-Vi: Event logged [IO_PAGE_FAULT device=0a:00.0 domain=0x001d address=0x0637c000 flags=0x] where device=0a:00.0 is TBS6981 card As far as I can tell this has nothing to do with the cx23885 driver but is a bug in the amd iommu/BIOS. See e.g.: https://bbs.archlinux.org/viewtopic.php?pid=1309055 I managed to reproduce the Intel equivalent if I enable CONFIG_IOMMU_SUPPORT. Most likely due to broken BIOS/ACPI/whatever information that's read by the kernel. I would recommend disabling this kernel option. Maybe... But on other hand this did not happen on old kernel with old driver. And when I did bisection on old kernel + media tree I started to receive this message only on new driver. And I can not disable this feature because then USB and LAN stop working. Ray -- 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 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 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: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
On 12.01.2015 12:55, Hans Verkuil wrote: On 01/11/2015 10:33 AM, Raimonds Cicans wrote: After upgrade from kernel 3.13.10 (do not have commit) to 3.17.7 (have commit) I started receiving following IOMMU related messages: This makes no sense. The cx23885 driver in 3.17.7 doesn't use vb2. Are you using the media_build repo perhaps to install the latest media drivers on a 3.17 kernel? Sorry for misinforming you. IMHO I saw somewhere that 453afdd was included in 3.17.0-rc_something. In last two weeks I did too much tests. As far as I remember kernel / driver combinations was following 3.13.10 built in driver - not affected 3.17.7 + https://github.com/ljalves/linux_media (media tree + few new TBS open source drivers) - affected 3.18.1 + https://github.com/ljalves/linux_media (media tree + few new TBS open source drivers) - affected 3.19.0-rc3 built in driver (+ few new TBS open source drivers injected by https://github.com/bas-t/saa716x-intree) - affected Bisection I did on pure 3.13.10 + pure media tree As you can see bug(s) are kernel version agnostic 1) AMD-Vi: Event logged [IO_PAGE_FAULT device=0a:00.0 domain=0x001d address=0x0637c000 flags=0x] where device=0a:00.0 is TBS6981 card sometimes this message was followed by storm of following messages: cx23885[0]: mpeg risc op code error This looks awfully like the bug that is fixed in commit 7675fe99d280ea83388a4382c54573c80db37cda. ... 2) [ cut here ] WARNING: CPU: 1 PID: 6946 at drivers/iommu/amd_iommu.c:2637 dma_ops_domain_unmap.part.12+0x55/0x72() CPU: 1 PID: 6946 Comm: w_scan Tainted: GW 3.19.0-rc3-myrc01 #1 Hmm, and this says 3.19-rc3. I really need to know what kernel and media drivers you are using! Look above Yesterday I did git bisect on Linux media tree (v3.13 - HEAD) and found that your commit is guilty in the first message. Try with commit 7675fe99d280ea83388a4382c54573c80db37cda. Did not help. Same errors. I think the only relevant bug is #2. Just before Christmas I found some issues with the vb2 threading code, although that was for video output streams, not video capture. But it may well be that similar problems exist for capture. I'll look at that this week or early next week. I did new checks on 3.18.2 + https://github.com/ljalves/linux_media (media tree + few new TBS open source drivers) and found strange coincidence: I did two tests in following way: started w_scan on first front-end and after 5-10 seconds on second and after some time received first bug in both tests. Than just for fun reversed order. I did two tests in following way: started w_scan on second front-end and after 5-10 seconds on first and after some time received second bug followed after some time by first bug in both tests. Then I wanted to check following sequences: 1) init first front-end - start scan on second - start scan on first 2) init second front-end - start scan on first - start scan on second By init I mean: run dvb-fe-tool -sDVBS -a0 // or -a1 But on first test of first sequence I received new bug: [ 369.295899] BUG: unable to handle kernel NULL pointer dereference at(nil) [ 369.295945] IP: [c05173df] cx23885_buf_prepare+0x8c/0xa9 [cx23885] [ 369.295989] PGD 0 [ 369.296002] Oops: [#1] SMP [ 369.296020] Modules linked in: ip6table_filter ip6_tables act_police cls_basic cls_flow cls_fw cls_u32 sch_fq_codel sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_CHECKSUM ipt_rpfilter xt_statistic xt_CT xt_realm xt_addrtype xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 ipt_ECN ipt_CLUSTERIP ipt_ah xt_set nf_nat_ftp xt_time xt_TCPMSS xt_tcpmss xt_policy xt_pkttype xt_physdev br_netfilter xt_NFQUEUE xt_NFLOG xt_mark xt_mac xt_length xt_helper xt_hashlimit xt_DSCP xt_dscp xt_CLASSIFY xt_AUDIT iptable_raw iptable_nat nf_nat_ipv4 nf_nat iptable_mangle hwmon_vid bridge stp llc ipv6 cx25840(O) snd_hda_codec_hdmi snd_usb_audio snd_hwdep uvcvideo(O) snd_usbmidi_lib videobuf2_vmalloc(O) snd_rawmidi ir_lirc_codec(O) ir_xmp_decoder(O) lirc_dev(O) ir_mce_kbd_decoder(O) ir_sharp_decoder(O) ir_sanyo_decoder(O) [ 369.296375] ir_sony_decoder(O) ir_jvc_decoder(O) ir_rc6_decoder(O) ir_rc5_decoder(O) ir_nec_decoder(O) rc_rc6_mce(O) mceusb(O) cx23885(O) tveeprom(O) cx2341x(O) tda18271(O) videobuf2_dvb(O) videobuf2_dma_sg(O) videobuf2_memops(O) videobuf2_core(O) v4l2_common(O) videodev(O) k10temp rc_core(O) microcode saa716x_core(O) dvb_core(O) cx24117(O) i2c_piix4 snd_hda_intel snd_hda_controller snd_hda_codec r8169 mii nouveau ttm drm_kms_helper [ 369.296547] CPU: 0 PID: 7016 Comm: vb2-cx23885[0] Tainted: G O 3.18.1-hardened-r1-myrc06-NOSEC #1 [ 369.296574] Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 LE R2.0, BIOS 2501 04/09/2014 [ 369.296601] task: 88020c720830 ti: 88020c720db0 task.ti: 88020c720db0 [ 369.296622] RIP: 0010:[c05173df] [c05173df
[REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
+0x199/0x296 [ 110.156628] [812a64ac] ? __sg_alloc_table+0x66/0x126 [ 110.157685] [816da71b] ? get_partial_node.isra.50+0x126/0x15b [ 110.158771] [810b6443] ? __alloc_pages_nodemask+0xf1/0x7a6 [ 110.159868] [812a64ac] ? __sg_alloc_table+0x66/0x126 [ 110.160957] [810dcf3d] ? __kmalloc+0x86/0xd5 [ 110.162056] [812a64ac] ? __sg_alloc_table+0x66/0x126 [ 110.163125] [812a6581] ? sg_kfree+0x15/0x15 [ 110.164206] [812a6708] ? sg_alloc_table+0x18/0x3b [ 110.165295] [812a6796] ? sg_alloc_table_from_pages+0x6b/0x139 [ 110.166405] [a0182599] ? vb2_dma_sg_alloc+0x178/0x1ee [videobuf2_dma_sg] [ 110.167493] [a019e97f] ? __vb2_queue_alloc+0xfb/0x33e [videobuf2_core] [ 110.168599] [a01a0fa3] ? __reqbufs+0x151/0x244 [videobuf2_core] [ 110.169717] [a01a12b8] ? __vb2_init_fileio+0xea/0x250 [videobuf2_core] [ 110.170794] [a01ab157] ? vb2_dvb_start_feed+0x7a/0x7a [videobuf2_dvb] [ 110.171921] [a01a1eb0] ? vb2_thread_start+0xa8/0x14c [videobuf2_core] [ 110.173042] [a01ab12b] ? vb2_dvb_start_feed+0x4e/0x7a [videobuf2_dvb] [ 110.174143] [a01897cb] ? dmx_section_feed_start_filtering+0xe9/0x13c [dvb_core] [ 110.175257] [a0187615] ? dvb_dmxdev_filter_start+0x226/0x301 [dvb_core] [ 110.176348] [a0187c51] ? dvb_demux_do_ioctl+0x1cc/0x4d8 [dvb_core] [ 110.177486] [a0187a85] ? dvb_dmxdev_ts_callback+0xbb/0xbb [dvb_core] [ 110.178599] [a018664e] ? dvb_usercopy+0x94/0xfc [dvb_core] [ 110.179727] [a01869b2] ? dvb_demux_ioctl+0xc/0xf [dvb_core] [ 110.180866] [810f3ac8] ? do_vfs_ioctl+0x34f/0x41a [ 110.181971] [810fb19a] ? __fd_install+0x15/0x39 [ 110.183085] [810f3bcc] ? SyS_ioctl+0x39/0x5e [ 110.184228] [816e4822] ? system_call_fastpath+0x16/0x1b [ 110.185323] Code: 43 0a 01 74 0b 48 89 ee 48 89 df e8 19 ff ff ff 48 8b 43 48 48 85 c0 74 07 5b 48 89 ef 5d ff e0 5b 5d c3 f7 c6 06 00 00 fe 74 02 0f 0b 41 56 23 35 77 f5 bc 00 41 55 41 54 81 e6 f0 3e 07 00 40 [ 110.186796] RIP [810dbe47] new_slab+0x8/0x1d3 [ 110.187983] RSP 8800b910daa0 [ 110.189218] ---[ end trace a037bdc618b75d87 ]--- which appeared much faster and often locked computer. But I can prove that second message appeared at OR after your commit. How to reproduce bug(s): requirements: computer with IOMMU (IMHO only third message can be obtained on system without IOMMU) digital TV/Sat card based on cx23885 (preferably with multiple front-ends) kernel = 3.17 or driver from linux-media tree reproducing bug(s): just run scan on all front-ends simultaneously (for example with w_scan) and wait. It take 5-15 minutes to hit bug Thank you. 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
TBS 6981 IOMMU problems
Hello. After kernel upgrade 3.13 = 3.19 I started to receive different IOMMU related problems: Problem #1: AMD-Vi: Event logged [IO_PAGE_FAULT device=08:00.0 domain=0x001c address=0x004b5000 flags=0x] Problem #2: [ cut here ] WARNING: CPU: 0 PID: 6588 at drivers/iommu/amd_iommu.c:2637 dma_ops_domain_unmap.part.12+0x4d/0x56() Modules linked in: ip6table_filter ip6_tables act_police cls_basic cls_flow cls_fw cls_u32 sch_fq_codel sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_CHECKSUM ipt_rpfilter xt_statistic xt_CT xt_realm xt_addrtype xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 ipt_ECN ipt_CLUSTERIP ipt_ah xt_set nf_nat_ftp xt_time xt_TCPMSS xt_tcpmss xt_policy xt_pkttype xt_physdev br_netfilter xt_NFQUEUE xt_NFLOG xt_mark xt_mac xt_length xt_helper xt_hashlimit xt_DSCP xt_dscp xt_CLASSIFY xt_AUDIT iptable_raw iptable_nat nf_nat_ipv4 nf_nat iptable_mangle hwmon_vid bridge stp llc ipv6 cx24117 cx25840 uvcvideo snd_usb_audio videobuf2_vmalloc snd_hwdep snd_usbmidi_lib snd_rawmidi snd_hda_codec_hdmi ir_xmp_decoder ir_lirc_codec lirc_dev ir_mce_kbd_decoder ir_sharp_decoder ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_nec_decoder ir_rc5_decoder rc_rc6_mce microcode k10temp mceusb uas usb_storage usblp si2157 si2168 saa716x_budget saa716x_core sp5100_tco i2c_piix4 nouveau cx23885 i2c_algo_bit ttm tda18271 altera_stapl videobuf2_dvb videobuf2_core videobuf2_dma_sg videobuf2_memops drm_kms_helper tveeprom cx2341x dvb_core snd_hda_intel rc_core drm v4l2_common snd_hda_controller videodev snd_hda_codec r8169 mii CPU: 0 PID: 6588 Comm: w_scan Tainted: GW 3.19.0-rc3-myrc00 #1 Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 LE R2.0, BIOS 2501 04/09/2014 0009 ab636bd8 ab0bcd91 880099d4a300 ab4e282b 0046 8800b87ccd88 023b1000 0001 01f8 Call Trace: [ab636bd8] ? dump_stack+0x40/0x50 [ab0bcd91] ? warn_slowpath_common+0x93/0xab [ab4e282b] ? dma_ops_domain_unmap.part.12+0x4d/0x56 [ab4e282b] ? dma_ops_domain_unmap.part.12+0x4d/0x56 [ab4e41d5] ? __unmap_single.isra.15+0x7b/0xcf [ab4e4983] ? free_coherent+0x46/0x7e [c046a2e7] ? __vb2_queue_cancel+0x11b/0x12d [videobuf2_core] [c046c0a2] ? __reqbufs+0xf2/0x29d [videobuf2_core] [c046c345] ? vb2_thread_stop+0x6b/0xb1 [videobuf2_core] [c04760ce] ? vb2_dvb_stop_feed+0x41/0x58 [videobuf2_dvb] [ab16b1bc] ? poll_select_copy_remaining+0xf4/0xf4 [c041e066] ? dmx_section_feed_stop_filtering+0x40/0x7b [dvb_core] [c041cb0b] ? dvb_dmxdev_ts_callback+0xc2/0xc2 [dvb_core] [c041c2bb] ? dvb_dmxdev_feed_stop+0x5d/0x89 [dvb_core] [c041cb0b] ? dvb_dmxdev_ts_callback+0xc2/0xc2 [dvb_core] [c041c401] ? dvb_dmxdev_filter_stop+0x4e/0xb6 [dvb_core] [c041cb0b] ? dvb_dmxdev_ts_callback+0xc2/0xc2 [dvb_core] [c041cc29] ? dvb_demux_do_ioctl+0x11e/0x4d8 [dvb_core] [c041cb0b] ? dvb_dmxdev_ts_callback+0xc2/0xc2 [dvb_core] [c041b66d] ? dvb_usercopy+0xa7/0x127 [dvb_core] [c0423797] ? dvb_ringbuffer_read_user+0x6d/0x8e [dvb_core] [c041bf97] ? dvb_dmxdev_buffer_read.isra.2+0x5c/0x156 [dvb_core] [ab0e0c59] ? __wake_up+0x33/0x44 [c041b9f3] ? dvb_demux_ioctl+0xd/0x11 [dvb_core] [c041b9e6] ? dvb_dvr_ioctl+0x11/0x11 [dvb_core] [ab16a8fb] ? do_vfs_ioctl+0x360/0x424 [ab0ef6fb] ? timespec_add_safe+0x1c/0x48 [ab16a9f2] ? SyS_ioctl+0x33/0x58 [ab63be92] ? system_call_fastpath+0x12/0x17 ---[ end trace a7dc5ffa658175f6 ]--- Thoughts about above problems: Hardware: AMD Athlon(tm) II X2 240e Processor on Asus M5A97 LE R2.0 motherboard This bugs cause random consequences: nothing bad happens stop working one front end stop working both front ends This bugs are easily triggered if I run /w_scan/ on both front ends simultaneously Theoretically it is possible to disable IOMMU but: it will just hide problem, not solve it some devices on my system do not work without IOMMU Theoretically it is possible that there is bug in IOMMU code itself, because I had IOMMU related regression in kernels 3.14-3.17 which was solved in 3.17.7 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
[PATCH] Fix typo in comments
Expression ((7bit i2c_addr 1) 0x01) can not be right because it is always 0 Signed-off-by: Raimonds Cicans r...@apollo.lv --- drivers/media/usb/dvb-usb/dibusb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/dvb-usb/dibusb.h b/drivers/media/usb/dvb-usb/dibusb.h index e47c321..32ab139 100644 --- a/drivers/media/usb/dvb-usb/dibusb.h +++ b/drivers/media/usb/dvb-usb/dibusb.h @@ -36,7 +36,7 @@ /* * i2c read - * bulk write: 0x02 ((7bit i2c_addr 1) 0x01) register_bytes length_word + * bulk write: 0x02 ((7bit i2c_addr 1) | 0x01) register_bytes length_word * bulk read: byte_buffer (length_word bytes) */ #define DIBUSB_REQ_I2C_READ0x02 -- 1.8.5.5 -- 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
Few questions about dibusb i2c over usb protocol
Hello. 1) As I understand format of i2c read command is following: 2, (dev_i2c_addr1)|1, addr_hi, addr_lo, size_hi, size_lo but in debug output I saw following commands: 02 a3 00 01 55 02 a3 00 04 55 00 53 00 This commands are shorter then command described above. Meaning of bytes 1, 2 and 4 is clear, but what mean third byte: if it is size_hi, then where is address? if it is addr_lo, then it is not clear why answer's first byte is 55 according to Cypress documentation first byte of program eeprom should be C2 2) What is format for i2c write command? 3, dev_i2c_addr1, addr_hi, addr_lo, data... ? 3) what mean following command 03 a2 51 3f 80 write byte 80 at address 513f? 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
Looking for Asus My Cinema U3000 (not Mini and not Hybrid) owners
Hello. I am looking for Asus My Cinema U3000 (not Mini and not Hybrid) owners. I am looking for device with USB VendorId:DeviceId = 0b05:1713 I am trying to write device driver for this device, but unfortunately I bricked mine. How can you help: 1) donate your device or 2) send me dump of device's memory chip (ATMEL 24C128N) contents Dump can be created at electronic repair shop or I can try to write dump tool or 3) sell your device 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
