dvb bug
With recent kernels I get system freeze when running with the following hardware: Intel DX58S02 motherboard Xeon W5520 cpu Hauppauge HVR-1700 PCIe DVB-T Technisat SkyStar2 DVB-T PCI card If I run either DVB-T card on its own then everything is ok. Or if I run both cards on different motherboard and cpu then everything is ok. So seems to related to DX58S02 and/or CPU and/or some timing issue. But with both dvb cards and debug kernel, I get: ? printk + 14/18 valid_state + 131/144 mark_lock + f2/1e1 ? check_usage_backwards + 0/65 __lock_acquire + 2dc/b91 ? sched_clock + 9/d ? sched_clock_cpu + 46/13b ? trace_hardirqs_off + b/d ? cpu_clock + 3b/53 lock_acquire + 93/b1 ? dvb_dmx_swfilter + 26/104 _spin_lock + 23/53 ? dvb_dmx_swfilter + 26/104 dvb_dmx_swfilter + 26/104 videobuf_dvb_thread + b3/135 ? videobuf_dvb_thread + 0/135 kthread + 64/69 ? kthread + 0/69 kernel_thread_helper + 7/10 And at that point everything freezes (the INFO printk wasn't visible on screen but I would have thought that this should have just been an informative trace and not something which would cause system to freeze). Without debug kernel I get either system freeze or other oops. And if there is any oops then the cx23885 module is always in the trace. The user space application runs as two completely seperate instances and opens two completely (supposedly) independent devices. Can anybody make sense of the trace and point out what exactly is happening? -- 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: [linux-dvb] [bug] AF9015 message WARNING: tuning failed!!!
On 11/23/2010 10:11 PM, Paul Gover wrote: On Wednesday 06 October 2010 22:29:35 Antti Palosaari wrote: On 10/06/2010 11:36 PM, dave cunningham wrote: In message4cacd0f3.6030...@iki.fi, Antti Palosaari wrote It is QT1010 tuner driver issue. None is working for that currently or in near future. Feel free to fix :] The wiki appears to show this stick as working. http://linuxtv.org/wiki/index.php/Afatech_AF9015. Is this information incorrect or is it hit and miss depending on the host system? It works but performance is poor. Usually it locks when RF signal is weak. If you fix bug around line 381 in qt1010.c it will work much better. But if you fix that it will break devices zl10353+qt1010 since zl10353 driver misses AGC configuration. Antti Antti, I took a look at qt1010.c, but didn't see what the bug was. I was hoping to see a FIXME or BUG or some comment; any comment ;-) Look this, I think it does have that fixed. http://linuxtv.org/hg/~anttip/qt1010/ But then I went back to my traces. They said my AF9015 detected an MT2060 tuner, not a QT1010. Does this mean the QT1010 comment was wrong? The detection code that said so looks to be part of the AF9015/9013 support, maybe they use the same code. Whatever, you will know, and I certainly don't. The tuner code certainly uses the QT1010 driver and not the MT2060 driver, if I understood the traces correctly. You surely misunderstand something now. Look your first post: Quantek QT1010 successfully identified. FWIW, I think you are right about AGC; when Kaffeine scans for channels, it gives a few fleeting signal levels about 50% but fails to identify anything. My previous DVB-T stick, different older chip, produced 100% signal solidly, and Kaffeine identified more than 80 channels. I think this bug renders the AF9015 in this configuration virtually useless in Linux; the signal is enough for the Windoze tuner bloatware supplied with it to find all the channels, but not a thing in Linux. Sorry for coming back on this so much later; I've been busy doing house repair. Also, I stopped following the mailing list - I was getting swamped with stuff and it seems to make yahoo break KDE PIM. If I should post this via the list, please say, and I'll start obeying the rules! Thanks in advance for any guidance. -- 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 -- http://palosaari.fi/ -- 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: [linux-dvb] [bug] AF9015 message WARNING: tuning failed!!!
On Wednesday 06 October 2010 22:29:35 Antti Palosaari wrote: On 10/06/2010 11:36 PM, dave cunningham wrote: In message 4cacd0f3.6030...@iki.fi, Antti Palosaari wrote It is QT1010 tuner driver issue. None is working for that currently or in near future. Feel free to fix :] The wiki appears to show this stick as working. http://linuxtv.org/wiki/index.php/Afatech_AF9015. Is this information incorrect or is it hit and miss depending on the host system? It works but performance is poor. Usually it locks when RF signal is weak. If you fix bug around line 381 in qt1010.c it will work much better. But if you fix that it will break devices zl10353+qt1010 since zl10353 driver misses AGC configuration. Antti Antti, I took a look at qt1010.c, but didn't see what the bug was. I was hoping to see a FIXME or BUG or some comment; any comment ;-) But then I went back to my traces. They said my AF9015 detected an MT2060 tuner, not a QT1010. Does this mean the QT1010 comment was wrong? The detection code that said so looks to be part of the AF9015/9013 support, maybe they use the same code. Whatever, you will know, and I certainly don't. The tuner code certainly uses the QT1010 driver and not the MT2060 driver, if I understood the traces correctly. FWIW, I think you are right about AGC; when Kaffeine scans for channels, it gives a few fleeting signal levels about 50% but fails to identify anything. My previous DVB-T stick, different older chip, produced 100% signal solidly, and Kaffeine identified more than 80 channels. I think this bug renders the AF9015 in this configuration virtually useless in Linux; the signal is enough for the Windoze tuner bloatware supplied with it to find all the channels, but not a thing in Linux. Sorry for coming back on this so much later; I've been busy doing house repair. Also, I stopped following the mailing list - I was getting swamped with stuff and it seems to make yahoo break KDE PIM. If I should post this via the list, please say, and I'll start obeying the rules! Thanks in advance for any guidance. -- 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
[linux-dvb] [bug] AF9015 message WARNING: tuning failed!!!
I've a cheap USB DVB key that won't work with Kaffeine. It identifies itself as KWorld USB DVB-T TV Stick II (VS-DVB-T 395U). It shows up on Kaffeine's Configure Television dialog, but scanning for channels finds nothing, and tuning using an old channel list gives Sorry - no available device found I had Kaffeine working OK with a different USB TV key. dvbscan produces WARNING: tuning failed!!! messages. The key works on XP using KWorld's HyperMedia Center. Rebooting from there to Linux with warm USB key shows it contains 4.95.0 firmware. At one point, such a warm reboot enabled Kaffeine to show TV. That was with one of the early KDE4 Kaffeine candidates, and an older linux kernel (sorry, I forget which). Now using kernel modules in Linux version 2.6.34-gentoo-r6. Kaffeine 1.0, KDE 4.4.5. linuxtv-dvb-apps 1.1.1.20080317 on an ASUS EeePC 1000HE (Intel Atom processor). Diagnostic stuff lsusb -v : Bus 001 Device 023: ID 1b80:e396 Afatech Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1b80 Afatech idProduct 0xe396 bcdDevice2.00 iManufacturer 1 Afatech iProduct2 DVB-T 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) lsmod : Module Size Used by ppp_deflate 3156 0 zlib_deflate 17980 1 ppp_deflate zlib_inflate 14197 1 ppp_deflate bsd_comp4568 0 ppp_async 6283 1 crc_ccitt 1023 1 ppp_async ppp_generic14958 7 ppp_deflate,bsd_comp,ppp_async slhc4431 1 ppp_generic sr_mod 10825 0 cdrom 29800 1 sr_mod option 18224 1 usbserial 24352 4 option snd_seq_oss23625 0 snd_seq_midi_event 4280 1 snd_seq_oss snd_seq39723 4 snd_seq_oss,snd_seq_midi_event snd_seq_device 4109 2 snd_seq_oss,snd_seq snd_pcm_oss30331 0 snd_mixer_oss 12481 1 snd_pcm_oss snd_hda_codec_realtek 187652 1 qt1010 4461 1 snd_hda_intel 16732 2 af9013 17817 1 snd_hda_codec 42659 2 snd_hda_codec_realtek,snd_hda_intel snd_pcm50564 3 snd_pcm_oss,snd_hda_intel,snd_hda_codec dvb_usb_af9015 24963 0
Re: [linux-dvb] [bug] AF9015 message WARNING: tuning failed!!!
It is QT1010 tuner driver issue. None is working for that currently or in near future. Feel free to fix :] Antti On 10/06/2010 04:56 PM, Paul Gover wrote: I've a cheap USB DVB key that won't work with Kaffeine. It identifies itself as KWorld USB DVB-T TV Stick II (VS-DVB-T 395U). It shows up on Kaffeine's Configure Television dialog, but scanning for channels finds nothing, and tuning using an old channel list gives Sorry - no available device found I had Kaffeine working OK with a different USB TV key. dvbscan produces WARNING: tuning failed!!! messages. The key works on XP using KWorld's HyperMedia Center. Rebooting from there to Linux with warm USB key shows it contains 4.95.0 firmware. At one point, such a warm reboot enabled Kaffeine to show TV. That was with one of the early KDE4 Kaffeine candidates, and an older linux kernel (sorry, I forget which). Now using kernel modules in Linux version 2.6.34-gentoo-r6. Kaffeine 1.0, KDE 4.4.5. linuxtv-dvb-apps 1.1.1.20080317 on an ASUS EeePC 1000HE (Intel Atom processor). Diagnostic stuff lsusb -v : Bus 001 Device 023: ID 1b80:e396 Afatech Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1b80 Afatech idProduct 0xe396 bcdDevice2.00 iManufacturer 1 Afatech iProduct2 DVB-T 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) lsmod : Module Size Used by ppp_deflate 3156 0 zlib_deflate 17980 1 ppp_deflate zlib_inflate 14197 1 ppp_deflate bsd_comp4568 0 ppp_async 6283 1 crc_ccitt 1023 1 ppp_async ppp_generic14958 7 ppp_deflate,bsd_comp,ppp_async slhc4431 1 ppp_generic sr_mod 10825 0 cdrom 29800 1 sr_mod option 18224 1 usbserial 24352 4 option snd_seq_oss23625 0 snd_seq_midi_event 4280 1 snd_seq_oss snd_seq39723 4 snd_seq_oss,snd_seq_midi_event snd_seq_device 4109 2 snd_seq_oss,snd_seq snd_pcm_oss30331 0 snd_mixer_oss 12481 1 snd_pcm_oss snd_hda_codec_realtek 187652 1 qt1010 4461 1 snd_hda_intel
Re: [linux-dvb] [bug] AF9015 message WARNING: tuning failed!!!
In message 4cacd0f3.6030...@iki.fi, Antti Palosaari wrote It is QT1010 tuner driver issue. None is working for that currently or in near future. Feel free to fix :] The wiki appears to show this stick as working. http://linuxtv.org/wiki/index.php/Afatech_AF9015. Is this information incorrect or is it hit and miss depending on the host system? Thanks, David Antti On 10/06/2010 04:56 PM, Paul Gover wrote: I've a cheap USB DVB key that won't work with Kaffeine. It identifies itself as KWorld USB DVB-T TV Stick II (VS-DVB-T 395U). It shows up on Kaffeine's Configure Television dialog, but scanning for channels finds nothing, and tuning using an old channel list gives Sorry - no available device found I had Kaffeine working OK with a different USB TV key. dvbscan produces WARNING: tuning failed!!! messages. The key works on XP using KWorld's HyperMedia Center. Rebooting from there to Linux with warm USB key shows it contains 4.95.0 firmware. At one point, such a warm reboot enabled Kaffeine to show TV. That was with one of the early KDE4 Kaffeine candidates, and an older linux kernel (sorry, I forget which). Now using kernel modules in Linux version 2.6.34-gentoo-r6. Kaffeine 1.0, KDE 4.4.5. linuxtv-dvb-apps 1.1.1.20080317 on an ASUS EeePC 1000HE (Intel Atom processor). Diagnostic stuff lsusb -v : Bus 001 Device 023: ID 1b80:e396 Afatech Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1b80 Afatech idProduct 0xe396 bcdDevice2.00 iManufacturer 1 Afatech iProduct2 DVB-T 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) lsmod : Module Size Used by ppp_deflate 3156 0 zlib_deflate 17980 1 ppp_deflate zlib_inflate 14197 1 ppp_deflate bsd_comp4568 0 ppp_async 6283 1 crc_ccitt 1023 1 ppp_async ppp_generic14958 7 ppp_deflate,bsd_comp,ppp_async slhc4431 1 ppp_generic sr_mod 10825 0 cdrom 29800 1 sr_mod option 18224 1 usbserial 24352 4 option snd_seq_oss23625 0 snd_seq_midi_event 4280 1 snd_seq_oss snd_seq
Re: [linux-dvb] [bug] AF9015 message WARNING: tuning failed!!!
On 10/06/2010 11:36 PM, dave cunningham wrote: In message 4cacd0f3.6030...@iki.fi, Antti Palosaari wrote It is QT1010 tuner driver issue. None is working for that currently or in near future. Feel free to fix :] The wiki appears to show this stick as working. http://linuxtv.org/wiki/index.php/Afatech_AF9015. Is this information incorrect or is it hit and miss depending on the host system? It works but performance is poor. Usually it locks when RF signal is weak. If you fix bug around line 381 in qt1010.c it will work much better. But if you fix that it will break devices zl10353+qt1010 since zl10353 driver misses AGC configuration. Antti -- http://palosaari.fi/ -- 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
v4l-dvb bug report
Hi, I am a newbee so please be patient with me. I have followed all the instructions and I tried to compile the sources and got a lot of errors. I don't think it's my fault but i may be wrong. My system: Ubuntu 10.04 with kernel 2.6.32.22 I have the headers installed, not the full kernel source code (shouldn't be required). My dvb-t interface is an usb stick: Conceptronic CTVDIGUSB2, I believe it has an afatech chipset. Here's the output from lsusb: Bus 002 Device 007: ID 1b80:d393 Afatech I downloaded the latest v4l-dvb source from hg clone http://linuxtv.org/hg/v4l-dvb I had a look at the daily test log and I don't see any test against 2.6.32.22 Here's the output from make: t...@xxx:~/v4l-dvb$ sudo make make -C /home/teo/v4l-dvb/v4l make[1]: Entering directory `/home/teo/v4l-dvb/v4l' No version yet, using 2.6.32-22-generic make[1]: Leaving directory `/home/teo/v4l-dvb/v4l' make[1]: Entering directory `/home/teo/v4l-dvb/v4l' scripts/make_makefile.pl Updating/Creating .config Preparing to compile for kernel version 2.6.32 ***WARNING:*** You do not have the full kernel sources installed. This does not prevent you from building the v4l-dvb tree if you have the kernel headers, but the full kernel source may be required in order to use make menuconfig / xconfig / qconfig. If you are experiencing problems building the v4l-dvb tree, please try building against a vanilla kernel before reporting a bug. Vanilla kernels are available at http://kernel.org. On most distros, this will compile a newly downloaded kernel: cp /boot/config-`uname -r` your kernel dir/.config cd your kernel dir make all modules_install install Please see your distro's web site for instructions to build a new kernel. V4L2_MEM2MEM_DEV: Requires at least kernel 2.6.33 VIDEO_TVP7002: Requires at least kernel 2.6.34 VIDEO_AK881X: Requires at least kernel 2.6.33 SOC_CAMERA: Requires at least kernel 2.6.33 SOC_CAMERA_MT9M001: Requires at least kernel 2.6.33 SOC_CAMERA_MT9M111: Requires at least kernel 2.6.33 SOC_CAMERA_MT9T031: Requires at least kernel 2.6.33 SOC_CAMERA_MT9V022: Requires at least kernel 2.6.33 SOC_CAMERA_TW9910: Requires at least kernel 2.6.33 SOC_CAMERA_PLATFORM: Requires at least kernel 2.6.33 SOC_CAMERA_OV772X: Requires at least kernel 2.6.33 RADIO_SAA7706H: Requires at least kernel 2.6.34 Created default (all yes) .config file ./scripts/make_myconfig.pl make[1]: Leaving directory `/home/teo/v4l-dvb/v4l' make[1]: Entering directory `/home/teo/v4l-dvb/v4l' perl scripts/make_config_compat.pl /lib/modules/2.6.32-22-generic/build ./.myconfig ./config-compat.h creating symbolic links... ln -sf . oss make -C firmware prep make[2]: Entering directory `/home/teo/v4l-dvb/v4l/firmware' make[2]: Leaving directory `/home/teo/v4l-dvb/v4l/firmware' make -C firmware make[2]: Entering directory `/home/teo/v4l-dvb/v4l/firmware' CC ihex2fw Generating vicam/firmware.fw Generating dabusb/firmware.fw Generating dabusb/bitstream.bin Generating ttusb-budget/dspbootcode.bin Generating cpia2/stv0672_vp4.bin Generating av7110/bootcode.bin make[2]: Leaving directory `/home/teo/v4l-dvb/v4l/firmware' Kernel build directory is /lib/modules/2.6.32-22-generic/build make -C /lib/modules/2.6.32-22-generic/build SUBDIRS=/home/teo/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.32-22-generic' CC [M] /home/teo/v4l-dvb/v4l/tuner-xc2028.o CC [M] /home/teo/v4l-dvb/v4l/tuner-simple.o CC [M] /home/teo/v4l-dvb/v4l/tuner-types.o CC [M] /home/teo/v4l-dvb/v4l/mt20xx.o CC [M] /home/teo/v4l-dvb/v4l/tda8290.o CC [M] /home/teo/v4l-dvb/v4l/tea5767.o CC [M] /home/teo/v4l-dvb/v4l/tea5761.o CC [M] /home/teo/v4l-dvb/v4l/tda9887.o CC [M] /home/teo/v4l-dvb/v4l/tda827x.o CC [M] /home/teo/v4l-dvb/v4l/au0828-core.o CC [M] /home/teo/v4l-dvb/v4l/au0828-i2c.o CC [M] /home/teo/v4l-dvb/v4l/au0828-cards.o CC [M] /home/teo/v4l-dvb/v4l/au0828-dvb.o CC [M] /home/teo/v4l-dvb/v4l/au0828-video.o CC [M] /home/teo/v4l-dvb/v4l/au8522_dig.o CC [M] /home/teo/v4l-dvb/v4l/au8522_decoder.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-pci.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-usb.o CC [M] /home/teo/v4l-dvb/v4l/flexcop.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-fe-tuner.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-i2c.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-sram.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-eeprom.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-misc.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-hw-filter.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-dma.o CC [M] /home/teo/v4l-dvb/v4l/bttv-driver.o CC [M] /home/teo/v4l-dvb/v4l/bttv-cards.o CC [M] /home/teo/v4l-dvb/v4l/bttv-if.o CC [M] /home/teo/v4l-dvb/v4l/bttv-risc.o CC [M] /home/teo/v4l-dvb/v4l/bttv-vbi.o CC [M] /home/teo/v4l-dvb/v4l/bttv-i2c.o CC [M] /home/teo/v4l-dvb/v4l/bttv-gpio.o CC [M] /home/teo/v4l-dvb/v4l/bttv-input.o CC [M] /home/teo/v4l-dvb/v4l/bttv-audio-hook.o CC [M] /home/teo/v4l-dvb/v4l/cpia2_v4l.o CC [M] /home/teo/v4l-dvb/v4l/cpia2_usb.o CC [M]
Re: v4l-dvb bug report
Hi Matteo, I had the same problem a while ago. Short answer, the firedtv driver needs full kernel source to compile. I think I ended up with the full kernel source for other reasons (you need full source if you are going to use make menuconfig/oldconfig/etc). But if make menuconfig and/or the firedtv driver doesn't matter for you - find your v4l-dvb/v4l/.config file, search for FIREDTV and set those entries to =n instead of =m or =y and you should be in business. Regards, Villy I am a newbee so please be patient with me. I have followed all the instructions and I tried to compile the sources and got a lot of errors. I don't think it's my fault but i may be wrong. My system: Ubuntu 10.04 with kernel 2.6.32.22 I have the headers installed, not the full kernel source code (shouldn't be required). My dvb-t interface is an usb stick: Conceptronic CTVDIGUSB2, I believe it has an afatech chipset. Here's the output from lsusb: Bus 002 Device 007: ID 1b80:d393 Afatech I downloaded the latest v4l-dvb source from hg clone http://linuxtv.org/hg/v4l-dvb I had a look at the daily test log and I don't see any test against 2.6.32.22 Here's the output from make: t...@xxx:~/v4l-dvb$ sudo make make -C /home/teo/v4l-dvb/v4l make[1]: Entering directory `/home/teo/v4l-dvb/v4l' No version yet, using 2.6.32-22-generic make[1]: Leaving directory `/home/teo/v4l-dvb/v4l' make[1]: Entering directory `/home/teo/v4l-dvb/v4l' scripts/make_makefile.pl Updating/Creating .config Preparing to compile for kernel version 2.6.32 ***WARNING:*** You do not have the full kernel sources installed. This does not prevent you from building the v4l-dvb tree if you have the kernel headers, but the full kernel source may be required in order to use make menuconfig / xconfig / qconfig. If you are experiencing problems building the v4l-dvb tree, please try building against a vanilla kernel before reporting a bug. Vanilla kernels are available at http://kernel.org. On most distros, this will compile a newly downloaded kernel: cp /boot/config-`uname -r` your kernel dir/.config cd your kernel dir make all modules_install install Please see your distro's web site for instructions to build a new kernel. V4L2_MEM2MEM_DEV: Requires at least kernel 2.6.33 VIDEO_TVP7002: Requires at least kernel 2.6.34 VIDEO_AK881X: Requires at least kernel 2.6.33 SOC_CAMERA: Requires at least kernel 2.6.33 SOC_CAMERA_MT9M001: Requires at least kernel 2.6.33 SOC_CAMERA_MT9M111: Requires at least kernel 2.6.33 SOC_CAMERA_MT9T031: Requires at least kernel 2.6.33 SOC_CAMERA_MT9V022: Requires at least kernel 2.6.33 SOC_CAMERA_TW9910: Requires at least kernel 2.6.33 SOC_CAMERA_PLATFORM: Requires at least kernel 2.6.33 SOC_CAMERA_OV772X: Requires at least kernel 2.6.33 RADIO_SAA7706H: Requires at least kernel 2.6.34 Created default (all yes) .config file ./scripts/make_myconfig.pl make[1]: Leaving directory `/home/teo/v4l-dvb/v4l' make[1]: Entering directory `/home/teo/v4l-dvb/v4l' perl scripts/make_config_compat.pl /lib/modules/2.6.32-22-generic/build ./.myconfig ./config-compat.h creating symbolic links... ln -sf . oss make -C firmware prep make[2]: Entering directory `/home/teo/v4l-dvb/v4l/firmware' make[2]: Leaving directory `/home/teo/v4l-dvb/v4l/firmware' make -C firmware make[2]: Entering directory `/home/teo/v4l-dvb/v4l/firmware' CC ihex2fw Generating vicam/firmware.fw Generating dabusb/firmware.fw Generating dabusb/bitstream.bin Generating ttusb-budget/dspbootcode.bin Generating cpia2/stv0672_vp4.bin Generating av7110/bootcode.bin make[2]: Leaving directory `/home/teo/v4l-dvb/v4l/firmware' Kernel build directory is /lib/modules/2.6.32-22-generic/build make -C /lib/modules/2.6.32-22-generic/build SUBDIRS=/home/teo/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.32-22-generic' CC [M] /home/teo/v4l-dvb/v4l/tuner-xc2028.o CC [M] /home/teo/v4l-dvb/v4l/tuner-simple.o CC [M] /home/teo/v4l-dvb/v4l/tuner-types.o CC [M] /home/teo/v4l-dvb/v4l/mt20xx.o CC [M] /home/teo/v4l-dvb/v4l/tda8290.o CC [M] /home/teo/v4l-dvb/v4l/tea5767.o CC [M] /home/teo/v4l-dvb/v4l/tea5761.o CC [M] /home/teo/v4l-dvb/v4l/tda9887.o CC [M] /home/teo/v4l-dvb/v4l/tda827x.o CC [M] /home/teo/v4l-dvb/v4l/au0828-core.o CC [M] /home/teo/v4l-dvb/v4l/au0828-i2c.o CC [M] /home/teo/v4l-dvb/v4l/au0828-cards.o CC [M] /home/teo/v4l-dvb/v4l/au0828-dvb.o CC [M] /home/teo/v4l-dvb/v4l/au0828-video.o CC [M] /home/teo/v4l-dvb/v4l/au8522_dig.o CC [M] /home/teo/v4l-dvb/v4l/au8522_decoder.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-pci.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-usb.o CC [M] /home/teo/v4l-dvb/v4l/flexcop.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-fe-tuner.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-i2c.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-sram.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-eeprom.o CC [M] /home/teo/v4l-dvb/v4l/flexcop-misc.o CC [M]
Re: v4l-dvb bug report
Yeah, thank you, I have found the FIREDTV=n trick on some other forum just a few minutes before I read your reply, and with that change it has compiled fine :) I'm not sure what firedtv is but I don't think I need it :) By the way may I ask a newbie question? If you need the kernel sources to compile v4l-dvb, it does not mean that you're recompiling the kernel, does it? :$ Thanks m. 2010/6/27 Villy Thomsen vill...@gmail.com: Hi Matteo, I had the same problem a while ago. Short answer, the firedtv driver needs full kernel source to compile. I think I ended up with the full kernel source for other reasons (you need full source if you are going to use make menuconfig/oldconfig/etc). But if make menuconfig and/or the firedtv driver doesn't matter for you - find your v4l-dvb/v4l/.config file, search for FIREDTV and set those entries to =n instead of =m or =y and you should be in business. Regards, Villy I am a newbee so please be patient with me. I have followed all the instructions and I tried to compile the sources and got a lot of errors. I don't think it's my fault but i may be wrong. My system: Ubuntu 10.04 with kernel 2.6.32.22 I have the headers installed, not the full kernel source code (shouldn't be required). My dvb-t interface is an usb stick: Conceptronic CTVDIGUSB2, I believe it has an afatech chipset. Here's the output from lsusb: Bus 002 Device 007: ID 1b80:d393 Afatech I downloaded the latest v4l-dvb source from hg clone http://linuxtv.org/hg/v4l-dvb I had a look at the daily test log and I don't see any test against 2.6.32.22 Here's the output from make: t...@xxx:~/v4l-dvb$ sudo make make -C /home/teo/v4l-dvb/v4l make[1]: Entering directory `/home/teo/v4l-dvb/v4l' No version yet, using 2.6.32-22-generic make[1]: Leaving directory `/home/teo/v4l-dvb/v4l' make[1]: Entering directory `/home/teo/v4l-dvb/v4l' scripts/make_makefile.pl Updating/Creating .config Preparing to compile for kernel version 2.6.32 ***WARNING:*** You do not have the full kernel sources installed. This does not prevent you from building the v4l-dvb tree if you have the kernel headers, but the full kernel source may be required in order to use make menuconfig / xconfig / qconfig. If you are experiencing problems building the v4l-dvb tree, please try building against a vanilla kernel before reporting a bug. Vanilla kernels are available at http://kernel.org. On most distros, this will compile a newly downloaded kernel: cp /boot/config-`uname -r` your kernel dir/.config cd your kernel dir make all modules_install install Please see your distro's web site for instructions to build a new kernel. V4L2_MEM2MEM_DEV: Requires at least kernel 2.6.33 VIDEO_TVP7002: Requires at least kernel 2.6.34 VIDEO_AK881X: Requires at least kernel 2.6.33 SOC_CAMERA: Requires at least kernel 2.6.33 SOC_CAMERA_MT9M001: Requires at least kernel 2.6.33 SOC_CAMERA_MT9M111: Requires at least kernel 2.6.33 SOC_CAMERA_MT9T031: Requires at least kernel 2.6.33 SOC_CAMERA_MT9V022: Requires at least kernel 2.6.33 SOC_CAMERA_TW9910: Requires at least kernel 2.6.33 SOC_CAMERA_PLATFORM: Requires at least kernel 2.6.33 SOC_CAMERA_OV772X: Requires at least kernel 2.6.33 RADIO_SAA7706H: Requires at least kernel 2.6.34 Created default (all yes) .config file ./scripts/make_myconfig.pl make[1]: Leaving directory `/home/teo/v4l-dvb/v4l' make[1]: Entering directory `/home/teo/v4l-dvb/v4l' perl scripts/make_config_compat.pl /lib/modules/2.6.32-22-generic/build ./.myconfig ./config-compat.h creating symbolic links... ln -sf . oss make -C firmware prep make[2]: Entering directory `/home/teo/v4l-dvb/v4l/firmware' make[2]: Leaving directory `/home/teo/v4l-dvb/v4l/firmware' make -C firmware make[2]: Entering directory `/home/teo/v4l-dvb/v4l/firmware' CC ihex2fw Generating vicam/firmware.fw Generating dabusb/firmware.fw Generating dabusb/bitstream.bin Generating ttusb-budget/dspbootcode.bin Generating cpia2/stv0672_vp4.bin Generating av7110/bootcode.bin make[2]: Leaving directory `/home/teo/v4l-dvb/v4l/firmware' Kernel build directory is /lib/modules/2.6.32-22-generic/build make -C /lib/modules/2.6.32-22-generic/build SUBDIRS=/home/teo/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.32-22-generic' CC [M] /home/teo/v4l-dvb/v4l/tuner-xc2028.o CC [M] /home/teo/v4l-dvb/v4l/tuner-simple.o CC [M] /home/teo/v4l-dvb/v4l/tuner-types.o CC [M] /home/teo/v4l-dvb/v4l/mt20xx.o CC [M] /home/teo/v4l-dvb/v4l/tda8290.o CC [M] /home/teo/v4l-dvb/v4l/tea5767.o CC [M] /home/teo/v4l-dvb/v4l/tea5761.o CC [M] /home/teo/v4l-dvb/v4l/tda9887.o CC [M] /home/teo/v4l-dvb/v4l/tda827x.o CC [M] /home/teo/v4l-dvb/v4l/au0828-core.o CC [M] /home/teo/v4l-dvb/v4l/au0828-i2c.o CC [M] /home/teo/v4l-dvb/v4l/au0828-cards.o CC [M] /home/teo/v4l-dvb/v4l/au0828-dvb.o CC [M] /home/teo/v4l-dvb/v4l/au0828-video.o CC [M]
Re: [Bulk] v4l-dvb bug report
Holy cow -- Ubuntu is still borked in regards to the firedtv stuff ?! What is that - something like 4 releases in a row now? Anyway, well known problem, have a look here: http://www.mail-archive.com/search?q=firedtv+Ubuntul=linux-media%40vger.kernel.org first link will give you the easy fix to your compilation/build problem. -- 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: [Bulk] Re: v4l-dvb bug report
matteo sisti sette wrote: Yeah, thank you, I have found the FIREDTV=n trick on some other forum just a few minutes before I read your reply, and with that change it has compiled fine :) oops, I just sent my reply before I saw that you already figured it out I'm not sure what firedtv is but I don't think I need it :) its a driver for some firewire based DVB devices ... you won't need it. By the way may I ask a newbie question? If you need the kernel sources to compile v4l-dvb, it does not mean that you're recompiling the kernel, does it? :$ that's correct ... all you are doing is building the v4l-dvb drivers against your specific kernel ... after building them, you can then install them, which effectively replaces the kernel supplied set of v4l-dvb drivers with the set you just compiled/built -- 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: [HG PULL] http://linuxtv.org/hg/~awalls/v4l-dvb-bug
Andy Walls wrote: On Mon, 2010-02-01 at 16:45 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb-bug for the following 5 *high priority* changesets: Hmm... I don't think cx18 alsa code went to 2.3.33. That may explain why they got rejected at fixes.git tree: Hmmm. Aorry for the confusion. I thought the cx18-alsa patches had gone. If some of the patches need to go to the fixes.git tree, please rebase them against the tree and send me a new pull request. Otherwise, please let me know for me to apply at the patches for 2.6.34. These patches only need to go with the cx18-alsa patches - wherever they are. Ok. I added them at the normal tree. As for me using git: I'm supposed to be getting cable Internet service Wednesday of this week. (Ha! I don't think the cable company will be laying cable in 10 inches of snow.) When I do get hooked up, I'll plan on moving to git. Well, except for the snow, that's good news! Cheers, Mauro -- 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: [HG PULL] http://linuxtv.org/hg/~awalls/v4l-dvb-bug
Andy Walls wrote: Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb-bug for the following 5 *high priority* changesets: Hmm... I don't think cx18 alsa code went to 2.3.33. That may explain why they got rejected at fixes.git tree: pulling from http://linuxtv.org/hg/~awalls/v4l-dvb-bug searching for changes adding changesets adding manifests adding file changes added 5 changesets with 6 changes to 5 files (+1 heads) (run 'hg heads' to see heads, 'hg merge' to merge) hg incoming -R /home/v4l/tmp/hg/v4l-dvb /home/v4l/tmp/hg_temp New patches start at 14086 Processing from patch 14086 to patch 14090 Generating hg_14086_cx18_rename_snd_cx18_mixer_lock_to_snd_cx18_lock_and_increase_visibility.patch Generating hg_14087_cx18_add_missing_serialization_locking_to_cx18_alsa.patch Generating hg_14088_cx18_fix_memory_leak_in_cx18_alsa_starting_of_pcm_captures.patch Generating hg_14089_cx18_increment_driver_version_for_the_addition_of_cx18_alsa_and_fixes.patch Generating hg_14090_cx18_add_missing_serialization_locks_to_cx18_dvb.patch [...@pedra fixes.git]$ quilt push Applying patch patches/hg_14086_cx18_rename_snd_cx18_mixer_lock_to_snd_cx18_lock_and_increase_visibility.patch can't find file to patch at input line 18 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |Changeset: 14086 |From: Andy Walls awa...@radix.net |Commiter: Andy Walls awa...@radix.net |Date: Sat Jan 30 12:27:29 2010 -0500 |Subject: cx18: Rename snd_cx18_mixer_lock to snd_cx18_lock and increase visibility | |Rename snd_cx18_mixer_lock() to snd_cx18_lock() in anticpation of using it |in the cx18-alsa-pcm.c file routines. | |Priority: high | |Signed-off-by: Andy Walls awa...@radix.net |--- | |diff -upNr oldtree/drivers/media/video/cx18/cx18-alsa.h linux/drivers/media/video/cx18/cx18-alsa.h |--- oldtree/drivers/media/video/cx18/cx18-alsa.h 2010-02-01 16:41:32.0 -0200 |+++ linux/drivers/media/video/cx18/cx18-alsa.h 2010-02-01 16:41:29.0 -0200 -- No file to patch. Skipping patch. 1 out of 1 hunk ignored can't find file to patch at input line 44 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |diff -upNr oldtree/drivers/media/video/cx18/cx18-alsa-mixer.c linux/drivers/media/video/cx18/cx18-alsa-mixer.c |--- oldtree/drivers/media/video/cx18/cx18-alsa-mixer.c 2010-02-01 16:41:32.0 -0200 |+++ linux/drivers/media/video/cx18/cx18-alsa-mixer.c 2010-02-01 16:41:29.0 -0200 -- No file to patch. Skipping patch. 4 out of 4 hunks ignored Patch patches/hg_14086_cx18_rename_snd_cx18_mixer_lock_to_snd_cx18_lock_and_increase_visibility.patch does not apply (enforce with -f) If some of the patches need to go to the fixes.git tree, please rebase them against the tree and send me a new pull request. Otherwise, please let me know for me to apply at the patches for 2.6.34. -- Cheers, Mauro -- 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: [HG PULL] http://linuxtv.org/hg/~awalls/v4l-dvb-bug
On Mon, 2010-02-01 at 16:45 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb-bug for the following 5 *high priority* changesets: Hmm... I don't think cx18 alsa code went to 2.3.33. That may explain why they got rejected at fixes.git tree: Hmmm. Aorry for the confusion. I thought the cx18-alsa patches had gone. If some of the patches need to go to the fixes.git tree, please rebase them against the tree and send me a new pull request. Otherwise, please let me know for me to apply at the patches for 2.6.34. These patches only need to go with the cx18-alsa patches - wherever they are. As for me using git: I'm supposed to be getting cable Internet service Wednesday of this week. (Ha! I don't think the cable company will be laying cable in 10 inches of snow.) When I do get hooked up, I'll plan on moving to git. Regards, Andy -- 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
[HG PULL] http://linuxtv.org/hg/~awalls/v4l-dvb-bug
Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb-bug for the following 5 *high priority* changesets: 01/05: cx18: Rename snd_cx18_mixer_lock to snd_cx18_lock and increase visibility http://linuxtv.org/hg/~awalls/v4l-dvb-bug?cmd=changeset;node=5d28c157d0ef 02/05: cx18: Add missing serialization locking to cx18-alsa http://linuxtv.org/hg/~awalls/v4l-dvb-bug?cmd=changeset;node=da3e7202f89e 03/05: cx18: Fix memory leak in cx18-alsa starting of PCM captures http://linuxtv.org/hg/~awalls/v4l-dvb-bug?cmd=changeset;node=600fd701323f 04/05: cx18: Increment driver version for the addition of cx18-alsa and fixes http://linuxtv.org/hg/~awalls/v4l-dvb-bug?cmd=changeset;node=e4fa9f845cbc 05/05: cx18: Add missing serialization locks to cx18-dvb http://linuxtv.org/hg/~awalls/v4l-dvb-bug?cmd=changeset;node=c00c5d613577 These changes fix previously discussed ALSA open race that can put the cx18 driver in a bad state, a DVB operation locking problem, and a memory leak in starting ALSA captures. cx18-alsa-mixer.c | 24 cx18-alsa-pcm.c | 28 ++-- cx18-alsa.h | 16 cx18-dvb.c|4 cx18-version.h|2 +- 5 files changed, 39 insertions(+), 35 deletions(-) Thanks, Andy -- 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: [linux-dvb] [BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)
Trent Piepho wrote: On Tue, 17 Feb 2009, Steven Toth wrote: Trent Piepho wrote: On Mon, 16 Feb 2009, Steven Toth wrote: Hartmut, Oliver and Trent: Thanks for helping with this issue. I've just reverted the changeset. We still need a fix at dm1105, au0828-dvb and maybe other drivers that call the filtering routines inside IRQ's. Fix the demux, add a worker thread and allow drivers to call it directly. I'm not a big fan of videobuf_dvb or having each driver do it's own thing as an alternative. Fixing the demux... Would this require and extra buffer copy? probably, but it's a trade-off between the amount of spent during code management on a driver by driver basis vs wrestling with videobuf_dvb and all of problems highlighted on the ML over the last 2 years. Have the driver copy the data into the demuxer from the interrupt handler with irqs disabled? That's still too much. The right way to do it is to have a queue of DMA buffers. In the interrupt handler the driver takes the completed DMA buffer off the to DMA queue and puts it in the to process queue. The driver should not copy and cetainly not demux the data from the interrupt handler. I know what the right way is Trent (see cx23885) although thank you for reminding me. videobuf_dvb hasn't convinced people like me to bury myself in its mess or complexity during retro fits cases. Retro fitting videobuf_dvb into cx18 (at the time) was way too much effort. Retro fitting it into existing drivers can be painful and I haven't seen any volunteers stand up over the last 24 months to get this done. My suggestion? For the most part we're talking about very low data rates for DVB, coupled with fast memory buses for memcpy's. If the group doesn't want calls to the sw_filter methods then implement a half-way-house replacement for those drivers - as I mentioned above - with the memcpy. Either this approach, or The problem is holding a spin lock with irqs disabled for a long amount of time. What exactly is your plan that will remove this, yet allow drivers to process their buffers from an irq handler? That's not what I was suggesting. I was suggesting adding some ring buffer code and a worker thread for each driver context (done in a mythical demux-register func). This means that each driver get's it's own worker and ringbuffer. Driver mutex on your own ring buffer is localized to your instance of the driver. It would be up to your drivers worker thread (instantiated and managed incidentally by the demux core, not at irq level), to acquire the long term spinlock via sw_filter_n (already in demux core) underdiscussion and NOT block a driver calling demux-feedMyPersonalRingBuffer(). A general question to the group: Who wants to volunteer to retro fit videobuf_dvb into the current drivers so we can avoid calls to sw_filter_...n() directly? I don't see why videobuf_dvb is needed. That was the point I was trying to make. IE. Push videobuf_dvb like behavior into the demux core, having drivers register, give each driver it's own worker thread and have that thread, running not in the interrupt context, feed the existing sw_filter_n() functions. The price is the cost of doing a memcpy of a low bitrate low frequency buffer into your demux's personal ring buffer. That has to be more efficient than the current drivers that feed sw_filter_n() directly, but not ideal. It's a half-way-house solution that consolidates complicated code into code, and keeps the drivers clean and easier to manage. Trade off an infrequent memcpy on a low volume stream in 50% of the drivers for a simplified approach. You don't have to do this for every driver, especially drivers that already implement videobuf_dvb, do it for the current problematic drivers.. or, have a volunteer add videobuf_dvb to all of the existing drivers. - Steve -- 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: [linux-dvb] [BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)
Trent Piepho wrote: On Wed, 18 Feb 2009, Oliver Endriss wrote: [1] If you want to lock a process against an interrupt handler, - the process must use spin_lock_irq() - the interrupt can use spin_lock() A routine has to use spin_lock_irqsave if (and only if) process and irq call the routine concurrently. I do not see yet how this might happen. Some code calls the swfilter functions from process context and some drivers call them from interrupt context. There would be a problem if (and only if) it could happen concurrently within a given driver. A driver may call the functions either from process context or from a tasklet/irq. User space access will occur only if demux_source == DMX_MEMORY_FE. In this case the driver must not call the routine. If demux_source == DMX_FRONTEND, the driver may call the routine, but userspace won't. Sorry, I need more information to identify the problem. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ -- 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: [linux-dvb] [BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)
On Wed, 18 Feb 2009, Steven Toth wrote: Trent Piepho wrote: On Tue, 17 Feb 2009, Steven Toth wrote: Trent Piepho wrote: On Mon, 16 Feb 2009, Steven Toth wrote: Fixing the demux... Would this require and extra buffer copy? probably, but it's a trade-off between the amount of spent during code management on a driver by driver basis vs wrestling with videobuf_dvb and all of problems highlighted on the ML over the last 2 years. Have the driver copy the data into the demuxer from the interrupt handler with irqs disabled? That's still too much. The right way to do it is to have a queue of DMA buffers. In the interrupt handler the driver takes the completed DMA buffer off the to DMA queue and puts it in the to process queue. The driver should not copy and cetainly not demux the data from the interrupt handler. I know what the right way is Trent (see cx23885) although thank you for reminding me. videobuf_dvb hasn't convinced people like me to bury myself in its mess or complexity during retro fits cases. Retro fitting videobuf_dvb into cx18 (at the time) was way too much effort. Retro fitting it into existing drivers can be painful and I haven't seen any volunteers stand up over the last 24 months to get this done. My suggestion? For the most part we're talking about very low data rates for DVB, coupled with fast memory buses for memcpy's. If the group doesn't want calls to the sw_filter methods then implement a half-way-house replacement for those drivers - as I mentioned above - with the memcpy. Either this approach, or The problem is holding a spin lock with irqs disabled for a long amount of time. What exactly is your plan that will remove this, yet allow drivers to process their buffers from an irq handler? That's not what I was suggesting. I was suggesting adding some ring buffer code and a worker thread for each driver context (done in a mythical demux-register func). This means that each driver get's it's own worker and ringbuffer. Driver But won't this new ringbuffer be fed from interrupt context? So instead of feeding the demuxer from an irq, you are feeding the pre-demuxer ringbuffer from an irq. Isn't that going to have the same long term lock holding with irqs disabled problem? A general question to the group: Who wants to volunteer to retro fit videobuf_dvb into the current drivers so we can avoid calls to sw_filter_...n() directly? I don't see why videobuf_dvb is needed. That was the point I was trying to make. IE. Push videobuf_dvb like behavior into the demux core, having drivers register, give each driver it's own worker thread and have that thread, running not in the interrupt context, feed the existing sw_filter_n() functions. The price is the cost of doing a memcpy of a If you look at the pluto2 fix I did, the code to create a work queue is very simple. I don't think moving that to the demuxer would make the patch to the driver much simpler. The difficulty comes from not using a single buffer so the driver doesn't need to hold a spin lock while it copies data out. -- 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: [linux-dvb] [BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)
Trent Piepho wrote: On Mon, 16 Feb 2009, Steven Toth wrote: Hartmut, Oliver and Trent: Thanks for helping with this issue. I've just reverted the changeset. We still need a fix at dm1105, au0828-dvb and maybe other drivers that call the filtering routines inside IRQ's. Fix the demux, add a worker thread and allow drivers to call it directly. I'm not a big fan of videobuf_dvb or having each driver do it's own thing as an alternative. Fixing the demux... Would this require and extra buffer copy? probably, but it's a trade-off between the amount of spent during code management on a driver by driver basis vs wrestling with videobuf_dvb and all of problems highlighted on the ML over the last 2 years. Have the driver copy the data into the demuxer from the interrupt handler with irqs disabled? That's still too much. The right way to do it is to have a queue of DMA buffers. In the interrupt handler the driver takes the completed DMA buffer off the to DMA queue and puts it in the to process queue. The driver should not copy and cetainly not demux the data from the interrupt handler. I know what the right way is Trent (see cx23885) although thank you for reminding me. videobuf_dvb hasn't convinced people like me to bury myself in its mess or complexity during retro fits cases. Retro fitting videobuf_dvb into cx18 (at the time) was way too much effort. Retro fitting it into existing drivers can be painful and I haven't seen any volunteers stand up over the last 24 months to get this done. My suggestion? For the most part we're talking about very low data rates for DVB, coupled with fast memory buses for memcpy's. If the group doesn't want calls to the sw_filter methods then implement a half-way-house replacement for those drivers - as I mentioned above - with the memcpy. Either this approach, or make videobuf_dvb mandatory and deprecate sw_filter_...n() to intensionally break drivers and force maintainers to comply. This will upset people. Realistically, this thread will probably go on for a couple of days then trail off into nothing. The subject will rear it's head again in a few months, like it's done in the past. A general question to the group: Who wants to volunteer to retro fit videobuf_dvb into the current drivers so we can avoid calls to sw_filter_...n() directly? I'm willing to loan any hardware I have to the volunteer assuming we can work out something on shipping. - Steve -- 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: [linux-dvb] [BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)
Steven Toth wrote: A general question to the group: Who wants to volunteer to retro fit videobuf_dvb into the current drivers so we can avoid calls to sw_filter_...n() directly? Can videobuf_dvb be used by hardware with MPEG decoders, too? My (probably not up-to-date) impression was that it's been designed specifically for budget cards with no demux or decoder hardware. But the sw_filter functions are useful for those devices, too, i.e. to feed a PID to multiple userspace clients or to provide section filters where some kind of hardware only provides basic PID filtering. Regards, Andreas -- 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: [linux-dvb] [BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)
Andreas Oberritter wrote: Oliver Endriss wrote: ... @Andreas: Could you please explain in more detail what bad things might happen? To quote myself from the changelog: This fixes a deadlock discovered by lockdep. I re-read the commit message, but it still does not ring any bells. Could you please post the lockdep output? The lock is used in process context (e.g. DMX_START) and might also be used from interrupt context (e.g. dvb_dmx_swfilter). Correct: - dvb_dmx_swfilter uses spin_lock (called from irq, tasklet, whatever) - DMX_START uses spin_lock_irq (called from process) - ok (see below). From http://osdir.com/ml/kernel.janitors/2002-08/msg00022.html: spin_lock_irq disables local interrupts and then takes the spin_lock. If you know you're in process context and other users may be in interrupt context, this is the correct call to make. spin_lock_irqsave saves local interrupt state into the flags variable, disables interrupts, then takes the spin_lock. spin_unlock_irqrestore restores the local state saved in the flags. Use this variant if you don't know whether you're in interrupt or process context. So, if the assumtions above are correct, then spin_lock_irq must be used by all functions called from process context and spin_lock_irqsave must be used by all functions called from an unknown context. Correct. [1] If you want to lock a process against an interrupt handler, - the process must use spin_lock_irq() - the interrupt can use spin_lock() A routine has to use spin_lock_irqsave if (and only if) process and irq call the routine concurrently. I do not see yet how this might happen. (Basically, the same happens when locking between tasklet and process context, except that it is sufficient to use spin_lock_bh instead of spin_lock_irq.) Regards Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ -- 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: [linux-dvb] [BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)
On Wed, 18 Feb 2009, Oliver Endriss wrote: [1] If you want to lock a process against an interrupt handler, - the process must use spin_lock_irq() - the interrupt can use spin_lock() A routine has to use spin_lock_irqsave if (and only if) process and irq call the routine concurrently. I do not see yet how this might happen. Some code calls the swfilter functions from process context and some drivers call them from interrupt context. -- 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: [linux-dvb] [BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)
Hartmut, Oliver and Trent: Thanks for helping with this issue. I've just reverted the changeset. We still need a fix at dm1105, au0828-dvb and maybe other drivers that call the filtering routines inside IRQ's. Fix the demux, add a worker thread and allow drivers to call it directly. I'm not a big fan of videobuf_dvb or having each driver do it's own thing as an alternative. Fixing the demux... Would this require and extra buffer copy? probably, but it's a trade-off between the amount of spent during code management on a driver by driver basis vs wrestling with videobuf_dvb and all of problems highlighted on the ML over the last 2 years. demux-register_driver() demux-deliver_payload() demux-unregister_driver() Then deprecate sw_filterN() methods. That would simplify drivers significantly, at the expense of another buffer copy while deliver-payload() clones the buffer into its internal state to be more timely. - Steve -- 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: [linux-dvb] [BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)
On Mon, 2009-02-16 at 14:15 -0500, Steven Toth wrote: Steven Toth wrote: Hartmut, Oliver and Trent: Thanks for helping with this issue. I've just reverted the changeset. We still need a fix at dm1105, au0828-dvb and maybe other drivers that call the filtering routines inside IRQ's. Fix the demux, add a worker thread and allow drivers to call it directly. I'm not a big fan of videobuf_dvb or having each driver do it's own thing as an alternative. Fixing the demux... Would this require and extra buffer copy? probably, but it's a trade-off between the amount of spent during code management on a driver by driver basis vs wrestling with videobuf_dvb and all of problems highlighted on the ML over the last 2 years. demux-register_driver() demux-deliver_payload() demux-unregister_driver() Then deprecate sw_filterN() methods. That would simplify drivers significantly, at the expense of another buffer copy while deliver-payload() clones the buffer into its internal state to be more timely. I meant to add... The cx18 and a few other smaller drivers (flexcop?) dvb drivers also call directly. cx23885/cx88 does not. cx18 calls it from it's own worker thread. To keep up with the rate at which the CX23418 firmware hands over buffers (and times out the cpu2epu mailbox!) during a dual analog DTV capture, there's no avoiding having a worker thread in the cx18 driver. Regards, Andy -- 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: [linux-dvb] [BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)
On Sun, 2009-02-15 at 13:36 +0100, Oliver Endriss wrote:
e9hack wrote:
Hi,
this change set is wrong. The affected functions cannot be called from an
interrupt
context, because they may process large buffers. In this case, interrupts
are disabled for
a long time. Functions, like dvb_dmx_swfilter_packets(), could be called
only from a
tasklet. This change set does hide some strong design bugs in dm1105.c and
au0828-dvb.c.
Please revert this change set and do fix the bugs in dm1105.c and
au0828-dvb.c (and other
files).
@Mauro:
This changeset _must_ be reverted! It breaks all kernels since 2.6.27
for applications which use DVB and require a low interrupt latency.
It is a very bad idea to call the demuxer to process data buffers with
interrupts disabled!
FYI, a LIRC problem was reported here:
http://vdrportal.de/board/thread.php?postid=786366#post786366
and it has been verified that changeset
http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833
causes the problem:
http://vdrportal.de/board/thread.php?postid=791813#post791813
Please revert this changeset immediately and submit a fix to the stable
kernels = 2.6.27.
CU
Oliver
The patch below is an idea for a fix that uses a module parameter to
give back right away the original behavior to those who need it, while
buying time to fix the drivers that are doing things wrong.
I don't know if this patch will be acceptable to anyone, and I suspect
there will be disagreement on the default behavior.
It compiles and comes through checkpatch.pl with only one warning about
an extern declaration I didn't know where to place. This patch still
needs to be checked for correctness and tested.
Regards,
Andy
Signed-off-by: Andy Walls awa...@radix.net
diff -r 3976e528b4a6 linux/drivers/media/dvb/dvb-core/dmxdev.c
--- a/linux/drivers/media/dvb/dvb-core/dmxdev.c Sat Feb 14 15:08:37 2009 -0500
+++ b/linux/drivers/media/dvb/dvb-core/dmxdev.c Sun Feb 15 14:55:49 2009 -0500
@@ -35,6 +35,17 @@
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Turn on/off debugging (default:off).);
+
+/*
+ * FIXME - remove this conservative lock kludge, when the offending drivers
+ * that make some calls improperly from an interrupt context are fixed.
+ */
+int dmxdev_conservative_locks;
+
+module_param_named(conservative_locks, dmxdev_conservative_locks, int, 0644);
+MODULE_PARM_DESC(conservative_locks,
+Work around for drivers that make calls\n
+\t\twith interrupts disabled (default:0/off).);
#define dprintkif (debug) printk
@@ -364,16 +375,22 @@
enum dmx_success success)
{
struct dmxdev_filter *dmxdevfilter = filter-priv;
- unsigned long flags;
+ unsigned long flags = 0;
int ret;
if (dmxdevfilter-buffer.error) {
wake_up(dmxdevfilter-buffer.queue);
return 0;
}
- spin_lock_irqsave(dmxdevfilter-dev-lock, flags);
+ if (dmxdev_conservative_locks)
+ spin_lock_irqsave(dmxdevfilter-dev-lock, flags);
+ else
+ spin_lock(dmxdevfilter-dev-lock);
if (dmxdevfilter-state != DMXDEV_STATE_GO) {
- spin_unlock_irqrestore(dmxdevfilter-dev-lock, flags);
+ if (dmxdev_conservative_locks)
+ spin_unlock_irqrestore(dmxdevfilter-dev-lock, flags);
+ else
+ spin_unlock(dmxdevfilter-dev-lock);
return 0;
}
del_timer(dmxdevfilter-timer);
@@ -392,7 +409,10 @@
}
if (dmxdevfilter-params.sec.flags DMX_ONESHOT)
dmxdevfilter-state = DMXDEV_STATE_DONE;
- spin_unlock_irqrestore(dmxdevfilter-dev-lock, flags);
+ if (dmxdev_conservative_locks)
+ spin_unlock_irqrestore(dmxdevfilter-dev-lock, flags);
+ else
+ spin_unlock(dmxdevfilter-dev-lock);
wake_up(dmxdevfilter-buffer.queue);
return 0;
}
@@ -404,12 +424,18 @@
{
struct dmxdev_filter *dmxdevfilter = feed-priv;
struct dvb_ringbuffer *buffer;
- unsigned long flags;
+ unsigned long flags = 0;
int ret;
- spin_lock_irqsave(dmxdevfilter-dev-lock, flags);
+ if (dmxdev_conservative_locks)
+ spin_lock_irqsave(dmxdevfilter-dev-lock, flags);
+ else
+ spin_lock(dmxdevfilter-dev-lock);
if (dmxdevfilter-params.pes.output == DMX_OUT_DECODER) {
- spin_unlock_irqrestore(dmxdevfilter-dev-lock, flags);
+ if (dmxdev_conservative_locks)
+ spin_unlock_irqrestore(dmxdevfilter-dev-lock, flags);
+ else
+ spin_unlock(dmxdevfilter-dev-lock);
return 0;
}
@@ -419,7 +445,10 @@
else
buffer = dmxdevfilter-dev-dvr_buffer;
if (buffer-error) {
-
