Re: Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)
Hello, We are now able to reproduce the problem faster and easier (using the patched version of szap-s2 and the scripts included in the tar.gz : http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/17334 and http://cache.gmane.org//gmane/linux/drivers/video-input-infrastructure/17334-001.bin ) 0) su -c rmmod ngene modprobe ngene one_adapter=0 1) ./run_szap-s2_adapter0.sh | grep Delay 2) in parallel to 1) szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r -Q 7 (better: by adding -Q the program is terminated, and all devices are closed after approx. 8 to 9 secs) = while 2) is running 1) will show increased tuning times Delay : 0.541970 Delay : 0.606943 Delay : 1.410069 [ HERE 2) was started ] Delay : 1.369592 Delay : 1.261879 Delay : 1.766680 3) after 2) has terminated simply let 1) continue for 30-40 iterations. you will see .. Delay : 1.845793 Delay : 1.772285 Delay : 2.045703 Delay : 1.817985 Delay : 0.982030 Delay : 1.769856 Delay : 1.769782 Delay : 0.537857 Delay : 21.628382 4) At this point, immediately press Ctrl-C and restart 1) - you will see Delay : 0.577599 Delay : 0.549717 Delay : 0.593816 Delay : 0.593758 Delay : 0.549584 Delay : 0.546012 == BAD: Problem seems to happen due to one adapter being opened and closed again == GOOD: we are now able to easily and quickly reproduce both problems without Ctrl-C thanks for your help, Andreas Besse Andreas Besse wrote: Hello, we discovered several problems with the ngene based dual DVB cards. The problems occur with the Digital Devices Cine S2 Dual DVB-S2 device (Linux4Media cineS2 DVB-S2 Twin Tuner), the clones like Mystique SaTiX S2 Dual should also be affected. We are using the ngene drivers from the linuxtv repository http://linuxtv.org/hg/v4l-dvb and the firmware version 15 provided by Digital Devices. *Setup* *** OpenSuse Linux 11.0 Linux anna 2.6.25.20-0.5-pae #1 SMP 2009-08-14 01:48:11 +0200 i686 i686 i386 GNU/Linux DVB drivers: http://linuxtv.org/hg/v4l-dvb (ngene) 2e0444bf93a4 (changeset 14233:2e0444bf93a4, date: Mon Feb 22 10:58:43 2010 -0300) module loaded with modprobe ngene one_adapter=0 *Usage* *** We slightly modified the latest version of szap-s2 (available from http://mercurial.intuxication.org/hg/szap-s2/ ); see attached .tar.gz tar xvfz modified_szap_s2.tar.gz make Most importantly, the modified version prints out the total delay in seconds of main() to allow for easier debugging. *Problem A* *** Two running instance of szap-s2 are used: a) one for changing channels between Das Erste (Astra 19.2E) and ZDF (Astra 19.2E) b) the other one for recording from Das Erste (or any other channel) Result: When only a) is running, channel tuning times between the two different transponders of Das Erste and ZDF are around 0.5 secs. This is really good. However, when b) is started in parallel, these times increase to 1.5 to 1.8 seconds. This is not good. How to reproduce? 1) in one shell, run ./run_szap-s2_adapter0.sh | grep Delay You will see Delay : 0.560508 Delay : 0.545771 Delay : 0.609781 Delay : 0.593796 Delay : 0.649772 Delay : 0.614023 .. 2) in parallel in another shell, run ./szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r Immediately, you will see in 1) Delay : 1.525178 Delay : 1.781971 .. *Problem B* *** After reproducing Problem A, we terminate process 2) by hitting Ctrl-C. Even then, channel tuning time stay high in process 1), you will still see Delay : 1.773303 Delay : 1.781734 Delay : 1.749948 .. This is not good. *Problem C* *** What is even worse: Very often, you will soon run into trouble: After a very iterations, you will see: Delay : 21.616521 Delay : 21.773475 Delay : 21.765678 This means that tuning was not possible anymore at all. In this situation, it always helps to re-load the module by runing: su -c rmmod ngene modprobe ngene one_adapter=0 *Problem D* *** When terminating process 1) and immediately restarting it, channel tuning times - again - stay high. This is not good. Often you will also see Problem C then. *Problem E* *** Go back to reproducing Problem A (process 1 and 2 are running), and the continuously start and terminate process 2) by hitting Ctrl-C again and again. Sooner or later, you will see Problem C occur then. *Remark* *** It _seems_ that, after terminating all szap-s2 processes, and waiting 1 to 2 minutes, and then restarting szap-s2 again, the failures/problems seem to be gone _without_ reloading the module. thanks for your help, Andreas Besse -- To unsubscribe from
Re: Order of dvb devices
Manu Abraham wrote: On Sat, Jan 16, 2010 at 3:00 AM, Oliver Endriss o.endr...@gmx.de wrote: Devin Heitmueller wrote: On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse be...@motama.com wrote: yes if there are different drivers I already observed the behaviour that the ordering gets flipped after reboot. But if I assume, that there is only *one* driver that is loaded (e.g. budget_av) for all dvb cards in the system, how is the ordering of these devices determined? How does the driver search for available dvb cards? The driver does not 'search' for a card. The driver registers the ids of all supported cards with the pci subsystem of the kernel. When the pci subsystem detects a new card, it calls the 'probe' routine of the driver (for example saa7146_init_one for saa7146-based cards). So the ordering is determined by the pci subsystem. I believe your assumption is incorrect. I believe the enumeration order is not deterministic even for multiple instances of the same driver. It is not uncommon to hear mythtv users complain that I have two PVR-150 cards installed in my PC and the order sometimes get reversed on reboot. Afaik the indeterministic behaviour is caused by udev, not by the kernel. We never had these problems before udev was introduced. True, the ordering is not exactly the same everytime. One will need to provide PCI Bus related info also to a practical udev configuration to get things sorted out in a sane way, rather than anything else. with PCI Bus related info you mean the KERNELS parameter which is reported by udevinfo? udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0) [...] looking at parent device '/devices/pci:00/:00:1e.0/:08:00.0': KERNELS==:08:00.0 SUBSYSTEMS==pci does this KERNELS parameter always match the Slot-Id of lspci -vmm ? Slot: 08:00.0 Class: Multimedia controller Vendor: Philips Semiconductors Device: SAA7146 SVendor:Technotrend Systemtechnik GmbH SDevice:S2-3200 Rev:01 is it right that the Slot-Id is deterministic for PCI/PCIe based systems? -- 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: Order of dvb devices
Manu Abraham wrote:
On Mon, Jan 18, 2010 at 12:58 PM, Andreas Besse be...@motama.com wrote:
Manu Abraham wrote:
On Sat, Jan 16, 2010 at 3:00 AM, Oliver Endriss o.endr...@gmx.de wrote:
Devin Heitmueller wrote:
On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse be...@motama.com wrote:
yes if there are different drivers I already observed the behaviour that
the ordering gets flipped after reboot.
But if I assume, that there is only *one* driver that is loaded (e.g.
budget_av) for all dvb cards in the system, how is the ordering of these
devices determined? How does the driver search for available dvb cards?
The driver does not 'search' for a card. The driver registers the ids of
all supported cards with the pci subsystem of the kernel.
When the pci subsystem detects a new card, it calls the 'probe' routine
of the driver (for example saa7146_init_one for saa7146-based cards).
So the ordering is determined by the pci subsystem.
I believe your assumption is incorrect. I believe the enumeration
order is not deterministic even for multiple instances of the same
driver. It is not uncommon to hear mythtv users complain that I have
two PVR-150 cards installed in my PC and the order sometimes get
reversed on reboot.
Afaik the indeterministic behaviour is caused by udev, not by the
kernel. We never had these problems before udev was introduced.
True, the ordering is not exactly the same everytime. One will need to
provide PCI Bus related info also to a practical udev configuration to
get things sorted out in a sane way, rather than anything else.
with PCI Bus related info you mean the KERNELS parameter which is
reported by udevinfo?
udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0)
[...]
looking at parent device '/devices/pci:00/:00:1e.0/:08:00.0':
KERNELS==:08:00.0
SUBSYSTEMS==pci
does this KERNELS parameter always match the Slot-Id of lspci -vmm ?
Slot: 08:00.0
Class: Multimedia controller
Vendor: Philips Semiconductors
Device: SAA7146
SVendor:Technotrend Systemtechnik GmbH
SDevice:S2-3200
Rev:01
is it right that the Slot-Id is deterministic for PCI/PCIe based systems?
Slot can also change, since slots are behind a specific bridge which
could be susceptible to events such as hotplug. Also things such as
PCI reordering and things like that tend to muck up things even
more.Things such as DVB_ADAPTER number are also pointless and useless.
You can see an example how to handle it in a bit practical manner:
http://www.wlug.org.nz/UDev
thanks for your explanation.
thank for your answer.
if no hotplug (removing or adding PCI/PCie cards) is involved, is the
PCI Slot-ID then fixed?
does the KERNELS parameter of the following udev rule not change after
boot if no hotplug is involved?
SUBSYSTEM==dvb, ATTRS{vendor}==0x18c3, ATTRS{device}==0x0720,
KERNELS==:01:00.0,
PROGRAM=/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter0/%%s
$${K#*.}', SYMLINK+=%c
--
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
Order of dvb devices
if a system contains multiple DVB cards of the same type, how is the order of devices determined by the driver/kernel? I use 2 Technotrend S2-3200 cards in a system and observerd that if I load the driver driver budget_ci manually as follows: modprobe budget_ci adapter_nr=0,1 the device with the lower pci ID :08:00.0 is assigned to adapter0 and the device with the higher pci ID :08:01.0 is assigned to adapter1: udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0) [...] looking at parent device '/devices/pci:00/:00:1e.0/:08:00.0': KERNELS==:08:00.0 SUBSYSTEMS==pci udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter1/frontend0) [...] looking at parent device '/devices/pci:00/:00:1e.0/:08:01.0': KERNELS==:08:01.0 SUBSYSTEMS==pci Is it true for all DVB drives that the device with the lower PCI id gets the lower adapter name? -- 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: Order of dvb devices
Devin Heitmueller wrote: On Thu, Jan 14, 2010 at 10:35 AM, Andreas Besse be...@motama.com wrote: if a system contains multiple DVB cards of the same type, how is the order of devices determined by the driver/kernel? I use 2 Technotrend S2-3200 cards in a system and observerd that if I load the driver driver budget_ci manually as follows: modprobe budget_ci adapter_nr=0,1 the device with the lower pci ID :08:00.0 is assigned to adapter0 and the device with the higher pci ID :08:01.0 is assigned to adapter1: udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0) [...] looking at parent device '/devices/pci:00/:00:1e.0/:08:00.0': KERNELS==:08:00.0 SUBSYSTEMS==pci udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter1/frontend0) [...] looking at parent device '/devices/pci:00/:00:1e.0/:08:01.0': KERNELS==:08:01.0 SUBSYSTEMS==pci Is it true for all DVB drives that the device with the lower PCI id gets the lower adapter name? No, you cannot really make this assumption. In fact, there are users who see behavior where uses have two of the same card and the cards get flipped around randomly just by rebooting. The ordering is based on the timing of the device driver loading, so it is not deterministic. yes if there are different drivers I already observed the behaviour that the ordering gets flipped after reboot. But if I assume, that there is only *one* driver that is loaded (e.g. budget_av) for all dvb cards in the system, how is the ordering of these devices determined? How does the driver search for available dvb cards? -- 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
Writing udev reuls for dual tuner devices
Hello,
I use a Media-Pointer MP-S2 Dual DVB-S2 PCIe card with the latest drivers from
the git-Repository
http://projects.vdr-developer.org/repositories/show/mediapointer-dvb-s2 .
I tried to write udev rules to define the adapter names of the tuner to avoid
that the device names could change at boot. It seems not to be possible to
write a udev rule for this dual DVB-S2 device, because there are no attributes
to differentiate between tuner 0 and tuner 1. Attached is the output of
udevinfo.
The following udev rule allows only to define the adapter name of a single
tuner:
SUBSYSTEM==dvb, ATTRS{vendor}==0x18c3, ATTRS{device}==0x0720,
KERNELS==:02:00.0,
PROGRAM=/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter0/%%s $${K#*.}',
SYMLINK+=%c
How can this issue be solved in general? I think the driver should provide an
attribute for each tuner, so that it is possible to write udev rules. How this
has been solved for other Dual Tuner devices like Pinnacle PCTV Dual DVB-T
Diversity, DViCO FusionHDTV DVB-T Dual Express?
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device
'/devices/pci:00/:00:01.0/:01:00.0/dvb/dvb0.frontend0':
KERNEL==dvb0.frontend0
SUBSYSTEM==dvb
DRIVER==
ATTR{dev}==212:2
looking at parent device '/devices/pci:00/:00:01.0/:01:00.0/dvb':
KERNELS==dvb
SUBSYSTEMS==
DRIVERS==
looking at parent device '/devices/pci:00/:00:01.0/:01:00.0':
KERNELS==:01:00.0
SUBSYSTEMS==pci
DRIVERS==ngene
ATTRS{vendor}==0x18c3
ATTRS{device}==0x0720
ATTRS{subsystem_vendor}==0x18c3
ATTRS{subsystem_device}==0xabc4
ATTRS{class}==0x04
ATTRS{irq}==16
ATTRS{local_cpus}==,,,
ATTRS{modalias}==pci:v18C3d0720sv18C3sdABC4bc04sc00i00
ATTRS{enable}==1
ATTRS{broken_parity_status}==0
ATTRS{msi_bus}==
looking at parent device '/devices/pci:00/:00:01.0':
KERNELS==:00:01.0
SUBSYSTEMS==pci
DRIVERS==pcieport-driver
ATTRS{vendor}==0x8086
ATTRS{device}==0x2771
ATTRS{subsystem_vendor}==0x
ATTRS{subsystem_device}==0x
ATTRS{class}==0x060400
ATTRS{irq}==223
ATTRS{local_cpus}==,,,
ATTRS{modalias}==pci:v8086d2771svsdbc06sc04i00
ATTRS{enable}==2
ATTRS{broken_parity_status}==0
ATTRS{msi_bus}==1
looking at parent device '/devices/pci:00':
KERNELS==pci:00
SUBSYSTEMS==
DRIVERS==
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device
'/devices/pci:00/:00:01.0/:01:00.0/dvb/dvb1.frontend0':
KERNEL==dvb1.frontend0
SUBSYSTEM==dvb
DRIVER==
ATTR{dev}==212:5
looking at parent device '/devices/pci:00/:00:01.0/:01:00.0/dvb':
KERNELS==dvb
SUBSYSTEMS==
DRIVERS==
looking at parent device '/devices/pci:00/:00:01.0/:01:00.0':
KERNELS==:01:00.0
SUBSYSTEMS==pci
DRIVERS==ngene
ATTRS{vendor}==0x18c3
ATTRS{device}==0x0720
ATTRS{subsystem_vendor}==0x18c3
ATTRS{subsystem_device}==0xabc4
ATTRS{class}==0x04
ATTRS{irq}==16
ATTRS{local_cpus}==,,,
ATTRS{modalias}==pci:v18C3d0720sv18C3sdABC4bc04sc00i00
ATTRS{enable}==1
ATTRS{broken_parity_status}==0
ATTRS{msi_bus}==
looking at parent device '/devices/pci:00/:00:01.0':
KERNELS==:00:01.0
SUBSYSTEMS==pci
DRIVERS==pcieport-driver
ATTRS{vendor}==0x8086
ATTRS{device}==0x2771
ATTRS{subsystem_vendor}==0x
ATTRS{subsystem_device}==0x
ATTRS{class}==0x060400
ATTRS{irq}==223
ATTRS{local_cpus}==,,,
ATTRS{modalias}==pci:v8086d2771svsdbc06sc04i00
ATTRS{enable}==2
ATTRS{broken_parity_status}==0
ATTRS{msi_bus}==1
looking at parent device '/devices/pci:00':
KERNELS==pci:00
SUBSYSTEMS==
DRIVERS==
Re: Re : cannot rmmod stb0899
Manu wrote: Easiest way to rmmod stb0899 is to go to your v4l-dvb devel directory and do; sudo make unload indeed stb0899 is needed by other drivers (like budget_ci and others). So this command will remove them all. Anyway you need to compile all drivers from the same tree else things will go wrong. thank you for your answer. As you can see in the logs of my first message I tried make rmmod in the v4l-dvb directory. This has the same effect as make unload. The script is not able to unload the drivers (ERROR: Module .. is in use). Any other ideas how to unload the drivers? regards, Andreas Besse -- 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
cannot rmmod stb0899
Hello, I'm using a KNC One TV-Station DVB-S2 Plus and a WinTV-NOVA-CI PCI with the multiprotocol drivers from http://www.jusst.de/hg/multiproto/ (changeset: 7218:2a911b8f9910, date: Wed Jul 09 23:07:29 2008 +0400) The drivers run fine since 250 (!) days, but I have an issue with high cpu load. So I decited to apply the patch Fix High CPU load in 'top' due to budget_av slot polling from Oliver Endriss or try the current v4l tree. First i tried to remove the current drivers. If i call rmmod stb0899 the driver is not removed. Instead an Error ERROR: Module stb0899 is in use is shown (but no application is using the device) I also tried rmmod -w stb0899. This leads to an infinite loop and I'm not able to kill the process. How can I rmmod the stb0899 driver without rebooting the system? How can I kill rmmod -w stb0899? regards, Andreas Besse === output of lsmod: ... tsdev 7968 0 budget_av 24192 1 saa7146_vv 45152 2 budget_av videobuf_dma_sg12996 1 saa7146_vv videobuf_core 17252 2 saa7146_vv,videobuf_dma_sg videodev 26528 2 saa7146_vv v4l2_common17216 2 saa7146_vv,videodev v4l1_compat12516 2 saa7146_vv,videodev firmware_class 9504 2 budget_ci,budget_av budget_core10756 2 budget_ci,budget_av dvb_core 79900 4 budget_ci,stv0299,budget_av,budget_core saa714618248 4 budget_ci,budget_av,saa7146_vv,budget_core ttpci_eeprom2432 1 budget_core ide_cd 36416 0 cdrom 32832 1 ide_cd rtc12856 0 pcspkr 3104 0 intel_agp 23188 1 i2c_i8018656 0 i2c_core 23552 10 budget_ci,stv0299,i2c_isa,tda8261,stb0899,budget_av,v4l2_common,budget_core,ttpci_eeprom,i2c_i801 === output of make rmmod in multiprotocol directory: Mail:~/pakete/multiproto# make rmmod make -C /root/pakete/multiproto/v4l rmmod make[1]: Entering directory `/root/pakete/multiproto/v4l' scripts/rmmod.pl unload found 230 modules /sbin/rmmod budget_av ERROR: Module budget_av is in use /sbin/rmmod budget_ci /sbin/rmmod saa7146_vv ERROR: Module saa7146_vv is in use by budget_av /sbin/rmmod videodev ERROR: Module videodev is in use by saa7146_vv /sbin/rmmod budget_core ERROR: Module budget_core is in use by budget_av /sbin/rmmod stv0299 /sbin/rmmod videobuf_dma_sg ERROR: Module videobuf_dma_sg is in use by saa7146_vv /sbin/rmmod stb0899 ERROR: Module stb0899 is in use /sbin/rmmod v4l1_compat ERROR: Module v4l1_compat is in use by saa7146_vv,videodev /sbin/rmmod dvb_core ERROR: Module dvb_core is in use by budget_av,budget_core /sbin/rmmod tda8261 ERROR: Module tda8261 is in use /sbin/rmmod v4l2_common ERROR: Module v4l2_common is in use by saa7146_vv,videodev /sbin/rmmod videobuf_core ERROR: Module videobuf_core is in use by saa7146_vv,videobuf_dma_sg /sbin/rmmod ir_common /sbin/rmmod saa7146 ERROR: Module saa7146 is in use by budget_av,saa7146_vv,budget_core /sbin/rmmod ttpci_eeprom ERROR: Module ttpci_eeprom is in use by budget_core /sbin/rmmod budget_av ERROR: Module budget_av is in use /sbin/rmmod saa7146_vv ERROR: Module saa7146_vv is in use by budget_av /sbin/rmmod videodev ERROR: Module videodev is in use by saa7146_vv /sbin/rmmod budget_core ERROR: Module budget_core is in use by budget_av /sbin/rmmod videobuf_dma_sg ERROR: Module videobuf_dma_sg is in use by saa7146_vv /sbin/rmmod stb0899 ERROR: Module stb0899 is in use /sbin/rmmod v4l1_compat ERROR: Module v4l1_compat is in use by saa7146_vv,videodev /sbin/rmmod dvb_core ERROR: Module dvb_core is in use by budget_av,budget_core /sbin/rmmod tda8261 ERROR: Module tda8261 is in use /sbin/rmmod v4l2_common ERROR: Module v4l2_common is in use by saa7146_vv,videodev /sbin/rmmod videobuf_core ERROR: Module videobuf_core is in use by saa7146_vv,videobuf_dma_sg /sbin/rmmod saa7146 ERROR: Module saa7146 is in use by budget_av,saa7146_vv,budget_core /sbin/rmmod ttpci_eeprom ERROR: Module ttpci_eeprom is in use by budget_core Couldn't unload: ttpci_eeprom saa7146 videobuf_core v4l2_common tda8261 dvb_core v4l1_compat stb0899 videobuf_dma_sg budget_core videodev saa7146_vv budget_av make[1]: Leaving directory `/root/pakete/multiproto/v4l' === lsmod after make rmmod budget_av 24192 1 saa7146_vv 45152 2 budget_av videobuf_dma_sg12996 1 saa7146_vv videobuf_core 17252 2 saa7146_vv,videobuf_dma_sg videodev 26528 2 saa7146_vv v4l2_common17216 2 saa7146_vv,videodev v4l1_compat12516 2 saa7146_vv,videodev firmware_class 9504 1 budget_av budget_core10756 1 budget_av dvb_core 79900 2 budget_av,budget_core saa714618248 3 budget_av,saa7146_vv,budget_core ttpci_eeprom
