Re: LinuxTV V3 vs. V4 API doc inconsistency, V4 probably wrong
Hi Mauro, First of all, there's no Linux DVB API v4. It was skipped, because there was a proposal for a v4, with was never adopted. Alright, whatever, you have understood it was the post-V3 API, S2API, you name it. You should assign it a version number by the way. Thanks for reviewing it! Yeah, the asterisks there are wrong. The definitions should be, instead: int ioctl(int fd, FE_SET_TONE, enum fe_sec_tone_mode tone) int ioctl(int fd, FE_SET_VOLTAGE, enum fe_sec_voltage voltage) int ioctl(int fd, FE_DISEQC_SEND_BURST, enum fe_sec_mini_cmd tone) As they're passing by value, not by reference[1]. Thanks for the clarification. Feel free to send us fix patches. Do you suggest I should locate the repository, clone it, understand the structure, locate the documentation files, etc? That would take 20 times the time it takes to remove the 3 asterisk characters when you already master the source code as you probably do. I own a few opensource projects on sourceforge and github. When a user reports a problem, whether it is a functional one or a documentation typo, I fix it myself. I do not expect users to do it for me. For those projects, I am the developer and they are the users. I welcome contributions, but I do not demand or even expect them. Cheers -Thierry
LinuxTV V3 vs. V4 API doc inconsistency, V4 probably wrong
Hi, There is an ambiguity in the LinuxTV documentation about the following ioctl's: FE_SET_TONE, FE_SET_VOLTAGE, FE_DISEQC_SEND_BURST. These ioctl's take an enum value as input. In the old V3 API, the parameter is passed by value. In the S2API documentation, it is passed by reference. Most sample programs (a bit old) use the "pass by value" method. V3 documentation: https://www.linuxtv.org/docs/dvbapi/dvbapi.html int ioctl(int fd, int request = FE_SET_TONE, fe_sec_tone_mode_t tone); int ioctl(int fd, int request = FE_SET_VOLTAGE, fe_sec_voltage_t voltage); int ioctl(int fd, int request = FE_DISEQC_SEND_BURST, fe_sec_mini_cmd_t burst); S2API documentation: https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/dvb/frontend_fcalls.html int ioctl(int fd, FE_SET_TONE, enum fe_sec_tone_mode *tone) int ioctl(int fd, FE_SET_VOLTAGE, enum fe_sec_voltage *voltage) int ioctl(int fd, FE_DISEQC_SEND_BURST, enum fe_sec_mini_cmd *tone) Also in: https://www.kernel.org/doc/html/v4.10/media/uapi/dvb/frontend_fcalls.html Which one is correct? If both are correct and the API was changed (I doubt about it), how can we know which one to use? Normally, I would say that the most recent doc is right. However, all sample codes use "by value". Moreover, if the most recent doc was right, then passing by value should fail since the values are zero or close to zero and are not valid addresses. Thanks -Thierry
RE: [linux-media] API V3 vs S2API behavior difference in reading tuning parameters
From: Andreas Oberritter [mailto:o...@linuxtv.org]
Sent: Wednesday, January 19, 2011 7:12 PM
To: Thierry LELEGARD
Cc: linux-media@vger.kernel.org; Devin Heitmueller
Subject: Re: [linux-media] API V3 vs SAPI behavior difference in reading
tuning
parameters
On 01/19/2011 06:03 PM, Thierry LELEGARD wrote:
OK, then what? Is the S2API behavior (returning cached - but incorrect -
tuning
parameter values) satisfactory for everyone or shall we adapt S2API to
mimic the
API V3 behavior (return the actual tuning parameter values as automatically
adjusted by the driver)?
To quote myself:
if that's still the case in Git (I didn't verify), then it should indeed
be changed to behave like v3 does. Would you mind to submit a patch, please?
I haven't heard any objections, so just go on if you want. Otherwise I
might prepare a patch once time permits.
Regards,
Andreas
Sorry for the late follow-up due to busy projects.
Yes, the latest git suffers from the same problem. The values returned
by FE_GET_PROPERTY (S2API) are sometimes wrong while the values returned
by FE_GET_FRONTEND (API V3) are correct, or at least as correct as the
driver can say.
Looking at the code in dvb_frontend.c, the reasons are pretty obvious.
FE_GET_PROPERTY directly returns cached values (at S2API level) while
FE_GET_FRONTEND asks the driver to return values. When the application
sends auto values (xxx_AUTO) or even wrong values that the driver is
able to correct, FE_GET_PROPERTY returns the same auto or wrong values
while FE_GET_FRONTEND returns the values that the driver has discovered
or decided to apply.
FE_GET_PROPERTY returning only cached values:
static int dtv_property_process_get(struct dvb_frontend *fe,
struct dtv_property *tvp,
struct file *file)
{
int r = 0;
/* Allow the frontend to validate incoming properties */
if (fe-ops.get_property)
r = fe-ops.get_property(fe, tvp);
if (r 0)
return r;
switch(tvp-cmd) {
case DTV_FREQUENCY:
tvp-u.data = fe-dtv_property_cache.frequency;
break;
case DTV_MODULATION:
tvp-u.data = fe-dtv_property_cache.modulation;
break;
case DTV_BANDWIDTH_HZ:
tvp-u.data = fe-dtv_property_cache.bandwidth_hz;
break;
...etc...
FE_GET_FRONTEND asking the driver to return its own values:
static int dvb_frontend_ioctl_legacy(struct file *file,
unsigned int cmd, void *parg)
{
...etc...
case FE_GET_FRONTEND:
if (fe-ops.get_frontend) {
memcpy (parg, fepriv-parameters, sizeof (struct
dvb_frontend_parameters));
err = fe-ops.get_frontend(fe, (struct
dvb_frontend_parameters*) parg);
}
break;
...etc...
How to fix this?
For legacy drivers, it is still possible to invoke driver's get_frontend
to get the correct values in a struct dvb_frontend_parameters. But, for
new drivers and new protocols for which some properties cannot be emulated
in a struct dvb_frontend_parameters, I do not see any driver callback to
ask for the value of a property. The callback get_property seems to be
here to validate the usage of a property in the driver's context. As you
can see, dtv_property_process_get simply checks the returned value but
ignore a possible update of the struct dtv_property. Moreover, I have
checked the code of a few drivers implementing get_property and the
general idea is usually simply return 0.
I do think that this problem is a functional regression from API V3 for
most users. But I do not see an obvious and general way of fixing it.
Any idea ?
Best regards,
-Thierry
--
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-media] API V3 vs SAPI behavior difference in reading tuning parameters
Dear all, I would like to report an annoying behavior difference between S2API and the legacy DVB API (V3) when _reading_ the current tuning configuration. In short, API V3 is able to report the _actual_ tuning parameters as used by the driver and corresponding to the actual broadcast steam. On the other hand, S2API reports cached values which were specified in the tuning operation and these values may be generic (*_AUTO symbols) or even wrong. Logically, it seems that the difference is located in the API and not in the driver. Here is the configuration I test: Kernel 2.6.35.10-74.fc14.i686 (Fedora 14) Hauppauge WinTV-Nova-T-500 (dual DVB-T, DiBcom 3000MC/P) I tune to a frequency and let many parameters to their *_AUTO value: DTV_TRANSMISSION_MODE DTV_GUARD_INTERVAL DTV_CODE_RATE_HP DTV_CODE_RATE_LP The tuning is performed correctly and reception is effective. The tuner finds the right parameters. With API V3, after reading the frontend state (FE_GET_FRONTEND), the returned values are correct. I can see that actual code rate HP is 3/4, LP 1/2, transmission mode 8K and guard interval 1/8. However, on the same machine, after reading the frontend state using S2API (FE_GET_PROPERTY), all returned values are the *_AUTO values I specified while tuning. But there is worse. If I set a wrong parameter in the tuning operation, for instance guard interval 1/32, the API V3 returns the correct value which is actually used by the tuner (GUARD_INTERVAL_1_8), while S2API returns the cached value which was set while tuning (GUARD_INTERVAL_1_32). So, the driver is able 1) to find the correct actual parameter and 2) to report this actual value since API V3 returns it. But it seems that API V3 returns the actual tuning parameter as used by the driver while S2API returns a cached value which was used while tuning. This seems an annoying regression. An application is no longer able to determine the modulation parameter of an actual stream. As a final note, there is no difference if the tuning operation is performed using API V3 or S2API, the difference is only in the reading operation (FE_GET_FRONTEND vs. FE_GET_PROPERTY). Best regards, -Thierry -- 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-media] API V3 vs SAPI behavior difference in reading tuning parameters
-Original Message- From: Andreas Oberritter [mailto:o...@linuxtv.org] Sent: Friday, January 14, 2011 5:32 PM Albeit, DVB-SI data isn't perfect and misconfiguration at the transmitter happens (e.g. wrong FEC values), especially where most of the parameters are signaled in-band (e.g. TPS for DVB-T). It's a better user experience if the reception continues to work, even if the user didn't specify AUTO. Exactly. In the French DVB-T network, there is no regional NIT, only one common national NIT. As a consequence, all tuning parameters (frequency but also FEC, guard interval, etc) are wrong in the terrestrial delivery descriptors because for a given TS they are obviously not identical on all transmitters. Moreover, these parameters change over time (many transmitters recently moved from 2/3 - 1/32 to 3/4 - 1/8). In such networks, nobody knows for sure the modulation parameters. This is why it is a good thing that the tuners can 1) find the actual parameters and 2) report them to the application whenever it requests them. I'd rather understand non-AUTO parameters that way: Try these first, but if you want and if you can, you're free to try other parameters. Exactly, for the same reasons as above. This is why the new behavior of S2API (compared to API V3) is quite unfortunate. On a pragmatic standpoint, this is really a major step backward. -Thierry -- 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] new DVB-T initial tuning for fr-nantes
One thing that would be good to do -- for someone who is in the
area served by a transmitter -- rather than use «AUTO» for the
FEC and Guard Interval values above, would be to perform a NIT
scan on the appropriate frequencies.
This should give as a result the actual transmitter frequency
and other parameters in use, and perhaps related ones from other
sites.
These values are configured by the broadcaster and are therefore
not guaranteed to be 100% accurate, but it is more likely that
they know the values they are using -- these values can be used
to locate other transmitter frequencies, as is the well-known
case for DVB-S satellite NIT tables.
Unfortunately, the terrestrial delivery descriptors are completely
wrong in the NIT of the French terrestrial network. The NIT is the
same all over the country, which is not appropriate in a terrestrial
network, and the frequency, FEC and guard interval are wrong. The
same TS will have distinct frequencies (of course) on different
transmitters but also distinct FEC and guard interval (actually,
two combinations are used: either 2/3 1/32 or 3/4 1/8).
Recently, many transmitters have changed the modulation parameters
while staying on the same frequency. It is very difficult to keep
up to date. Between the moment when you submit a patch with the
new parameters and the moment you get the file in your distro,
the parameters may have changed again.
I think that in such a moving environment, the AUTO choice is
definitely better.
-Thierry
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
RE: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2)
I finally gave up using this card. I replaced it with an old Hauppauge WinTV Nova-S in the same PCI slot and the same transponder is received fine. No discontinuity is observed. Using the Nova-HD-S2 in the same PCI slot, on the same transponder, gave a lot of discontinuities, correlated with the pci_abort errors. I think that the Hauppauge WinTV Nova-HD-S2 should be marked as partially supported only since it seems to work fine on some systems and poorly in other systems (mine). -Thierry De : linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] De la part de Thierry LELEGARD Envoyé : vendredi 7 mai 2010 15:49 À : linux-media@vger.kernel.org Objet : RE: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2) Without knowing if this is appropriate or not, as a test, I replaced the 3 occurrences of IRQF_SHARED | IRQF_DISABLED by simply IRQF_SHARED in cx88 driver. The number of pci_abort was considerably reduced but I still get some. Again, this was just a try, not a patch proposal. And it seems not to be a final solution, but it just changed the behavior a little bit. Any other idea ? -Thierry -Message d'origine- De : linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] De la part de Thierry LELEGARD Envoyé : vendredi 7 mai 2010 11:38 À : Paul Shepherd; linux-media@vger.kernel.org Objet : RE: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2) Hi, The firmware version can be seen using dmesg the first time the tuner is actually used after power up. From dmesg: cx24116_firmware_ondemand: Waiting for firmware upload (dvb-fe-cx24116.fw)... cx88-mpeg driver manager :05:05.2: firmware: requesting dvb-fe-cx24116.fw cx24116_firmware_ondemand: Waiting for firmware upload(2)... cx24116_load_firmware: FW version 1.26.90.0 cx24116_firmware_ondemand: Firmware upload complete By removing or swapping cards on the PCI bus, I can see that the number of cx88[0]: irq mpeg [0x8] pci_abort varies. From once every 10 seconds, at best, to once per second, at worst. The following message can be interesting: IRQ 17/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs After some googling, I saw messages mentioning that this kind of message can be the symptom of unexpected behaviors. Could this explain the pci_abort ? Also, some messages suggest that a driver code should not request both IRQF_DISABLED and IRQF_SHARED. In the complete v4l-dvb source code, this combination is found only 20 times, in 12 drivers, including the cx88. Could this be a problem in the driver ? -Thierry -Message d'origine- De : Paul Shepherd [mailto:p...@whitelands.org.uk] Envoyé : jeudi 6 mai 2010 20:59 À : linux-media@vger.kernel.org Cc : Thierry LELEGARD Objet : Re: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2) On 06/05/2010 16:01, Thierry LELEGARD wrote: I recently added a Hauppauge WinTV Nova-HD-S2 into a Linux system. I experience frequent packet loss and pci_abort errors. Each time my application detects packet loss (continuity errors actually), I get the following messages in dmesg: cx88[0]: irq mpeg [0x8] pci_abort* cx88[0]/2-mpeg: general errors: 0x0008 Such problems occur every few seconds. I use firmware file dvb-fe-cx24116.fw version 1.26.90.0. Since the IRQ was shared with the nVidia card and a Dektec modulator, I swapped some PCI boards. The IRQ is still shared but with another Tuner I do not use when using the S2 tuner. After swapping the PCI boards, the errors occur less frequently but still happen. Assuming that the pci_abort was due to an interrupted DMA transfer, I tried to increase the PCI latency timer of the device to 248 but this did not change anything (setpci -s 05:05 latency_timer=f8). I use the tuner with a custom application which reads the complete Transport stream. This application had worked for years using DVB-T and DVB-S tuners. I tried to reduce the application read buffer input size and it did not change anything at all. Note that my application still uses the V3 API, not the S2API. But, using DVB-S transponders, it works (except the pci_abort errors). I disabled the serial port, the parallel port and the PS/2 ports in the BIOS. It did not change anything either. Does anyone have an idea, please? Thanks a lot in advance for any help. -Thierry I have the board working in a Ubuntu 9.10 system, log below shows no pci errors: Apr 21 18:32:11 antec300 kernel: [ 16.576416] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded Apr 21 18:32:11 antec300 kernel: [ 16.576711] cx88[0]: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [card=69,autodetected], frontend(s): 1 Apr 21 18:32:11 antec300
RE: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2)
Hi, The firmware version can be seen using dmesg the first time the tuner is actually used after power up. From dmesg: cx24116_firmware_ondemand: Waiting for firmware upload (dvb-fe-cx24116.fw)... cx88-mpeg driver manager :05:05.2: firmware: requesting dvb-fe-cx24116.fw cx24116_firmware_ondemand: Waiting for firmware upload(2)... cx24116_load_firmware: FW version 1.26.90.0 cx24116_firmware_ondemand: Firmware upload complete By removing or swapping cards on the PCI bus, I can see that the number of cx88[0]: irq mpeg [0x8] pci_abort varies. From once every 10 seconds, at best, to once per second, at worst. The following message can be interesting: IRQ 17/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs After some googling, I saw messages mentioning that this kind of message can be the symptom of unexpected behaviors. Could this explain the pci_abort ? Also, some messages suggest that a driver code should not request both IRQF_DISABLED and IRQF_SHARED. In the complete v4l-dvb source code, this combination is found only 20 times, in 12 drivers, including the cx88. Could this be a problem in the driver ? -Thierry -Message d'origine- De : Paul Shepherd [mailto:p...@whitelands.org.uk] Envoyé : jeudi 6 mai 2010 20:59 À : linux-media@vger.kernel.org Cc : Thierry LELEGARD Objet : Re: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2) On 06/05/2010 16:01, Thierry LELEGARD wrote: I recently added a Hauppauge WinTV Nova-HD-S2 into a Linux system. I experience frequent packet loss and pci_abort errors. Each time my application detects packet loss (continuity errors actually), I get the following messages in dmesg: cx88[0]: irq mpeg [0x8] pci_abort* cx88[0]/2-mpeg: general errors: 0x0008 Such problems occur every few seconds. I use firmware file dvb-fe-cx24116.fw version 1.26.90.0. Since the IRQ was shared with the nVidia card and a Dektec modulator, I swapped some PCI boards. The IRQ is still shared but with another Tuner I do not use when using the S2 tuner. After swapping the PCI boards, the errors occur less frequently but still happen. Assuming that the pci_abort was due to an interrupted DMA transfer, I tried to increase the PCI latency timer of the device to 248 but this did not change anything (setpci -s 05:05 latency_timer=f8). I use the tuner with a custom application which reads the complete Transport stream. This application had worked for years using DVB-T and DVB-S tuners. I tried to reduce the application read buffer input size and it did not change anything at all. Note that my application still uses the V3 API, not the S2API. But, using DVB-S transponders, it works (except the pci_abort errors). I disabled the serial port, the parallel port and the PS/2 ports in the BIOS. It did not change anything either. Does anyone have an idea, please? Thanks a lot in advance for any help. -Thierry I have the board working in a Ubuntu 9.10 system, log below shows no pci errors: Apr 21 18:32:11 antec300 kernel: [ 16.576416] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded Apr 21 18:32:11 antec300 kernel: [ 16.576711] cx88[0]: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [card=69,autodetected], frontend(s): 1 Apr 21 18:32:11 antec300 kernel: [ 16.576714] cx88[0]: TV tuner type -1, Radio tuner type -1 Apr 21 18:32:11 antec300 kernel: [ 16.583565] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded Apr 21 18:32:11 antec300 kernel: [ 16.586270] cx2388x alsa driver version 0.0.7 loaded Apr 21 18:32:11 antec300 kernel: [ 16.605679] EXT4-fs (sda1): internal journal on sda1:8 Apr 21 18:32:11 antec300 kernel: [ 16.755834] EXT4-fs (sdc1): barriers enabled Apr 21 18:32:11 antec300 kernel: [ 16.757791] kjournald2 starting: pid 956, dev sdc1:8, commit interval 5 seconds Apr 21 18:32:11 antec300 kernel: [ 16.763057] EXT4-fs (sdc1): internal journal on sdc1:8 Apr 21 18:32:11 antec300 kernel: [ 16.763061] EXT4-fs (sdc1): delayed allocation enabled Apr 21 18:32:11 antec300 kernel: [ 16.763063] EXT4-fs: file extents enabled Apr 21 18:32:11 antec300 kernel: [ 16.789147] EXT4-fs: mballoc enabled Apr 21 18:32:11 antec300 kernel: [ 16.789163] EXT4-fs (sdc1): mounted filesystem with ordered data mode Apr 21 18:32:11 antec300 kernel: [ 16.795868] tveeprom 2-0050: Hauppauge model 69100, rev B4C3, serial# 7084390 Apr 21 18:32:11 antec300 kernel: [ 16.795871] tveeprom 2-0050: MAC address is 00:0d:fe:6c:19:66 Apr 21 18:32:11 antec300 kernel: [ 16.795874] tveeprom 2-0050: tuner model is Conexant CX24118A (idx 123, type 4) Apr 21 18:32:11 antec300 kernel: [ 16.795876] tveeprom 2-0050: TV standards ATSC/DVB Digital (eeprom 0x80) Apr 21 18:32:11 antec300 kernel: [ 16.795878] tveeprom 2-0050: audio processor is None (idx 0) Apr 21 18:32:11 antec300 kernel
RE: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2)
Without knowing if this is appropriate or not, as a test, I replaced the 3 occurrences of IRQF_SHARED | IRQF_DISABLED by simply IRQF_SHARED in cx88 driver. The number of pci_abort was considerably reduced but I still get some. Again, this was just a try, not a patch proposal. And it seems not to be a final solution, but it just changed the behavior a little bit. Any other idea ? -Thierry -Message d'origine- De : linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] De la part de Thierry LELEGARD Envoyé : vendredi 7 mai 2010 11:38 À : Paul Shepherd; linux-media@vger.kernel.org Objet : RE: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2) Hi, The firmware version can be seen using dmesg the first time the tuner is actually used after power up. From dmesg: cx24116_firmware_ondemand: Waiting for firmware upload (dvb-fe-cx24116.fw)... cx88-mpeg driver manager :05:05.2: firmware: requesting dvb-fe-cx24116.fw cx24116_firmware_ondemand: Waiting for firmware upload(2)... cx24116_load_firmware: FW version 1.26.90.0 cx24116_firmware_ondemand: Firmware upload complete By removing or swapping cards on the PCI bus, I can see that the number of cx88[0]: irq mpeg [0x8] pci_abort varies. From once every 10 seconds, at best, to once per second, at worst. The following message can be interesting: IRQ 17/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs After some googling, I saw messages mentioning that this kind of message can be the symptom of unexpected behaviors. Could this explain the pci_abort ? Also, some messages suggest that a driver code should not request both IRQF_DISABLED and IRQF_SHARED. In the complete v4l-dvb source code, this combination is found only 20 times, in 12 drivers, including the cx88. Could this be a problem in the driver ? -Thierry -Message d'origine- De : Paul Shepherd [mailto:p...@whitelands.org.uk] Envoyé : jeudi 6 mai 2010 20:59 À : linux-media@vger.kernel.org Cc : Thierry LELEGARD Objet : Re: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2) On 06/05/2010 16:01, Thierry LELEGARD wrote: I recently added a Hauppauge WinTV Nova-HD-S2 into a Linux system. I experience frequent packet loss and pci_abort errors. Each time my application detects packet loss (continuity errors actually), I get the following messages in dmesg: cx88[0]: irq mpeg [0x8] pci_abort* cx88[0]/2-mpeg: general errors: 0x0008 Such problems occur every few seconds. I use firmware file dvb-fe-cx24116.fw version 1.26.90.0. Since the IRQ was shared with the nVidia card and a Dektec modulator, I swapped some PCI boards. The IRQ is still shared but with another Tuner I do not use when using the S2 tuner. After swapping the PCI boards, the errors occur less frequently but still happen. Assuming that the pci_abort was due to an interrupted DMA transfer, I tried to increase the PCI latency timer of the device to 248 but this did not change anything (setpci -s 05:05 latency_timer=f8). I use the tuner with a custom application which reads the complete Transport stream. This application had worked for years using DVB-T and DVB-S tuners. I tried to reduce the application read buffer input size and it did not change anything at all. Note that my application still uses the V3 API, not the S2API. But, using DVB-S transponders, it works (except the pci_abort errors). I disabled the serial port, the parallel port and the PS/2 ports in the BIOS. It did not change anything either. Does anyone have an idea, please? Thanks a lot in advance for any help. -Thierry I have the board working in a Ubuntu 9.10 system, log below shows no pci errors: Apr 21 18:32:11 antec300 kernel: [ 16.576416] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded Apr 21 18:32:11 antec300 kernel: [ 16.576711] cx88[0]: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [card=69,autodetected], frontend(s): 1 Apr 21 18:32:11 antec300 kernel: [ 16.576714] cx88[0]: TV tuner type -1, Radio tuner type -1 Apr 21 18:32:11 antec300 kernel: [ 16.583565] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded Apr 21 18:32:11 antec300 kernel: [ 16.586270] cx2388x alsa driver version 0.0.7 loaded Apr 21 18:32:11 antec300 kernel: [ 16.605679] EXT4-fs (sda1): internal journal on sda1:8 Apr 21 18:32:11 antec300 kernel: [ 16.755834] EXT4-fs (sdc1): barriers enabled Apr 21 18:32:11 antec300 kernel: [ 16.757791] kjournald2 starting: pid 956, dev sdc1:8, commit interval 5 seconds Apr 21 18:32:11 antec300 kernel: [ 16.763057] EXT4-fs (sdc1): internal journal on sdc1:8 Apr 21 18:32:11 antec300 kernel: [ 16.763061] EXT4-fs (sdc1): delayed allocation enabled Apr 21 18:32:11 antec300 kernel: [ 16.763063] EXT4-fs: file extents
cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2)
Hello, Does anyone experience pci_abort errors with the cx88 driver? Many thanks -Thierry De : linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] De la part de Thierry LELEGARD Envoyé : mardi 4 mai 2010 16:48 À : linux-...@linuxtv.org; linux-media@vger.kernel.org Objet : [linux-dvb] pci_abort errors with Hauppauge WinTV Nova-HD-S2 Hello, I recently added a Hauppauge WinTV Nova-HD-S2 into a Linux system. I experience frequent packet loss and pci_abort errors. Each time my application detects packet loss (continuity errors actually), I get the following messages in dmesg: cx88[0]: irq mpeg [0x8] pci_abort* cx88[0]/2-mpeg: general errors: 0x0008 Such problems occur every few seconds. I use firmware file dvb-fe-cx24116.fw version 1.26.90.0. Since the IRQ was shared with the nVidia card and a Dektec modulator, I swapped some PCI boards. The IRQ is still shared but with another Tuner I do not use when using the S2 tuner. After swapping the PCI boards, the errors occur less frequently but still happen. Assuming that the pci_abort was due to an interrupted DMA transfer, I tried to increase the PCI latency timer of the device to 248 but this did not change anything (setpci -s 05:05 latency_timer=f8). I use the tuner with a custom application which reads the complete Transport stream. This application had worked for years using DVB-T and DVB-S tuners. I tried to reduce the application read buffer input size and it did not change anything at all. Note that my application still uses the V3 API, not the S2API. But, using DVB-S transponders, it works (except the pci_abort errors). I disabled the serial port, the parallel port and the PS/2 ports in the BIOS. It did not change anything either. Does anyone have an idea, please? Thanks a lot in advance for any help. -Thierry PS: some additional information: # lspci -v -s 05:05 05:05.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) Subsystem: Hauppauge computer works Inc. Device 6906 Flags: bus master, medium devsel, latency 248, IRQ 17 Memory at f500 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Kernel driver in use: cx8800 Kernel modules: cx8800 05:05.1 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05) Subsystem: Hauppauge computer works Inc. Device 6906 Flags: bus master, medium devsel, latency 248, IRQ 17 Memory at f600 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Kernel driver in use: cx88_audio Kernel modules: cx88-alsa 05:05.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) Subsystem: Hauppauge computer works Inc. Device 6906 Flags: bus master, medium devsel, latency 248, IRQ 17 Memory at f700 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Kernel driver in use: cx88-mpeg driver manager Kernel modules: cx8802 05:05.4 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [IR Port] (rev 05) Subsystem: Hauppauge computer works Inc. Device 6906 Flags: bus master, medium devsel, latency 248, IRQ 10 Memory at f800 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 # cat /proc/interrupts CPU0 CPU1 0:296 4 IO-APIC-edge timer 1: 1 2 IO-APIC-edge i8042 8: 1 0 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 16:279 122104 IO-APIC-fasteoi uhci_hcd:usb4, uhci_hcd:usb10, HDA Intel, Dta1xx, nvidia 17: 1863 507353 IO-APIC-fasteoi uhci_hcd:usb5, uhci_hcd:usb8, uhci_hcd:usb11, cx88[0], cx88[0], cx88[0] 18: 130224 8533 IO-APIC-fasteoi ehci_hcd:usb3, uhci_hcd:usb9 22: 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb6 23: 170156246 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb7 28: 57235 4517 PCI-MSI-edge ahci 29: 69 15965 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC:25290232281329 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts PND: 0 0 Performance pending work RES: 42023 29529 Rescheduling interrupts CAL:123994 Function call interrupts TLB: 150508 136321 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0
[linux-dvb] pci_abort errors with Hauppauge WinTV Nova-HD-S2
Hello, I recently added a Hauppauge WinTV Nova-HD-S2 into a Linux system. I experience frequent packet loss and pci_abort errors. Each time my application detects packet loss (continuity errors actually), I get the following messages in dmesg: cx88[0]: irq mpeg [0x8] pci_abort* cx88[0]/2-mpeg: general errors: 0x0008 Such problems occur every few seconds. I use firmware file dvb-fe-cx24116.fw version 1.26.90.0. Since the IRQ was shared with the nVidia card and a Dektec modulator, I swapped some PCI boards. The IRQ is still shared but with another tuner I do not use when using the S2 tuner. After swapping the PCI boards, the errors occur less frequently but still happen. Assuming that the pci_abort was due to an interrupted DMA transfer, I tried to increase the PCI latency timer of the device to 248 but this did not change anything (setpci -s 05:05 latency_timer=f8). I use the tuner with a custom application which reads the complete transport stream. This application had worked for years using DVB-T and DVB-S tuners. I tried to reduce the application read buffer input size and it did not change anything at all. Note that my application still uses the V3 API, not the S2API. But, using DVB-S transponders, it works (except the pci_abort errors). I disabled the serial port, the parallel port and the PS/2 ports in the BIOS. It did not change anything either. Does anyone have an idea, please? Thanks a lot in advance for any help. -Thierry PS: some additional information: # lspci -v -s 05:05 05:05.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) Subsystem: Hauppauge computer works Inc. Device 6906 Flags: bus master, medium devsel, latency 248, IRQ 17 Memory at f500 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Kernel driver in use: cx8800 Kernel modules: cx8800 05:05.1 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05) Subsystem: Hauppauge computer works Inc. Device 6906 Flags: bus master, medium devsel, latency 248, IRQ 17 Memory at f600 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Kernel driver in use: cx88_audio Kernel modules: cx88-alsa 05:05.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) Subsystem: Hauppauge computer works Inc. Device 6906 Flags: bus master, medium devsel, latency 248, IRQ 17 Memory at f700 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Kernel driver in use: cx88-mpeg driver manager Kernel modules: cx8802 05:05.4 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [IR Port] (rev 05) Subsystem: Hauppauge computer works Inc. Device 6906 Flags: bus master, medium devsel, latency 248, IRQ 10 Memory at f800 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 # cat /proc/interrupts CPU0 CPU1 0:296 4 IO-APIC-edge timer 1: 1 2 IO-APIC-edge i8042 8: 1 0 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 16:279 122104 IO-APIC-fasteoi uhci_hcd:usb4, uhci_hcd:usb10, HDA Intel, Dta1xx, nvidia 17: 1863 507353 IO-APIC-fasteoi uhci_hcd:usb5, uhci_hcd:usb8, uhci_hcd:usb11, cx88[0], cx88[0], cx88[0] 18: 130224 8533 IO-APIC-fasteoi ehci_hcd:usb3, uhci_hcd:usb9 22: 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb6 23: 170156246 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb7 28: 57235 4517 PCI-MSI-edge ahci 29: 69 15965 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC:25290232281329 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts PND: 0 0 Performance pending work RES: 42023 29529 Rescheduling interrupts CAL:123994 Function call interrupts TLB: 150508 136321 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP: 16 16 Machine check polls ERR: 1 MIS: 0 -- 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] Anysee E30 C Plus + MPEG-4?
Pásztor Szilárd: With scan -vv I could find the video PIDs for the HD channels and indeed they were missing in my channels.conf (values were 0) as scan detected them as OTHER, but with a type 0x1b addition with which I don't know what to do for the time being... Stream type 0x1B precisely means AVC / H.264 video stream (cf. ISO 138181-1:2000/FDAM 3) Try VLC instead of mplayer. VLC does render H.264 HD video, provided you have a (very) good CPU. -Thierry -- 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 : Hauppauge Nova-TD-500 vs. T-500
I have a few more informations. 1) Sorry for those who don't like top posting, but the initial description is really too long for good readability of answers. 2) Since the TD-500 contains two aerial inputs instead of one for the T-500, I plugged in two antenna cables. Then, after some tests, I realized that this was a source of trouble: - Two antenna cables = lots of errors (mostly garbage sometimes, depending on the frequency). - Top input only = still many errors but much better on both tuners. - Bottom input only = got nothing on both tuners. So, from now on, I use only one antenna cable, in the top aerial input. Maybe this could be clarified somewhere (unless it is already but I missed it). 3) There are still many uncorrectable errors (TS packets with transport error indicator set) in the input. The amount of uncorrectable errors is approximately 0.1% (depending on the frequency), while I do not have any with the T-500 using the same antenna. These errors occurs in groups of +/- 50 consecutive packets with TEI set. Sometimes, in the middle of packets with errors, one packet has TEI clear but it is still erroneous (invalid PID in this context for instance). Note: I forgot to mention in the initial post that I set the following option: options dvb_usb_dib0700 force_lna_activation=1 4) There is apparently a minor but annoying problem in the driver concerning the ioctl FE_GET_INFO. Its usage requires opening the frontend device in O_RDWR mode with the TD-500. Comparison of T-500 vs. TD-500. a) After boot, before the first tuning, if we open the frontend in O_RDONLY more, the ioctl FE_GET_INFO succeeds with the TD-500 and the T-500. b) While another process uses the frontend for packet reception, the ioctl FE_GET_INFO succeeds with the TD-500 and the T-500, with frontend in O_RDONLY mode. c) After the frontend has been used for packet reception but no other process uses it any longer, the ioctl FE_GET_INFO fails with errno no such device with TD-500 frontend in O_RDONLY mode. However, the ioctl FE_GET_INFO succeeds with TD-500 frontend in O_RDWR mode. With the T-500, the ioctl FE_GET_INFO succeeds in O_RDONLY mode. Using O_RDWR mode for a simple ioctl FE_GET_INFO is a problem since it fails with device busy when another process is using it in O_RDWR mode for tuning and reception, which is normal. I see here two inconsistencies and one annoying feature: - Inconsistent behaviour of ioctl FE_GET_INFO in O_RDONLY mode before and after the first tuning. - Incorrect error no such device because /dev/dvb/adapter0/frontend0 is still there and useable in O_RDWR mode. - Obligation to use O_RDWR mode for reading the characteristics of a device. -Thierry -Message d'origine- De : linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] De la part de Thierry Lelegard Envoyé : lundi 18 mai 2009 16:33 À : linux-media@vger.kernel.org Objet : Hauppauge Nova-TD-500 vs. T-500 Hello, Like many others, I have some problems with the Hauppauge Nova-TD-500. I have been running a Fedora system with one Hauppauge Nova-T-500 (-T-, with one input connector, not -TD-) quite successfully for 2 years. I just built another Fedora system and ordered two T-500 but I actually received two TD-500 (the one with two input connectors). So, I now have another Fedora box with two Hauppauge Nova-TD-500 and it does not work quite well. The two systems (the first one with one T-500 and the second one with two TD-500) are running the same O/S version, same drivers, same firmware: - Fedora 10, up-to-date as of 2009-05-17 - Kernel 2.6.27.21-170.2.56.fc10.i686 - Latest V4L-DVB mercurial tree, same date - Firmware dvb-usb-dib0700-1.20.fw You will find below some outputs of dmesg, lspci, etc for the two systems. I use custom signal monitoring applications, no TV watching apps. The same application is used in both systems, same antenna input (roof antenna and wall socket, not the small antenna that comes with the cards). The application continuously reads the complete transport stream for analysis. From time to time, it tunes to some frequency, then another, etc. With the two TD-500, the 4 adapters are created under /dev/dvb. Using them works more or less. As far as I tested now, I do not have any reported error, no error message. But the input is not good: many packets are corrupted. This does not happen all the time. Sometimes, the input is reasonably correct (a few packets seems incorrect) and sometimes it is a mess (most packets are incorrect, the result of the analysis report many non-existing PIDs, weird content, etc). I guess that most of you will say most probably an application pb... But the same application is working fine with: 1) Linux + Hauppauge Nova-T-500 2) Linux + Hauppauge Nova-T Stick 3) Linux + Pinnacle PCTV stick 72e 4) Windows + the two above sticks 4
Hauppauge Nova-TD-500 vs. T-500
Hello, Like many others, I have some problems with the Hauppauge Nova-TD-500. I have been running a Fedora system with one Hauppauge Nova-T-500 (-T-, with one input connector, not -TD-) quite successfully for 2 years. I just built another Fedora system and ordered two T-500 but I actually received two TD-500 (the one with two input connectors). So, I now have another Fedora box with two Hauppauge Nova-TD-500 and it does not work quite well. The two systems (the first one with one T-500 and the second one with two TD-500) are running the same O/S version, same drivers, same firmware: - Fedora 10, up-to-date as of 2009-05-17 - Kernel 2.6.27.21-170.2.56.fc10.i686 - Latest V4L-DVB mercurial tree, same date - Firmware dvb-usb-dib0700-1.20.fw You will find below some outputs of dmesg, lspci, etc for the two systems. I use custom signal monitoring applications, no TV watching apps. The same application is used in both systems, same antenna input (roof antenna and wall socket, not the small antenna that comes with the cards). The application continuously reads the complete transport stream for analysis. From time to time, it tunes to some frequency, then another, etc. With the two TD-500, the 4 adapters are created under /dev/dvb. Using them works more or less. As far as I tested now, I do not have any reported error, no error message. But the input is not good: many packets are corrupted. This does not happen all the time. Sometimes, the input is reasonably correct (a few packets seems incorrect) and sometimes it is a mess (most packets are incorrect, the result of the analysis report many non-existing PIDs, weird content, etc). I guess that most of you will say most probably an application pb... But the same application is working fine with: 1) Linux + Hauppauge Nova-T-500 2) Linux + Hauppauge Nova-T Stick 3) Linux + Pinnacle PCTV stick 72e 4) Windows + the two above sticks 4) Windows + Terratec Cinergy T USB XE Rev 2 (not supported on Linux) Of course, on Windows, the input module is a custom DirectShow capture filter instead of Linux DVB API but the rest of the application is identical. Another weird behaviour: After running the monitoring application, ioctl (frontend_fd, FE_GET_INFO, ...) returns No such device errno. Example: 1) Run tool to get dvb device info, ie. ioctl FE_GET_INFO, right after system boot: /dev/dvb/adapter0 (DiBcom 7000PC, DVB-T) Status: Bit error rate . 2,097,151 (0%) Signal/noise ratio . 0 (0%) Signal strength 0 (0%) Uncorrected blocks . 0 Frequencies: Current .. 0 Hz Min . 45,000,000 Hz Max 860,000,000 Hz Step 62,500 Hz Tolerance 0 Hz Spectral inversion .. auto Bandwidth .. 8-MHz FEC (high priority) .. 1/2 FEC (low priority) ... 1/2 Constellation ... QPSK Transmission mode . 2K Guard interval .. 1/32 Hierarchy ... none 2) Run monitoring application. OK, with corrupted packets. 3) Run previous tool doing ioctl FE_GET_INFO: error getting info on /dev/dvb/adapter0/frontend0: No such device Note: this error is reported by ioctl, opening the device is OK. 4) # ls -l /dev/dvb/adapter0/frontend0 crw-rw+ 1 tlelegard video 212, 3 2009-05-18 15:59 /dev/dvb/adapter0/frontend0 5) Run monitoring application. OK, with corrupted packets. Is there any new development regarding TD-500 ? Any test I could make ? Thanks in advance for your assistance. -Thierry - dmesg - one T-500 - # dmesg | grep -i -e dvb -e dib dib0700: loaded with support for 9 different device-types dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try to load a firmware firmware: requesting dvb-usb-dib0700-1.20.fw dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' dib0700: firmware started successfully. dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) DVB: registering adapter 0 frontend 0 (DiBcom 3000MC/P)... dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) DVB: registering adapter 1 frontend 0 (DiBcom 3000MC/P)... dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected. usbcore: registered new interface driver
