Re: [GIT PULL FOR v3.5] Move sta2x11_vip to staging
Any news on this? Hi Hans, I'm on it :) -- Federico Vaga -- 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 1/3] adv7180: add support to user controls
If you could do that work, then that would be much appreciated. You have the hardware, after all, so that makes it easier for you. Hi Hans, I'll submit a patch for the control framework on the ADV7180 -- Federico Vaga -- 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: pctv452e
On 07/08/2012 02:07 AM, Marx wrote: W dniu 2012-07-07 02:00, Antti Palosaari pisze: I don't know what can i do next. Get the rid of vdr and use only szap/vlc/mplayer only to see if it works. This computer is remote headless without any GUI, but ok - I'll do my best (that's why I use VDR - I can using streamdev play it on local PC). And install latest patch from here: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/pctv452e it just ignores the I2C error coming from wrong I2C address used which could have some effect for STB6100 driver. Patch works as expected - no more I2C errors in error log. Very nice. Lacking GUI I tried to save stream on HDD. wuwek:~# szap -n 51 -r reading channels from file '/root/.szap/channels.conf' zapping to 51 'Mango 24;TVN': sat 0, frequency = 11393 MHz V, symbolrate 2750, vpid = 0x0205, apid = 0x02bc sid = 0x0245 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 1f | signal 01ce | snr 0095 | ber | unc fffe | FE_HAS_LOCK status 1f | signal 01ce | snr 0094 | ber | unc fffe | FE_HAS_LOCK status 1f | signal 01ce | snr 0094 | ber | unc fffe | FE_HAS_LOCK wuwek:~# ls /dev/dvb/adapter0/ demux0 dvr0 frontend0 net0 wuwek:~# cat /dev/dvb/adapter0/dvr0 /mnt/video/test.ts ^C wuwek:~# ls -l /mnt/video/test.ts -rw-r--r-- 1 root root 0 lip 8 00:37 /mnt/video/test.ts wuwek:~# dvbdate dvbdate: Unable to get time from multiplex. wuwek:~# dvbtraffic dvbdemux_set_pid_filter: Invalid argument I've tried to tune many different channels (log at the end), it works for many of them, some (all HD) doesn't work. I've used szap-s2 because szap doesn't work with DVB-S2 channels. For DVB-S channels szap produces results the same as szap-s2. I've tried to save some different channels (as above) but none saved anything, so there is still something wrong with this driver. Marx I suspect you stopped szap ? You cannot use dvbdate or dvbtraffic, nor read data from dvr0 unless frontend is tuned. Leave szap running backround and try again. regards Antti kern.log: Jul 8 00:16:29 wuwek kernel: [6.001815] input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci:00/:00:01.1/sound/card0/input3 Jul 8 00:16:29 wuwek kernel: [6.066989] usb 1-4: dvb_usbv2: found a 'PCTV HDTV USB' in warm state Jul 8 00:16:29 wuwek kernel: [6.067002] pctv452e_power_ctrl: 1 Jul 8 00:16:29 wuwek kernel: [6.067007] pctv452e_power_ctrl: step 1 Jul 8 00:16:29 wuwek kernel: [6.067012] pctv452e_power_ctrl: step 2 Jul 8 00:16:29 wuwek kernel: [6.067559] pctv452e_power_ctrl: step 3 Jul 8 00:16:29 wuwek kernel: [6.067684] usbcore: registered new interface driver dvb_usb_pctv452e Jul 8 00:16:29 wuwek kernel: [6.067745] pctv452e_power_ctrl: step 4 Jul 8 00:16:29 wuwek kernel: [6.067996] pctv452e_power_ctrl: step 5 Jul 8 00:16:29 wuwek kernel: [6.068113] usb 1-4: dvb_usbv2: will pass the complete MPEG2 transport stream to the software demuxer Jul 8 00:16:29 wuwek kernel: [6.068175] DVB: registering new adapter (PCTV HDTV USB) Jul 8 00:16:29 wuwek kernel: [6.117522] input: HDA ATI SB Line as /devices/pci:00/:00:14.2/sound/card1/input4 Jul 8 00:16:29 wuwek kernel: [6.117730] input: HDA ATI SB Rear Mic as /devices/pci:00/:00:14.2/sound/card1/input5 Jul 8 00:16:29 wuwek kernel: [6.118330] input: HDA ATI SB Line Out CLFE as /devices/pci:00/:00:14.2/sound/card1/input6 Jul 8 00:16:29 wuwek kernel: [6.118482] input: HDA ATI SB Line Out Surround as /devices/pci:00/:00:14.2/sound/card1/input7 Jul 8 00:16:29 wuwek kernel: [6.121096] input: HDA ATI SB Line Out Front as /devices/pci:00/:00:14.2/sound/card1/input8 Jul 8 00:16:29 wuwek kernel: [6.157236] stb0899_attach: Attaching STB0899 Jul 8 00:16:29 wuwek kernel: [6.182361] DVB: registering adapter 0 frontend 0 (STB0899 Multistandard)... Jul 8 00:16:29 wuwek kernel: [6.209194] stb6100_attach: Attaching STB6100 Jul 8 00:16:29 wuwek kernel: [6.209208] pctv452e_power_ctrl: 0 Jul 8 00:16:29 wuwek kernel: [6.209224] usb 1-4: dvb_usbv2: 'PCTV HDTV USB' successfully initialized and connected Jul 8 00:16:29 wuwek kernel: [7.998317] Adding 2097148k swap on /dev/sda2. Priority:-1 extents:1 across:2097148k (...) Jul 8 00:16:49 wuwek kernel: [ 58.654218] pctv452e_power_ctrl: 1 Jul 8 00:16:49 wuwek kernel: [ 58.654229] pctv452e_power_ctrl: step 1 Jul 8 00:27:05 wuwek kernel: [ 674.833814] pctv452e_power_ctrl: 0 Jul 8 00:27:30 wuwek kernel: [ 699.336350] pctv452e_power_ctrl: 1 Jul 8 00:27:30 wuwek kernel: [ 699.336363] pctv452e_power_ctrl: step 1 Jul 8 00:28:08 wuwek kernel: [ 737.552961] pctv452e_power_ctrl: 0 wuwek:/var/lib/vdr/kanaly# ./szap-s2 -n 2 -x -r reading channels from file '/root/.szap/channels.conf' zapping to 2 'TVN Turbo;TVN': delivery DVB-S, modulation QPSK sat 0, frequency 11393 MHz V, symbolrate 2750, coderate 5/6,
Re: WinTV-Duet
Ok - well using twoflower all works fine. However, using luggage (or the latest dvBlast) I get: [0x8f123cc] dvb access debug: Opening device /dev/dvb/adapter2/frontend0 [0x8f123cc] dvb access debug: Frontend Info: [0x8f123cc] dvb access debug: name = DiBcom 7000PC [0x8f123cc] dvb access debug: type = OFDM (DVB-T) [0x8f123cc] dvb access debug: frequency_min = 4500 (kHz) [0x8f123cc] dvb access debug: frequency_max = 86000 (kHz) [0x8f123cc] dvb access debug: frequency_stepsize = 62500 [0x8f123cc] dvb access debug: frequency_tolerance = 0 [0x8f123cc] dvb access debug: symbol_rate_min = 0 (kHz) [0x8f123cc] dvb access debug: symbol_rate_max = 0 (kHz) [0x8f123cc] dvb access debug: symbol_rate_tolerance (ppm) = 0 [0x8f123cc] dvb access debug: notifier_delay (ms) = 0 [0x8f123cc] dvb access debug: Frontend Info capability list: [0x8f123cc] dvb access debug: inversion auto [0x8f123cc] dvb access debug: forward error correction 1/2 [0x8f123cc] dvb access debug: forward error correction 2/3 [0x8f123cc] dvb access debug: forward error correction 3/4 [0x8f123cc] dvb access debug: forward error correction 5/6 [0x8f123cc] dvb access debug: forward error correction 7/8 [0x8f123cc] dvb access debug: forward error correction auto [0x8f123cc] dvb access debug: card can do QPSK [0x8f123cc] dvb access debug: card can do QAM 16 [0x8f123cc] dvb access debug: card can do QAM 64 [0x8f123cc] dvb access debug: card can do QAM auto [0x8f123cc] dvb access debug: transmission mode auto [0x8f123cc] dvb access debug: guard interval mode auto [0x8f123cc] dvb access debug: hierarchy mode auto [0x8f123cc] dvb access debug: card can recover from a cable unplug [0x8f123cc] dvb access debug: End of capability list [0x8f123cc] dvb access debug: trying to tune the frontend... [0x8f123cc] dvb access debug: using inversion=2 [0x8f123cc] dvb access debug: using bandwidth=8 [0x8f123cc] dvb access debug: using fec=9 [0x8f123cc] dvb access debug: using fec=9 [0x8f123cc] dvb access debug: using transmission=8 [0x8f123cc] dvb access debug: using guard=32 [0x8f123cc] dvb access debug: using hierarchy=-1 [0x8f123cc] dvb access debug: Opening device /dev/dvb/adapter2/dvr0 [0x9053b24] main input debug: TIMER input launching for '5 USA' : 23006.206 ms - Total 23006.206 ms / 1 intvls (Avg 23006.205 ms) [0x8f123cc] dvb access debug: setting filter on PAT [0x8f123cc] dvb access debug: Opening device /dev/dvb/adapter2/demux0 [0x8f123cc] dvb access debug: DMXSetFilter: DMX_PES_OTHER for PID 0 [0x8f123cc] dvb access debug: Opening device /dev/dvb/adapter2/ca0 [0x8f123cc] dvb access warning: CAMInit: opening CAM device failed (No such file or directory) [0x8f123cc] main access debug: using access module dvb [0x8f123cc] main access debug: TIMER module_need() : 6.304 ms - Total 6.304 ms / 1 intvls (Avg 6.304 ms) [0x8d54964] main stream debug: Using AStream*Block [0x8d54964] main stream debug: pre buffering [0x8d1568c] qt4 interface debug: IM: Setting an input [0x8f123cc] dvb access debug: frontend has acquired signal [0x8f123cc] dvb access debug: frontend has acquired carrier [0x8f123cc] dvb access debug: frontend has acquired stable FEC [0x8f123cc] dvb access debug: frontend has acquired sync [0x8f123cc] dvb access debug: frontend has acquired lock [0x8f123cc] dvb access debug: - Bit error rate: 0 [0x8f123cc] dvb access debug: - Signal strength: 39285 [0x8f123cc] dvb access debug: - SNR: 232 Which all looks fine - except that no video results (on my desktop). Laptox running Ubuntu 10.01 is fine. The only obvious difference between these two cases is that trhe desktop has a hauppauge nova-t 500 OCI card already installed...not sure if that could interfere somehow? As I say, now all working in twoflower, but if anyone has any thoughts on what caused the initial problem they would be welcome. On Sat, Jul 7, 2012 at 10:40 PM, Ben Barker b...@bbarker.co.uk wrote: well It looks like this is a diversity card, which seems to be a way of combining the two tuners, and is not supported on linux. The fact I can use one, or the other, but not both of the tuners makes this sound like a likely culprit. But all the documentation I can find seems to suggest this not being supported merely means you cant combine the tuners - but can still run fine with 2. I wonder if in this case I can't uncombine them...and how I could check if diversity mode is on or off... On Sat, Jul 7, 2012 at 8:27 PM, Ben Barker b...@bbarker.co.uk wrote: Firstly, let me apologise if this is not an appropriate place to ask what is not really a development question... I have been playing around with the Hauppauge WinTV Duet dual USB tuner today. dmesg seems happy when it is connected, and detects it as two devices This: http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-Duet-HD-Stick Suggests the device may be supported, though the HD vestion does not seem to exist as far as I can tell. I can run scan to get a channels list from the device no problem, and whilst VLC will
Re: video: USB webcam fails since kernel 3.2
2012/6/17 Martin-Éric Racine martin-eric.rac...@iki.fi: pe, 2012-06-15 kello 23:41 -0500, Jonathan Nieder kirjoitti: Martin-Éric Racine wrote: usb 1-7: new high-speed USB device number 3 using ehci_hcd [...] usb 1-7: New USB device found, idVendor=0ac8, idProduct=0321 usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-7: Product: USB2.0 Web Camera usb 1-7: Manufacturer: Vimicro Corp. [...] Linux media interface: v0.10 Linux video capture interface: v2.00 gspca_main: v2.14.0 registered gspca_main: vc032x-2.14.0 probing 0ac8:0321 usbcore: registered new interface driver vc032x The device of interest is discovered. gspca_main: ISOC data error: [36] len=0, status=-71 gspca_main: ISOC data error: [65] len=0, status=-71 [...] gspca_main: ISOC data error: [48] len=0, status=-71 video_source:sr[3246]: segfault at 0 ip (null) sp ab36de1c error 14 in cheese[8048000+21000] gspca_main: ISOC data error: [17] len=0, status=-71 (The above data error spew starts around t=121 seconds and continues at a rate of about 15 messages per second. The segfault is around t=154.) The vc032x code hasn't changed since 3.4.1, so please report your symptoms to Jean-François Moine moin...@free.fr, cc-ing linux-media@vger.kernel.org, linux-ker...@vger.kernel.org, and either me or this bug log so we can track it. Be sure to mention: - steps to reproduce, expected result, actual result, and how the difference indicates a bug (should be simple enough in this case) 1. Ensure that user 'myself' is a member of the 'video' group. 2. Launch the webcam application Cheese from the GNOME desktop. Expected result: Cheese displays whatever this laptop's camera sees. Actual result: Cheese crashes while attempting to access the camera. - how reproducible the bug is (100%?) 100% - which kernel versions you have tested and result with each (what is the newest kernel version that worked?) It probably was 3.1.0 or some earlier 3.2 release (the upcoming Debian will release with 3.2.x; 3.4 was only used here for testing purposes), but I wouldn't know for sure since I don't use my webcam too often. I finally found time to perform further testing, using kernel packages from snapshots.debian.org, and the last one that positively worked (at least using GNOME's webcam application Cheese) was: linux-image-3.1.0-1-686-pae 3.1.8-2 Linux 3.1 for modern PCs This loaded the following video modules: gspca_vc032x gspca_main videodev media Tests using 3.2.1-1 or more recent crashed as described before. This at least gives us a time frame for when the regression started. Martin-Éric -- 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
[regression 3.4-3.5, bisected] kernel oops when starting capturing from gspca-sn9c20x webcams
Hi, running kernel 3.5.rc6 with the two gspca-sn9c20x webcams 0c45:62b3 Microdia PC Camera with Microphone (SN9C202 + OV9655) 0c45:6270 Microdia PC Camera (SN9C201 + MI0360/MT9V011 or MI0360SOC/MT9V111) U-CAM PC Camera NE878, Whitcom WHC017, ... I'm getting the following kernel oops when I start capturing with qv4l2 (and also Kopete and others): [ 81.719973] gspca_sn9c20x: Set 640x480 [ 81.736805] BUG: unable to handle kernel NULL pointer dereference at 002c [ 81.736877] IP: [f7aebb59] v4l2_ctrl_g_ctrl+0x9/0x50 [videodev] [ 81.736901] *pdpt = 2c4fa001 *pde = [ 81.736922] Oops: [#1] PREEMPT SMP [ 81.737055] [ 81.737071] Pid: 4026, comm: qv4l2 Not tainted 3.4.0-0.1-desktop+ #19 System manufacturer System Product Name/M2N-VM DH [ 81.737101] EIP: 0060:[f7aebb59] EFLAGS: 00010292 CPU: 1 [ 81.737130] EIP is at v4l2_ctrl_g_ctrl+0x9/0x50 [videodev] [ 81.737147] EAX: EBX: ECX: f6c000c0 EDX: 0001 [ 81.737165] ESI: 0028 EDI: 0028 EBP: f5af9c84 ESP: f5af9c7c [ 81.737183] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 81.737200] CR0: 80050033 CR2: 002c CR3: 2c941000 CR4: 07f0 [ 81.737219] DR0: DR1: DR2: DR3: [ 81.737236] DR6: 0ff0 DR7: 0400 [ 81.737252] Process qv4l2 (pid: 4026, ti=f5af8000 task=f594c030 task.ti=f5af8000) [ 81.737271] Stack: [ 81.737290] 0028 f61c2000 f5af9cd0 f7d1c74c 007f f5af9ca4 c0586ba1 [ 81.737318] ef190444 007f 0080 01e0 0280 0002 02000100 [ 81.737346] 003c2800 00f000a0 f61c2000 f5af9d84 f7b682c0 f71d8bec [ 81.737366] Call Trace: [ 81.737390] [f7d1c74c] sd_start+0x2dc/0x450 [gspca_sn9c20x] [ 81.737421] [c0586ba1] ? usb_alloc_coherent+0x21/0x30 [ 81.737448] [f7b682c0] gspca_init_transfer+0x260/0x420 [gspca_main] [ 81.737479] [c02ea322] ? __alloc_pages_nodemask+0x142/0x7b0 [ 81.737504] [f7b6926b] vidioc_streamon+0x9b/0xb0 [gspca_main] [ 81.737535] [f7ae4919] __video_do_ioctl+0x2ba9/0x5780 [videodev] [ 81.737565] [c031b7ee] ? alloc_pages_current+0x8e/0x100 [ 81.737588] [c0230998] ? kmap_atomic_prot+0xe8/0x110 [ 81.737611] [c04824ea] ? __copy_from_user_ll+0x1a/0x30 [ 81.737630] [c0482530] ? _copy_from_user+0x30/0x50 [ 81.737656] [f7ae1b0e] video_usercopy+0x1de/0x270 [videodev] [ 81.737679] [c0309fc8] ? mmap_region+0x1e8/0x4b0 [ 81.737706] [f7ae1bb2] video_ioctl2+0x12/0x20 [videodev] [ 81.737725] [f7ae1d70] ? v4l2_norm_to_name+0x50/0x50 [videodev] [ 81.737725] [f7ae064a] v4l2_ioctl+0xca/0x190 [videodev] [ 81.737725] [c030a401] ? do_mmap_pgoff+0x171/0x2e0 [ 81.737725] [f7ae0580] ? v4l2_open+0x120/0x120 [videodev] [ 81.737725] [c0344074] do_vfs_ioctl+0x74/0x2e0 [ 81.737725] [c0344347] sys_ioctl+0x67/0x80 [ 81.737725] [c07242dd] syscall_call+0x7/0xb [ 81.737725] Code: 55 f0 89 02 8b 46 10 8b 40 14 e8 03 61 c3 c8 89 f8 83 c4 04 5b 5e 5f 5d c3 89 f6 8d bc 27 00 00 00 00 55 89 e5 53 89 c3 83 ec 04 8b 40 2c c7 45 f8 00 00 00 00 8d 50 fb 83 fa 02 77 09 80 b8 d3 [ 81.737725] EIP: [f7aebb59] v4l2_ctrl_g_ctrl+0x9/0x50 [videodev] SS:ESP 0068:f5af9c7c [ 81.737725] CR2: 002c [ 81.743027] ---[ end trace 1c291740d69b151f ]--- This is a regression from kernel 3.4.x. The causing commit seems to be commit 63069da1c8ef0abcdb74b0ea1c461d23fb9181d9 Author: Hans Verkuil hans.verk...@cisco.com Date: Sun May 6 09:28:29 2012 -0300 [media] gcpca_sn9c20x: Convert to the control framework HdG: Small fix: don't register some controls for sensors which don't have an implementation for them. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans de Goede hdego...@redhat.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Should I open a bug report at bugzilla, too ? Regards, Frank Schäfer -- 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sun Jul 8 19:00:20 CEST 2012 git hash:b7e386360922a15f943b2fbe8d77a19bb86f2e6f gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: ERRORS linux-3.4-x86_64: ERRORS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: ERRORS linux-3.4-i686: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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: [regression 3.4-3.5, bisected] kernel oops when starting capturing from gspca-sn9c20x webcams
Hi, Thanks for reporting this! On 07/08/2012 06:25 PM, Frank Schäfer wrote: Hi, running kernel 3.5.rc6 with the two gspca-sn9c20x webcams 0c45:62b3 Microdia PC Camera with Microphone (SN9C202 + OV9655) 0c45:6270 Microdia PC Camera (SN9C201 + MI0360/MT9V011 or MI0360SOC/MT9V111) U-CAM PC Camera NE878, Whitcom WHC017, ... I'm getting the following kernel oops when I start capturing with qv4l2 (and also Kopete and others): [ 81.719973] gspca_sn9c20x: Set 640x480 [ 81.736805] BUG: unable to handle kernel NULL pointer dereference at 002c [ 81.736877] IP: [f7aebb59] v4l2_ctrl_g_ctrl+0x9/0x50 [videodev] [ 81.736901] *pdpt = 2c4fa001 *pde = [ 81.736922] Oops: [#1] PREEMPT SMP [ 81.737055] [ 81.737071] Pid: 4026, comm: qv4l2 Not tainted 3.4.0-0.1-desktop+ #19 System manufacturer System Product Name/M2N-VM DH [ 81.737101] EIP: 0060:[f7aebb59] EFLAGS: 00010292 CPU: 1 [ 81.737130] EIP is at v4l2_ctrl_g_ctrl+0x9/0x50 [videodev] [ 81.737147] EAX: EBX: ECX: f6c000c0 EDX: 0001 [ 81.737165] ESI: 0028 EDI: 0028 EBP: f5af9c84 ESP: f5af9c7c [ 81.737183] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 81.737200] CR0: 80050033 CR2: 002c CR3: 2c941000 CR4: 07f0 [ 81.737219] DR0: DR1: DR2: DR3: [ 81.737236] DR6: 0ff0 DR7: 0400 [ 81.737252] Process qv4l2 (pid: 4026, ti=f5af8000 task=f594c030 task.ti=f5af8000) [ 81.737271] Stack: [ 81.737290] 0028 f61c2000 f5af9cd0 f7d1c74c 007f f5af9ca4 c0586ba1 [ 81.737318] ef190444 007f 0080 01e0 0280 0002 02000100 [ 81.737346] 003c2800 00f000a0 f61c2000 f5af9d84 f7b682c0 f71d8bec [ 81.737366] Call Trace: [ 81.737390] [f7d1c74c] sd_start+0x2dc/0x450 [gspca_sn9c20x] [ 81.737421] [c0586ba1] ? usb_alloc_coherent+0x21/0x30 [ 81.737448] [f7b682c0] gspca_init_transfer+0x260/0x420 [gspca_main] [ 81.737479] [c02ea322] ? __alloc_pages_nodemask+0x142/0x7b0 [ 81.737504] [f7b6926b] vidioc_streamon+0x9b/0xb0 [gspca_main] [ 81.737535] [f7ae4919] __video_do_ioctl+0x2ba9/0x5780 [videodev] [ 81.737565] [c031b7ee] ? alloc_pages_current+0x8e/0x100 [ 81.737588] [c0230998] ? kmap_atomic_prot+0xe8/0x110 [ 81.737611] [c04824ea] ? __copy_from_user_ll+0x1a/0x30 [ 81.737630] [c0482530] ? _copy_from_user+0x30/0x50 [ 81.737656] [f7ae1b0e] video_usercopy+0x1de/0x270 [videodev] [ 81.737679] [c0309fc8] ? mmap_region+0x1e8/0x4b0 [ 81.737706] [f7ae1bb2] video_ioctl2+0x12/0x20 [videodev] [ 81.737725] [f7ae1d70] ? v4l2_norm_to_name+0x50/0x50 [videodev] [ 81.737725] [f7ae064a] v4l2_ioctl+0xca/0x190 [videodev] [ 81.737725] [c030a401] ? do_mmap_pgoff+0x171/0x2e0 [ 81.737725] [f7ae0580] ? v4l2_open+0x120/0x120 [videodev] [ 81.737725] [c0344074] do_vfs_ioctl+0x74/0x2e0 [ 81.737725] [c0344347] sys_ioctl+0x67/0x80 [ 81.737725] [c07242dd] syscall_call+0x7/0xb [ 81.737725] Code: 55 f0 89 02 8b 46 10 8b 40 14 e8 03 61 c3 c8 89 f8 83 c4 04 5b 5e 5f 5d c3 89 f6 8d bc 27 00 00 00 00 55 89 e5 53 89 c3 83 ec 04 8b 40 2c c7 45 f8 00 00 00 00 8d 50 fb 83 fa 02 77 09 80 b8 d3 [ 81.737725] EIP: [f7aebb59] v4l2_ctrl_g_ctrl+0x9/0x50 [videodev] SS:ESP 0068:f5af9c7c [ 81.737725] CR2: 002c [ 81.743027] ---[ end trace 1c291740d69b151f ]--- This is a regression from kernel 3.4.x. The causing commit seems to be commit 63069da1c8ef0abcdb74b0ea1c461d23fb9181d9 Author: Hans Verkuil hans.verk...@cisco.com Date: Sun May 6 09:28:29 2012 -0300 [media] gcpca_sn9c20x: Convert to the control framework HdG: Small fix: don't register some controls for sensors which don't have an implementation for them. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans de Goede hdego...@redhat.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Should I open a bug report at bugzilla, too ? That won't be necessary, the attached patch should fix this, can you give it a try please? Thanks, Hans From e3d5933cf00270768b202041adf463ffc4fc9544 Mon Sep 17 00:00:00 2001 From: Hans de Goede hdego...@redhat.com Date: Sun, 8 Jul 2012 19:41:14 +0200 Subject: [PATCH] gspca_sn9c20x: Fix NULL pointer dereference MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Don't call v4l2_ctrl_g_ctrl on ctrls which the model cam in question does not have. Reported-by: Frank Schäfer fschaefer@googlemail.com Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/media/video/gspca/sn9c20x.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/media/video/gspca/sn9c20x.c b/drivers/media/video/gspca/sn9c20x.c index 6c31e46..b9c6f17 100644 --- a/drivers/media/video/gspca/sn9c20x.c +++ b/drivers/media/video/gspca/sn9c20x.c @@ -2070,10 +2070,13 @@ static int sd_start(struct gspca_dev *gspca_dev) set_gamma(gspca_dev, v4l2_ctrl_g_ctrl(sd-gamma));
Re: video: USB webcam fails since kernel 3.2
Hi, On 07/08/2012 03:01 PM, Martin-Éric Racine wrote: 2012/6/17 Martin-Éric Racine martin-eric.rac...@iki.fi: pe, 2012-06-15 kello 23:41 -0500, Jonathan Nieder kirjoitti: Martin-Éric Racine wrote: usb 1-7: new high-speed USB device number 3 using ehci_hcd [...] usb 1-7: New USB device found, idVendor=0ac8, idProduct=0321 usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-7: Product: USB2.0 Web Camera usb 1-7: Manufacturer: Vimicro Corp. [...] Linux media interface: v0.10 Linux video capture interface: v2.00 gspca_main: v2.14.0 registered gspca_main: vc032x-2.14.0 probing 0ac8:0321 usbcore: registered new interface driver vc032x The device of interest is discovered. gspca_main: ISOC data error: [36] len=0, status=-71 gspca_main: ISOC data error: [65] len=0, status=-71 [...] gspca_main: ISOC data error: [48] len=0, status=-71 video_source:sr[3246]: segfault at 0 ip (null) sp ab36de1c error 14 in cheese[8048000+21000] gspca_main: ISOC data error: [17] len=0, status=-71 (The above data error spew starts around t=121 seconds and continues at a rate of about 15 messages per second. The segfault is around t=154.) The vc032x code hasn't changed since 3.4.1, so please report your symptoms to Jean-François Moine moin...@free.fr, cc-ing linux-media@vger.kernel.org, linux-ker...@vger.kernel.org, and either me or this bug log so we can track it. Be sure to mention: - steps to reproduce, expected result, actual result, and how the difference indicates a bug (should be simple enough in this case) 1. Ensure that user 'myself' is a member of the 'video' group. 2. Launch the webcam application Cheese from the GNOME desktop. Expected result: Cheese displays whatever this laptop's camera sees. Actual result: Cheese crashes while attempting to access the camera. - how reproducible the bug is (100%?) 100% - which kernel versions you have tested and result with each (what is the newest kernel version that worked?) It probably was 3.1.0 or some earlier 3.2 release (the upcoming Debian will release with 3.2.x; 3.4 was only used here for testing purposes), but I wouldn't know for sure since I don't use my webcam too often. I finally found time to perform further testing, using kernel packages from snapshots.debian.org, and the last one that positively worked (at least using GNOME's webcam application Cheese) was: linux-image-3.1.0-1-686-pae 3.1.8-2 Linux 3.1 for modern PCs This loaded the following video modules: gspca_vc032x gspca_main videodev media Tests using 3.2.1-1 or more recent crashed as described before. This at least gives us a time frame for when the regression started. Hmm, this is then likely caused by the new isoc bandwidth negotiation code in 3.2, unfortunately the vc032x driver is one of the few gspca drivers for which I don't have a cam to test with. Can you try to build your own kernel from source? Boot into your own kernel, and verify the regression is still there, then edit drivers/media/video/gspca/gspca.c and go to the which_bandwidth function, and at the beginning of this function add the following line: return 2000 * 2000 * 120; Then rebuild and re-install the kernel and try again. If that helps, remove the added return 2000 * 2000 * 120; line, and also remove the following lines from which_bandwidth: /* if the image is compressed, estimate its mean size */ if (!gspca_dev-cam.needs_full_bandwidth bandwidth gspca_dev-cam.cam_mode[i].width * gspca_dev-cam.cam_mode[i].height) bandwidth = bandwidth * 3 / 8; /* 0.375 */ And try again if things still work this way. Once you've tested this I can try to write a fix for this. 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: video: USB webcam fails since kernel 3.2
On Sun, 08 Jul 2012 19:58:08 +0200 Hans de Goede hdego...@redhat.com wrote: Hmm, this is then likely caused by the new isoc bandwidth negotiation code in 3.2, unfortunately the vc032x driver is one of the few gspca drivers for which I don't have a cam to test with. Can you try to build your own kernel from source? Hi Martin-Éric, Instead of re-building the gspca driver from a kernel source, you may try the gspca test tarball from my web site http://moinejf.free.fr/gspca-2.15.18.tar.gz It contains most of the bug fixes, including the one about the bandwidth problem. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 3.4-3.5, bisected] kernel oops when starting capturing from gspca-sn9c20x webcams
Am 08.07.2012 19:43, schrieb Hans de Goede: Hi, Thanks for reporting this! On 07/08/2012 06:25 PM, Frank Schäfer wrote: Hi, running kernel 3.5.rc6 with the two gspca-sn9c20x webcams 0c45:62b3 Microdia PC Camera with Microphone (SN9C202 + OV9655) 0c45:6270 Microdia PC Camera (SN9C201 + MI0360/MT9V011 or MI0360SOC/MT9V111) U-CAM PC Camera NE878, Whitcom WHC017, ... I'm getting the following kernel oops when I start capturing with qv4l2 (and also Kopete and others): [ 81.719973] gspca_sn9c20x: Set 640x480 [ 81.736805] BUG: unable to handle kernel NULL pointer dereference at 002c [ 81.736877] IP: [f7aebb59] v4l2_ctrl_g_ctrl+0x9/0x50 [videodev] [ 81.736901] *pdpt = 2c4fa001 *pde = [ 81.736922] Oops: [#1] PREEMPT SMP [ 81.737055] [ 81.737071] Pid: 4026, comm: qv4l2 Not tainted 3.4.0-0.1-desktop+ #19 System manufacturer System Product Name/M2N-VM DH [ 81.737101] EIP: 0060:[f7aebb59] EFLAGS: 00010292 CPU: 1 [ 81.737130] EIP is at v4l2_ctrl_g_ctrl+0x9/0x50 [videodev] [ 81.737147] EAX: EBX: ECX: f6c000c0 EDX: 0001 [ 81.737165] ESI: 0028 EDI: 0028 EBP: f5af9c84 ESP: f5af9c7c [ 81.737183] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 81.737200] CR0: 80050033 CR2: 002c CR3: 2c941000 CR4: 07f0 [ 81.737219] DR0: DR1: DR2: DR3: [ 81.737236] DR6: 0ff0 DR7: 0400 [ 81.737252] Process qv4l2 (pid: 4026, ti=f5af8000 task=f594c030 task.ti=f5af8000) [ 81.737271] Stack: [ 81.737290] 0028 f61c2000 f5af9cd0 f7d1c74c 007f f5af9ca4 c0586ba1 [ 81.737318] ef190444 007f 0080 01e0 0280 0002 02000100 [ 81.737346] 003c2800 00f000a0 f61c2000 f5af9d84 f7b682c0 f71d8bec [ 81.737366] Call Trace: [ 81.737390] [f7d1c74c] sd_start+0x2dc/0x450 [gspca_sn9c20x] [ 81.737421] [c0586ba1] ? usb_alloc_coherent+0x21/0x30 [ 81.737448] [f7b682c0] gspca_init_transfer+0x260/0x420 [gspca_main] [ 81.737479] [c02ea322] ? __alloc_pages_nodemask+0x142/0x7b0 [ 81.737504] [f7b6926b] vidioc_streamon+0x9b/0xb0 [gspca_main] [ 81.737535] [f7ae4919] __video_do_ioctl+0x2ba9/0x5780 [videodev] [ 81.737565] [c031b7ee] ? alloc_pages_current+0x8e/0x100 [ 81.737588] [c0230998] ? kmap_atomic_prot+0xe8/0x110 [ 81.737611] [c04824ea] ? __copy_from_user_ll+0x1a/0x30 [ 81.737630] [c0482530] ? _copy_from_user+0x30/0x50 [ 81.737656] [f7ae1b0e] video_usercopy+0x1de/0x270 [videodev] [ 81.737679] [c0309fc8] ? mmap_region+0x1e8/0x4b0 [ 81.737706] [f7ae1bb2] video_ioctl2+0x12/0x20 [videodev] [ 81.737725] [f7ae1d70] ? v4l2_norm_to_name+0x50/0x50 [videodev] [ 81.737725] [f7ae064a] v4l2_ioctl+0xca/0x190 [videodev] [ 81.737725] [c030a401] ? do_mmap_pgoff+0x171/0x2e0 [ 81.737725] [f7ae0580] ? v4l2_open+0x120/0x120 [videodev] [ 81.737725] [c0344074] do_vfs_ioctl+0x74/0x2e0 [ 81.737725] [c0344347] sys_ioctl+0x67/0x80 [ 81.737725] [c07242dd] syscall_call+0x7/0xb [ 81.737725] Code: 55 f0 89 02 8b 46 10 8b 40 14 e8 03 61 c3 c8 89 f8 83 c4 04 5b 5e 5f 5d c3 89 f6 8d bc 27 00 00 00 00 55 89 e5 53 89 c3 83 ec 04 8b 40 2c c7 45 f8 00 00 00 00 8d 50 fb 83 fa 02 77 09 80 b8 d3 [ 81.737725] EIP: [f7aebb59] v4l2_ctrl_g_ctrl+0x9/0x50 [videodev] SS:ESP 0068:f5af9c7c [ 81.737725] CR2: 002c [ 81.743027] ---[ end trace 1c291740d69b151f ]--- This is a regression from kernel 3.4.x. The causing commit seems to be commit 63069da1c8ef0abcdb74b0ea1c461d23fb9181d9 Author: Hans Verkuil hans.verk...@cisco.com Date: Sun May 6 09:28:29 2012 -0300 [media] gcpca_sn9c20x: Convert to the control framework HdG: Small fix: don't register some controls for sensors which don't have an implementation for them. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans de Goede hdego...@redhat.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Should I open a bug report at bugzilla, too ? That won't be necessary, the attached patch should fix this, can you give it a try please? Thank you Hans, I can confirm that your patch fixes the oops for both devices. Regards, Frank Thanks, 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: [media] lirc_sir: make device registration work
Hi On Monday 04 June 2012, Jarod Wilson wrote: For one, the driver device pointer needs to be filled in, or the lirc core will refuse to load the driver. And we really need to wire up all the platform_device bits. This has been tested via the lirc sourceforge tree and verified to work, been sitting there for months, finally getting around to sending it. :\ Please consider pushing this[1] patch to 3.5 and -stable (at least 3.0+ is affected, most likely everything = 2.6.37[2]). I can confirm bug - and this patch fixing it on 3.4.4: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A smsc_superio_flat(): fir: 0x230, sir: 0x2f8, dma: 03, irq: 3, mode: 0x0e smsc_ircc_present: can't get sir_base of 0x2f8 […] lirc_dev: IR Remote Control driver registered, major 251 lirc_sir: module is from the staging directory, the quality is unknown, you have been warned. lirc_register_driver: dev pointer not filled in! lirc_sir: init_chrdev() failed. After applying this patch lirc_sir loads find and is usable with irrecord and lirc. serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A smsc_superio_flat(): fir: 0x230, sir: 0x2f8, dma: 03, irq: 3, mode: 0x0e smsc_ircc_present: can't get sir_base of 0x2f8 […] lirc_dev: IR Remote Control driver registered, major 251 lirc_sir: module is from the staging directory, the quality is unknown, you have been warned. platform lirc_dev.0: lirc_dev: driver lirc_sir registered at minor = 0 lirc_sir: I/O port 0x02f8, IRQ 3. lirc_sir: Installed Without this patch lirc_sir can't even get loaded, the alternative would be to mark it as BROKEN for 3.6. Regards Stefan Lippers-Hollmann [1] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=4b71ca6bce8fab3d08c61bf330e781f957934ae1 http://patchwork.linuxtv.org/patch/11579/ [2] RedHat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=557210 [2.6.31.9-174.fc12.i686.PAE] Ubuntu launchpad: https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/912251 [3.0.0-12-generic] Debian BTS: http://bugs.debian.org/680762 [3.2+] -- 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
Geniatech S870 ISDB-T does not work properly on kernels above 3.2
I'm trying to install the v4l-dvb drivers on fedora 17 so I can use my ISDB-T (Geniatech/MyGica S870) usb card but I'm having some issues... this is what I did, - clean install of fedora 17. - git clone git://linuxtv.org/media_build.git - cd media_build ./build make install - reboot then the card starts to work with VLC 2.0, selecting the card as DVB-T. but other programs like w_scan/vdr/tvheadend/scandvb don't work. I'm using Fedora17 with kernel 3.4.4-5.fc17.i686 here's the dmesg output, when my card gets plugged in: http://pastebin.com/QJHrkwsS here's w_scan output, using w_scan -c BR channels.conf http://pastebin.com/pN6vRsUX * tvheadend detects my card as dvb-s sometimes. if I restart tvheadend a few times it gets detected as dvb-t (as it normally would do.) then I'm able to add the multiplexes to tvheadend's list, but tvheadend scan fails with this error: http://pastebin.com/U3YCTM6j and it also produces this message on dmesg: [ 315.447669] dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 [ 327.947746] dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 I tried to do the same thing on ubuntu 12.04 and downgrading the kernel to 3.2 fixed the problem. but I need this to work on fedora 17, so how can I fix this? -- Diego Porto Graduando em Ciência da Computação - UFPB -- 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 3/3] [media] winbond-cir: Adjust sample frequency to improve reliability
Hi David, Just to make sure something like that isn't happening, could you correct the line in wbcir_irq_rx() which currently reads: rawir.duration = US_TO_NS((irdata 0x7F) * 10); so that it reads rawir.duration = US_TO_NS(((irdata 0x7F) + 1) * 10); Sure, I have added the change. This is what my diff to mainline looks like right now: diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c index 342c2c8..6381c11 100644 --- a/drivers/media/rc/winbond-cir.c +++ b/drivers/media/rc/winbond-cir.c @@ -232,7 +232,7 @@ MODULE_PARM_DESC(invert, Invert the signal from the IR receiver); static bool txandrx; /* default = 0 */ module_param(txandrx, bool, 0444); -MODULE_PARM_DESC(invert, Allow simultaneous TX and RX); +MODULE_PARM_DESC(txandrx, Allow simultaneous TX and RX); static unsigned int wake_sc = 0x800F040C; module_param(wake_sc, uint, 0644); @@ -358,7 +358,8 @@ wbcir_irq_rx(struct wbcir_data *data, struct pnp_dev *device) if (data-rxstate == WBCIR_RXSTATE_ERROR) continue; rawir.pulse = irdata 0x80 ? false : true; - rawir.duration = US_TO_NS((irdata 0x7F) * 10); + rawir.duration = US_TO_NS(((irdata 0x7F) + 1) * 10); + printk(KERN_DEBUG %x %d %d\n, irdata, rawir.pulse, rawir.duration); ir_raw_event_store_with_filter(data-dev, rawir); } @@ -1026,6 +1027,7 @@ wbcir_probe(struct pnp_dev *device, const struct pnp_device_id *dev_id) data-dev-input_id.product = WBCIR_ID_FAMILY; data-dev-input_id.version = WBCIR_ID_CHIP; data-dev-map_name = RC_MAP_RC6_MCE; + data-dev-timeout = MS_TO_NS(100); data-dev-s_idle = wbcir_idle_rx; data-dev-s_tx_mask = wbcir_txmask; data-dev-s_tx_carrier = wbcir_txcarrier; Here is the debug output: http://ozlabs.org/~anton/winbond.log1.gz Another possibility is that the printk in the interrupt handler causes overhead...could you do a debug run without the printk in the interrupt handler? Here is the output without the printk in the interrupt handler: http://ozlabs.org/~anton/winbond.log2.gz Anton -- 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
