Re: [PATCH RESEND] Revert "media: dvbsky: use just one mutex for serializing device R/W ops"
Dear Mauro,
thanks! Just to clarify, the issue I described in
https://bugzilla.kernel.org/show_bug.cgi?id=199323
was on an Intel x86_64 system, with an onboard USB Controller handled by the
standard xhci driver,
so this does not affect RPi alone.
Cheers and thanks,
Oliver
Am 05.10.18 um 16:26 schrieb Mauro Carvalho Chehab:
> As pointed at:
> https://bugzilla.kernel.org/show_bug.cgi?id=199323
>
> This patch causes a bad effect on RPi. I suspect that the root
> cause is at the USB RPi driver, with uses high priority
> interrupts instead of normal ones. Anyway, as this patch
> is mostly a cleanup, better to revert it.
>
> This reverts commit 7d95fb746c4eece67308f1642a666ea1ebdbd2cc.
>
> Cc: sta...@vger.kernel.org # For Kernel 4.18
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
> Re-sending it with the right message ID
>
> drivers/media/usb/dvb-usb-v2/dvbsky.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c
> b/drivers/media/usb/dvb-usb-v2/dvbsky.c
> index 1aa88d94e57f..e28bd8836751 100644
> --- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
> +++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
> @@ -31,6 +31,7 @@ MODULE_PARM_DESC(disable_rc, "Disable inbuilt IR
> receiver.");
> DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>
> struct dvbsky_state {
> + struct mutex stream_mutex;
> u8 ibuf[DVBSKY_BUF_LEN];
> u8 obuf[DVBSKY_BUF_LEN];
> u8 last_lock;
> @@ -67,17 +68,18 @@ static int dvbsky_usb_generic_rw(struct dvb_usb_device *d,
>
> static int dvbsky_stream_ctrl(struct dvb_usb_device *d, u8 onoff)
> {
> + struct dvbsky_state *state = d_to_priv(d);
> int ret;
> - static u8 obuf_pre[3] = { 0x37, 0, 0 };
> - static u8 obuf_post[3] = { 0x36, 3, 0 };
> + u8 obuf_pre[3] = { 0x37, 0, 0 };
> + u8 obuf_post[3] = { 0x36, 3, 0 };
>
> - mutex_lock(>usb_mutex);
> - ret = dvb_usbv2_generic_rw_locked(d, obuf_pre, 3, NULL, 0);
> + mutex_lock(>stream_mutex);
> + ret = dvbsky_usb_generic_rw(d, obuf_pre, 3, NULL, 0);
> if (!ret && onoff) {
> msleep(20);
> - ret = dvb_usbv2_generic_rw_locked(d, obuf_post, 3, NULL, 0);
> + ret = dvbsky_usb_generic_rw(d, obuf_post, 3, NULL, 0);
> }
> - mutex_unlock(>usb_mutex);
> + mutex_unlock(>stream_mutex);
> return ret;
> }
>
> @@ -606,6 +608,8 @@ static int dvbsky_init(struct dvb_usb_device *d)
> if (ret)
> return ret;
> */
> + mutex_init(>stream_mutex);
> +
> state->last_lock = 0;
>
> return 0;
>
[Regression] DVBSky S960CI hard broken in 4.18
Hi all, sorry to bump this, but I wonder whether I could help by submitting a [PATCH] reverting the buggy change from 7d95fb7 ? As discussed in https://bugzilla.kernel.org/show_bug.cgi?id=199323 , the widespread card is unusable since 7d95fb7 . Please include me in any replies, I am not subscribed to the list. Cheers, Oliver Am 24.09.18 um 22:26 schrieb Oliver Freyermuth: > Dear DVB experts, > > commit: > 7d95fb7 - media: dvbsky: use just one mutex for serializing device R/W ops > hard breaks DVBSky cards. > Also the previous locking commits have caused several runtime issues. > > Since the bug tracker is not regularly checked, I'd love to make everybody > aware of the corresponding issue > with much more detail: > https://bugzilla.kernel.org/show_bug.cgi?id=199323 > which has gotten large attention from several users. > > From my side, I can confirm that reverting 7d95fb7 makes the card work again > for me. on 4.18. > With 7d95fb7 applied, the card tunes fine, but does not deliver any data. > > Please include me in any replies, I am not subscribed to the list. > > Cheers and all the best, > Oliver >
DVBSky S960CI hard broken in 4.18
Dear DVB experts, commit: 7d95fb7 - media: dvbsky: use just one mutex for serializing device R/W ops hard breaks DVBSky cards. Also the previous locking commits have caused several runtime issues. Since the bug tracker is not regularly checked, I'd love to make everybody aware of the corresponding issue with much more detail: https://bugzilla.kernel.org/show_bug.cgi?id=199323 which has gotten large attention from several users. >From my side, I can confirm that reverting 7d95fb7 makes the card work again >for me. on 4.18. With 7d95fb7 applied, the card tunes fine, but does not deliver any data. Please include me in any replies, I am not subscribed to the list. Cheers and all the best, Oliver
m88ds3103 (in a DVBSky S960CI ) loses lock, does not re-gain by itself - unless FE_CAN_RECOVER is removed
Dear DVB-experts, since recently I own a DVBSky S960CI incorporating a m88ds3103. I am on 3.18.2 with two patches from 3.19 in (the S960 CI support + the dvb-usb-dvbsky: fix i2c adapter for sp2 device commit), using firmware 3.B for the m88ds3103. My card is connected to a Quad LNB, to which also two set-top-box receivers and a TV with internal receiver are wired. No extra multiswitch. The card locks fine and has good reception (szap-s2 output): status 1f | signal c4e9 | snr 009a | ber | unc fffe | FE_HAS_LOCK but whenever one of the three other devices connected to the same Quad LNB is turned on / off, the LOCK is lost and not regained unless I explicitly retune, e.g. by restarting szap-s2. Following an intuitive feeling, I removed FE_CAN_RECOVER from the static struct dvb_frontend_ops m88ds3103_ops.info.caps, thus activating the swzigzag-recover method in dvb-frontend.c which seems to be disabled by the CAN_RECOVER capability of a device. After rebuilding my kernel, the card now reacquires the lock by itself following the swzigzag procedure. Below the mail, you can find some debug output I captured with my kernel after removing FE_CAN_RECOVER. Is FE_CAN_RECOVER really true for this device? Is something broken in my setup (the LNB is only a few days old)? Is there a better solution, maybe it would be a good idea to have a generic fallback to swzigzag in any case even for (supposedly) FE_CAN_RECOVER-capable frontends if they do not recover on their own? I would be grateful for any advice on finally getting into a stable situation - I already own one Terratec S7 (for which the driver, or firmware, can not tune to S2 channels, but works fine with the Windows-driver) and an aparently broken TT3650CI which creates broken packages out of nowhere every few seconds (both Windows and Linux) and I am slowly running out of functional DVB-USB (with CI) hardware. Cheers and thanks for any help, Oliver -- $ ./szap-s2 -h -V -c ~/.mpv/channelsS2VDR.conf -r Das Erste HD;ARD -S1 reading channels from file '/home/olifre/.mpv/channelsS2VDR.conf' zapping to 209 'Das Erste HD;ARD': delivery DVB-S2, modulation 8PSK sat 0, frequency 11493 MHz H, symbolrate 2200, coderate 2/3, rolloff 0.35 stream_id -1 vpid 0x13ed, apid 0x13ee, sid 0x283d using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' Filtering for PID= 0x13ed Filtering for PID= 0x13ee status 00 | signal | snr 005a | ber | unc fffe | status 1f | signal c4e9 | snr 009c | ber | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 009c | ber | unc fffe | FE_HAS_LOCK ... putting one of the other receivers in standby ... status 1f | signal c4e9 | snr 009a | ber | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 009a | ber | unc fffe | FE_HAS_LOCK status 00 | signal c4e9 | snr 0075 | ber | unc fffe | status 00 | signal c4e9 | snr 0068 | ber 7e5f | unc fffe | status 00 | signal c4e9 | snr 0068 | ber 7e5f | unc fffe | status 00 | signal c4e9 | snr 0068 | ber 7e5f | unc fffe | status 1f | signal c4e9 | snr 008b | ber 7e5f | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 0096 | ber 7e5f | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 0099 | ber 7e5f | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 009a | ber 0001 | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 009b | ber 0001 | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 0099 | ber 0001 | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 0099 | ber 0001 | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 009a | ber | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 0097 | ber | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 0093 | ber | unc fffe | FE_HAS_LOCK In kernel log with dyndebug on, from when lock was lost: ... Jan 12 19:55:19 alien17 kernel: [ 510.022420] i2c i2c-9: m88ds3103_read_status: lock=8f status=1f Jan 12 19:55:19 alien17 kernel: [ 510.022424] usb 1-1: dvb_frontend_swzigzag_update_delay: Jan 12 19:55:19 alien17 kernel: [ 510.545510] dvb_dmx_swfilter_packet: 46431 callbacks suppressed Jan 12 19:55:19 alien17 kernel: [ 510.545513] TEI detected. PID=0x13f7 data1=0x93 Jan 12 19:55:19 alien17 kernel: [ 510.545514] TEI detected. PID=0x12fb data1=0x92 Jan 12 19:55:19 alien17 kernel: [ 510.545515] TEI detected. PID=0x1c39 data1=0x9c Jan 12 19:55:19 alien17 kernel: [ 510.545516] TEI detected. PID=0xf6f data1=0xcf Jan 12 19:55:19 alien17 kernel: [ 510.545517] TEI detected. PID=0x14 data1=0xc0 Jan 12 19:55:19 alien17 kernel: [ 510.545518] TEI detected. PID=0x1a09 data1=0xba Jan 12 19:55:19 alien17 kernel: [ 510.545519] TEI detected. PID=0xc82 data1=0xec Jan 12 19:55:19 alien17 kernel: [ 510.545520] TEI detected. PID=0x1b5 data1=0xa1 Jan 12 19:55:19
Re: [PATCH] Add support for PCTV452E.
Am 23.07.2011 13:24, schrieb Steffen Barszus: On Tue, 24 May 2011 21:51:22 +0200 Hans Petter Selasky hsela...@c2i.net wrote: NOTES: Sources were taken from the following repositorium as of today: http://mercurial.intuxication.org/hg/s2-liplianin/ And depend on the zig-zag fix posted today. Did a first test on the patch. [ 96.780040] usb 1-8: new high speed USB device using ehci_hcd and address 5 [ 97.376058] dvb_usb_pctv452e: Unknown symbol ttpci_eeprom_decode_mac (err 0) Same here. Looks like this patch didn't make it into patchwork - Mauro can you check that ? I think the patch for ttpci-eeprom.c is missing this: --- linux/drivers/media/dvb/ttpci/ttpci-eeprom.c.orig 2011-07-23 11:00:49.0 + +++ linux/drivers/media/dvb/ttpci/ttpci-eeprom.c2011-07-23 11:04:00.0 + @@ -165,6 +165,7 @@ int ttpci_eeprom_parse_mac(struct i2c_ad } EXPORT_SYMBOL(ttpci_eeprom_parse_mac); +EXPORT_SYMBOL(ttpci_eeprom_decode_mac); MODULE_LICENSE(GPL); MODULE_AUTHOR(Ralph Metzler, Marcus Metzler, others); This patch indeed fixed it for me. Module now loads, detects the card and appears to be successful. However, when I try to tune, syslog shows: Jul 29 02:46:00 sandy kernel: [ 122.986314] pctv452e_power_ctrl: 1 Jul 29 02:46:01 sandy kernel: [ 124.041037] pctv452e: I2C error -121; AA 31 CC 00 01 - 55 31 CC 00 00. Jul 29 02:46:01 sandy kernel: [ 124.056408] pctv452e: I2C error -121; AA 48 CC 00 01 - 55 48 CC 00 00. Jul 29 02:46:01 sandy kernel: [ 124.100998] pctv452e: I2C error -121; AA 63 CC 00 01 - 55 63 CC 00 00. [...cut...] Jul 29 02:46:30 sandy kernel: [ 153.265552] pctv452e: I2C error -121; AA 95 CC 00 01 - 55 95 CC 00 00. Jul 29 02:46:31 sandy kernel: [ 153.812108] pctv452e_power_ctrl: 0 Tuning is not possible here (Kernel 3.0 in use). Anybody with the same issue? Reference for the 'normal' users who just want to use their card: I have now downgraded to 2.6.38 again on my Sandy Bridge board (sacrificing working reboot...) for s2liplianin does not like bkl-removal in 2.6.39 and definitely no 3.0-tree. s2liplianin on 2.6.38 works perfectly with this card. It also has much better support for my other az6027 than the in-tree-modules (still, no signal for any DVB-S2 with the az6027). -- 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
az6027: Terratec S7 has no signal on S2-transponders
Hi all, I use a Terratec S7 MKII with dvb_usb_az6027. DVB-S channels are working fine, but when trying to lock on DVB-S2 channels, the signal level drops to zero. Google and Windows told me this problem is not limited to me, and trying out s2-liplianin, in-kernel drivers of 2.6.38 and media-build.git did not help. As I have this hardware and C-knowledge here, I offer any help that might be needed in tracking down the problem. If there is something like an USB-trace/-sniffing to do (device works fine in Windows-VM), a RTFM with an URL would be fine. Furthermore, scanning Astra S19E2 takes ~90min with w_scan, as compared to 3-5min on Windows, so there appears to be also some problem tuning-related for DVB-S. - If this is the wrong place to ask, please ignore the message and direct me somewhere else. - All help is very much appreciated! Thx -- 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
