Bug 103391

Created attachment 185581 [details]
kaffeine: First not working, then working, then failing completely.

Added the kaffeine log. I am not sure by the way, if I selected the correct component (dvb-core). Thanks in advance.

Should I add linux-media at vger.kernel.org to this bug report?

Created attachment 186011 [details]
Logs of the bug in Kubuntu beta (dmesg, kaffeine, uname, lsusb)

I tried to use the device on Kubuntu (15.10 beta 1), which fails in the same way as in Fedora, so the problem is not Fedora specific. I started the live system, installed kaffeine and performed a channel scan (no channels were found).
I added lsusb and uname output for clearity. Also, I own the device twice, so the problem is not a broken device.

Thank you for the report. I will examine that soon when I found some time - probably during next weekend 29-30.8.2015.

Is it possible to help debugging the issue or do you own the device? I'd like to be helpful. Thanks, again.

I own pretty many different devices having RTL2832U chipset with different tuners on board. Anyhow, I am not able to reproduce the issue. I ran whole last weekend w_scan in a loop, using many different devices. Only once I was able to get IO errors - it was device having e4000 tuner - and after that I haven't get errors even same device and kernel is used.

I suspect it could be some timing issue. Also I suspect it is not very common as I haven't got bug reports to my email.

I have good (bad?) news: I think there is a problem with my USB ports. There are a lot more errors if I put my DVB-T device into my keyboard (which is a USB hub), if the keyboard is plugged in into a special port on the mainboard. I used to watch TV this way.
If I put the DVB-T device directly into another port on the mainboard, there are no errors (or much much less) any more, and I can watch TV again. But if I perform a channel scan, I find not all channels that are in my channel list, and there are sometimes (?) CRC errors (in w_scan, is this a sign that there is something wrong with the device / connection?)
Given the fact that it works now mostly again, I believe that the error is on my side. 
It's interesting that the same problem seems to exist on another computer I have (but access only in a few days).
I cannot remember having those problems with older kernels than 4.0. Maybe also something else changed (USB stuff or something), that caused the USB connection to be more sensitive / temperamental. I used to think that USB does work or does not work, but not "a little bit".

So I am still investigating the issue, but I think this bug can be closed for now.
Thanks for the great work and your time.

I tried watching TV / w_scan on older Ubuntu and Fedora versions and was not able to produce the errors like 

[  268.397802] fc0013: I2C write reg failed, reg: 03, val: d5
[  268.397810] fc0013: fc0013_set_params: failed: -121
[  268.488309] rtl2832 5-0010: i2c reg read failed -71

, independent of the USB port, I was using. If I used the apparently partly broken one, there were "no channels found" (w_scan), but no other errors in dmesg. But I was able to produce those errors by pulling out the device while I was performing a channel scan. For me it still looks like a USB connection problem, which became worse (or visible at all; silent failing on older kernels) with newer kernel versions, but the cause seems to be the USB port. My (usb-hub-)keyboard does no work at all on the broken port, the DVB-T device is recognized correctly (dmesg), but then fails to work in nine times out of ten. If I find out something new, I'll add it in here. Thanks again.

I am also seeing this problem, I can't say for sure when the problem started but I think I have noticed it after the update to linux 4.0.

I am not sure if it coincided with rtl2832_sdr now being loaded, I remember (maybe incorrectly) that it wasn't loaded before.

This is what I see:
[23265.061109] usb 6-3: new high-speed USB device number 8 using ehci-pci
[23265.204940] usb 6-3: dvb_usb_v2: found a 'Dexatek DK DVB-T Dongle' in warm state
[23265.235139] usb 6-3: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[23265.235200] DVB: registering new adapter (Dexatek DK DVB-T Dongle)
[23265.244415] i2c i2c-5: Added multiplexed i2c bus 6
[23265.244431] rtl2832 5-0010: Realtek RTL2832 successfully attached
[23265.244465] usb 6-3: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
[23265.256446] i2c i2c-6: fc0012: Fitipower FC0012 successfully identified
[23265.261869] rtl2832_sdr rtl2832_sdr.0.auto: Registered as swradio0
[23265.261884] rtl2832_sdr rtl2832_sdr.0.auto: Realtek RTL2832 SDR attached
[23265.261890] rtl2832_sdr rtl2832_sdr.0.auto: SDR API is still slightly experimental and functionality changes may follow
[23265.272744] Registered IR keymap rc-empty
[23265.273080] input: Dexatek DK DVB-T Dongle as /devices/pci0000:00/0000:00:13.5/usb6/6-3/rc/rc0/input25
[23265.273447] rc0: Dexatek DK DVB-T Dongle as /devices/pci0000:00/0000:00:13.5/usb6/6-3/rc/rc0
[23265.273758] input: MCE IR Keyboard/Mouse (dvb_usb_rtl28xxu) as /devices/virtual/input/input26
[23265.275898] rc rc0: lirc_dev: driver ir-lirc-codec (dvb_usb_rtl28xxu) registered at minor = 0
[23265.275919] usb 6-3: dvb_usb_v2: schedule remote query interval to 200 msecs
[23265.286959] usb 6-3: dvb_usb_v2: 'Dexatek DK DVB-T Dongle' successfully initialized and connected
[23317.223814] rtl2832 5-0010: invalid bandwidth_hz 0
[23358.170571] i2c i2c-6: fc0012: I2C read reg failed, reg: 0e
[23358.170593] i2c i2c-6: fc0012: fc0012_set_params failed: -121
[23409.219059] i2c i2c-6: fc0012: I2C write reg failed, reg: 01, val: 05
[23409.219080] i2c i2c-6: fc0012: fc0012_set_params failed: -121
[23412.623866] i2c i2c-6: fc0012: I2C read reg failed, reg: 0e
[23412.623888] i2c i2c-6: fc0012: fc0012_set_params failed: -121

The line with invalid bandwidth_hz 0 shows up when I try to open the device with VLC and leave the bandwidth setting in auto, this used to work fine before. The other lines show up when trying a scan with w_scan.

My device (abridged lsusb):
Bus 006 Device 008: ID 1d19:1101 Dexatek Technology Ltd. DK DVB-T Dongle
Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I guess the reason no one reported this problem before is because this is a recent(ish) problem and most users probably are still on an older kernel without this problem. I wanted to try a bisect before submitting a bug report but I'm a bit short on time and this is not very high priority for me as I don't use the device very often, but I'll gladly try any patches or do tests that might help narrow this down.

I am seeing exactly the same issue on various machines/platforms (x86_64 and ARM). All my Chinese rtl2832 based DVB-T sticks (with fc0013 and rt820 tuners) stopped working somewhere on kernel 4. I can mostly initially tune after the stick is plugged in, but later (after several re-tunes) it stops working with I2C write/read reg failures. Then I need to power down the stick and reload the driver to get it working again. It worked fine with kernel 3. I am going to bi-sect.

Something I suspect could be rtl2832 regmap conversion.
For some reason I cannot reproduce the issue...

I made some hacks to remove things I feel could have potential root of cause. First tune is now notably slower as more I2C IO, just wait 10 secs or so. Please test. And if it helps, then bisect correct patch.

http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/log/?h=rtl2832u

(In reply to Antti Palosaari from comment #12)
> I made some hacks to remove things I feel could have potential root of
> cause. First tune is now notably slower as more I2C IO, just wait 10 secs or
> so. Please test. And if it helps, then bisect correct patch.
> 
> http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/log/?h=rtl2832u

Thanks for info, I will check.

In the meantime I set-up testing machine for bisecting on different geographical location (with different DVB-T transmitters), and I am unable to reproduce the issue there with vanilla upstream kernel 4.1.7 (this one didn't work for me). So it is probably related to the channel/mode used. It seems to work for me with Czech DVB-T, doesn't work for me with Croatian and Slovak DVB-T (worked previously). I am going to sort this out.

Created attachment 189211 [details]
w_scan output

The difference in the transmission parameters might be a good clue. Attached is the output of a scan with w_scan I did with the driver I used to use before this stick was natively supported by linux.

Hello, I spent some time to bisect this and came up with
b3b2bf8 [media] rtl2832: disable regmap register cache

I've tried reverting that commit on later kernels and works fine, running 4.3.0-rc3 now. 

my tuner has r820t, lsusb output
Bus 001 Device 008: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

* I'm in Australia.
* I didn't try anttip/media_tree.git yet.

The problem reproduces using anttip/media_tree.git rlt2832u branch. After a bit of playing around I found reverting "c61910d rtl2832: treat all registers a volatile" as well as b3b2bf8 got it working again.

One thing I've noticed after lots of reboots: on kernels that have the problem, *sometimes* the tuner will work if it's left plugged in during reboot but if I re-plug the tuner, it won't work. A kernel with b3b2bf8 reverted works before and after re-plug.

Created attachment 189461 [details]
dvb-usb debug logs

I looked around to see what happens to the register reads/writes and saw the debug message in rtl28xxu_ctrl_msg() so the attached log files are produced with #define DEBUG at the top of drivers/media/usb/dvb-usb-v2/rtl28xxu.c

The sequence of events was:
add #define DEBUG
make && make modules_install
plug in dvb tuner
mplayer -ao sdl -vo sdl "dvb://SBS ONE"
replug
mplayer -ao sdl -vo sdl "dvb://SBS ONE"
replug
mplayer -ao sdl -vo sdl "dvb://SBS ONE"
# this produces log files bad-1.txt bad-2.txt and bad-3.txt

change REGCACHE_NONE to REGCACHE_RBTREE
make && make modules_install
rmmod rtl2832
plug in dvb tuner
mplayer -ao sdl -vo sdl "dvb://SBS ONE"
replug dvb tuner
mplayer -ao sdl -vo sdl "dvb://SBS ONE"
replug dvb tuner
mplayer -ao sdl -vo sdl "dvb://SBS ONE"
# this produces log files good-1.txt good-2.txt good-3.txt

---
* note when mplayer fails, the output is like this
In each case mplayer fails with
+ mplayer -ao sdl -vo sdl 'dvb://SBS ONE'
MPlayer SVN-r37391-5.1.1 (C) 2000-2015 MPlayer Team
do_connect: could not connect to socket
connect: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing dvb://SBS ONE.
dvb_tune Freq: 184500000
dvb_streaming_read, attempt N. 6 failed with errno 0 when reading 4096 bytes
dvb_streaming_read, attempt N. 5 failed with errno 0 when reading 4096 bytes
dvb_streaming_read, attempt N. 4 failed with errno 0 when reading 4096 bytes
dvb_streaming_read, attempt N. 3 failed with errno 0 when reading 4096 bytes
dvb_streaming_read, attempt N. 2 failed with errno 0 when reading 4096 bytes
dvb_streaming_read, attempt N. 1 failed with errno 0 when reading 4096 bytes
dvb_streaming_read, return 0 bytes


Exiting... (End of file)

I found one very potential bug. Please test quickly. Newest patch on that tree
http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/log/?h=rtl2832u_test2

Yep works for me, great!

I have applied the patch on top of linux 4.2.2 and everything works, I don't see errors anymore. Scanning with w_scan also works without a hitch.

I am still seeing "rtl2832 5-0010: invalid bandwidth_hz 0" when using VLC and setting the bandwith to automatic, but it doesn't seem to prevent things from working.

Thanks for fixing this.

(In reply to Mauro Santos from comment #20)
> I am still seeing "rtl2832 5-0010: invalid bandwidth_hz 0" when using VLC
> and setting the bandwith to automatic, but it doesn't seem to prevent things
> from working.

Whole FE_CAN_BANDWIDTH_AUTO parameter is rather useless as I think zero demodulator can auto-detect it. Driver does not set FE_CAN_BANDWIDTH_AUTO capability flag at all, so ideally application should not even try it. And on a case when invalid parameter is given, it should just return error. Now it works with a good luck on some cases (8MHz bandwidth and tuner uses Zero-IF).
But let it be that way even it is wrong to avoid further problems.

Awesome that this seems fixed :)
Thank you all so much. From which kernel version will the fix be included?

It's included in Linux 4.3-rc7.
Thanks! 

http://lkml.iu.edu/hypermail/linux/kernel/1510.3/00159.html