Most recent kernel where this bug did *NOT* occur: it did never really work Distribution: debian etch Hardware Environment: intel asus a7v8x, hauppage wintv-nova-t or hama dvb-t Problem Description: After about 5hrs of correct functioning, the usb dvb-t device suddenly gets disconnected from the usb port (usb 1-3: USB disconnect, address 6 in dmesg). Then any access to the device fails with: mt2060 I2C read failed mt2060 I2C write failed Here is the relevant dmesg output. Please note that this problem happens with the hauppage aswell as the hama dvb-t dongle in different usb ports with 2 different psu's delivering much more power than necessary. So I guess this happens with *any* dib0700 based device. Also note that this is 100% reproducable in my vdr setup. Vdr itself runs nicely when only the full featured+budget dvb-c/dvb-t pci cards are used. This happens with 2.6.20 and also with 2.6.19.3 + v4l-dvb-stable as from 10.02.2007 ( hg clone http://linuxtv.org/hg/~mrechberger/v4l-dvb-stable ). This may also result in oopses as the dvb-core does not like devices to vanish... I will happily help debugging - but need guidance. usb 1-3: new high speed USB device using ehci_hcd and address 6 usb 1-3: configuration #1 chosen from 1 choice dib0700: loaded with support for 2 different device-types dvb-usb: found a 'Uniwill STK7700P based (Hama and others)' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-dib0700-01.fw' dib0700: firmware started successfully. dvb-usb: found a 'Uniwill STK7700P based (Hama and others)' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Uniwill STK7700P based (Hama and others)). DVB: registering frontend 2 (DiBcom 7000MA/MB/PA/PB/MC)... MT2060: successfully identified (IF1 = 1220) usb 1-1: USB disconnect, address 2 dvb-usb: Uniwill STK7700P based (Hama and others) successfully initialized and connected. usbcore: registered new interface driver dvb_usb_dib0700 tda1004x: found firmware revision 2c -- ok [5 hrs later] usb 1-3: USB disconnect, address 6 mt2060 I2C write failed (len=2) mt2060 I2C write failed (len=6) mt2060 I2C read failed mt2060 I2C read failed mt2060 I2C read failed mt2060 I2C read failed mt2060 I2C read failed mt2060 I2C read failed mt2060 I2C read failed mt2060 I2C read failed mt2060 I2C read failed mt2060 I2C read failed mt2060 I2C write failed (len=2) mt2060 I2C write failed (len=6) Steps to reproduce: Try to use the dongle for more than just a few hours.
Hi, please test http://mcentral.de/hg/~mrec/v4l-dvb-experimental I added some hotplugging fixes which prevents a crash of the dvb framework. Markus
Is there a seperate patch for this issue available ? I am now on 2.6.21 (same problem) and tried downloaded the experimental branch (7th of May) and basically immediately got an oops (after starting some recordings): BUG: unable to handle kernel NULL pointer dereference at virtual address 000001e0 printing eip: f9baa030 *pde = 00000000 Oops: 0000 [#1] PREEMPT Modules linked in: mt2060 dvb_usb_a800 dvb_usb_dibusb_common dib3000mc dibx000_common dvb_usb dvb_pll tda1004x budget_ci budget_core dvb_ttpci dvb_core saa7146_vv video_buf saa7146 videodev v4l2_common v4l1_compat ttpci_eeprom ves1820 ipt_iprange ipt_REDIRECT lirc_serial lirc_dev ipt_REJECT xt_tcpudp xt_state xt_limit ipt_LOG ipt_MASQUERADE iptable_mangle iptable_nat nf_conntrack_ipv4 iptable_filter ip_tables x_tables capi capifs capidrv isdn nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack lcd eth1394 usb_storage usblp b44 e1000 fcpci(P) kernelcapi ir_common via_agp agpgart ohci1394 ieee1394 CPU: 0 EIP: 0060:[<f9baa030>] Tainted: P VLI EFLAGS: 00010286 (2.6.21.1 #2) EIP is at philips_cd1516_tuner_set_params+0x10/0xb0 [dvb_ttpci] eax: f7d74d14 ebx: 00000000 ecx: 177bf680 edx: f5abdefc esi: 0000f424 edi: f5abdf2c ebp: f7d74c00 esp: f5abde78 ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068 Process kdvb-fe-0 (pid: 15166, ti=f5abc000 task=f351f070 task.ti=f5abc000) Stack: c012c6f8 f7f4eda0 0000000b f99933c5 f7d74c08 c1f54428 f5abdf2c f9933535 00000000 f300f004 00000000 f351f070 c1f54404 f9baa020 00000002 f300f008 00000000 00000001 00000000 f9993ae4 f5abdf3c ffffffff c0273d20 00000001 Call Trace: [<c012c6f8>] finish_wait+0x4c/0x64 [<f99933c5>] saa7146_i2c_writeout+0x174/0x47f [saa7146] [<f9933535>] ves1820_set_parameters+0xc0/0x54b [ves1820] [<f9baa020>] philips_cd1516_tuner_set_params+0x0/0xb0 [dvb_ttpci] [<f9993ae4>] saa7146_i2c_transfer+0x414/0x42b [saa7146] [<c0273d20>] vsnprintf+0x46d/0x4a9 [<f9baac55>] av7110_fe_set_frontend+0x39/0x3d [dvb_ttpci] [<f9a93804>] dvb_frontend_swzigzag_autotune+0x1ab/0x1d8 [dvb_core] [<c0123252>] del_timer+0x43/0x5c [<f9a93ff4>] dvb_frontend_swzigzag+0x1a4/0x202 [dvb_core] [<f9a94347>] dvb_frontend_thread+0x212/0x2ad [dvb_core] [<c012c63b>] autoremove_wake_function+0x0/0x35 [<f9a94135>] dvb_frontend_thread+0x0/0x2ad [dvb_core] [<c012c57f>] kthread+0xa0/0xc9 [<c012c4df>] kthread+0x0/0xc9 [<c010486b>] kernel_thread_helper+0x7/0x10 ======================= Code: 00 00 00 e8 aa 74 79 c6 48 0f 94 c0 83 c4 14 5b 5e 5f 5d 0f b6 c0 8d 44 80 fb c3 57 56 be 24 f4 00 00 53 83 ec 10 8b 58 08 8b 0a <8b> 83 e0 01 00 00 8d 91 5a b3 27 02 8b 78 20 8d 44 24 0c 66 c7 EIP: [<f9baa030>] philips_cd1516_tuner_set_params+0x10/0xb0 [dvb_ttpci] SS:ESP 0068:f5abde78 BUG: unable to handle kernel NULL pointer dereference at virtual address 000001ec printing eip: f9a84423 *pde = 00000000 Oops: 0000 [#2] PREEMPT Modules linked in: mt2060 dvb_usb_a800 dvb_usb_dibusb_common dib3000mc dibx000_common dvb_usb dvb_pll tda1004x budget_ci budget_core dvb_ttpci dvb_core saa7146_vv video_buf saa7146 videodev v4l2_common v4l1_compat ttpci_eeprom ves1820 ipt_iprange ipt_REDIRECT lirc_serial lirc_dev ipt_REJECT xt_tcpudp xt_state xt_limit ipt_LOG ipt_MASQUERADE iptable_mangle iptable_nat nf_conntrack_ipv4 iptable_filter ip_tables x_tables capi capifs capidrv isdn nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack lcd eth1394 usb_storage usblp b44 e1000 fcpci(P) kernelcapi ir_common via_agp agpgart ohci1394 ieee1394 CPU: 0 EIP: 0060:[<f9a84423>] Tainted: P VLI EFLAGS: 00010292 (2.6.21.1 #2) EIP is at dvb_pll_set_params+0x11/0x9e [dvb_pll] eax: f433a90c ebx: f9a84412 ecx: f363def4 edx: f363def4 esi: 00000000 edi: ffffffea ebp: f7e52404 esp: f363debc ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068 Process kdvb-fe-2 (pid: 15176, ti=f363c000 task=f5ae8ad0 task.ti=f363c000) Stack: 00000000 01000000 001c0000 0060fba5 01e39c25 f9a84412 f7e52428 f363df24 f7e52404 f9b69479 00008000 f3308000 f433a800 f433a800 0b6a0ee0 00000004 00000000 00000000 00000000 00000001 00000002 00000001 00000001 00000001 Call Trace: [<f9a84412>] dvb_pll_set_params+0x0/0x9e [dvb_pll] [<f9b69479>] dib3000mc_set_frontend+0x172/0x439 [dib3000mc] [<f9a93804>] dvb_frontend_swzigzag_autotune+0x1ab/0x1d8 [dvb_core] [<c0118352>] __wake_up_locked+0x1f/0x21 [<c03db69d>] __down_interruptible+0x102/0x125 [<f9a93ff4>] dvb_frontend_swzigzag+0x1a4/0x202 [dvb_core] [<f9a94347>] dvb_frontend_thread+0x212/0x2ad [dvb_core] [<c012c63b>] autoremove_wake_function+0x0/0x35 [<f9a94135>] dvb_frontend_thread+0x0/0x2ad [dvb_core] [<c012c57f>] kthread+0xa0/0xc9 [<c012c4df>] kthread+0x0/0xc9 [<c010486b>] kernel_thread_helper+0x7/0x10 ======================= Code: 78 10 8b 03 88 45 00 89 53 0c ba 05 00 00 00 89 73 10 89 d0 5a 5b 5e 5f 5d c3 55 89 d1 57 bf ea ff ff ff 56 53 83 ec 14 8b 70 08 <8b> 9e ec 01 00 00 8b 03 66 c7 44 24 06 00 00 66 c7 44 24 08 04 EIP: [<f9a84423>] dvb_pll_set_params+0x11/0x9e [dvb_pll] SS:ESP 0068:f363debc
Soeren, You can now test with 2.6.22-rc5. All latest development patches from DVB tree were picked up there, including ones in #1 (right, Marcus?) Thanks.
I submitted a patch to not oops anymore when disconnecting the device, although the device still disconnects due a bad dib0700 driver and firmware incompatibilities. With the latest drivers it's sufficient to restart the DVB application as soon as a disconnect happens. Markus
There were some fixes on dib0700 driver, available at both -git and -hg trees. Please, test with the latest v4l-dvb tree: http://linuxtv.org/hg/v4l-dvb
I already did (including the new firmware dvb-usb-dib0700-03-pre1.fw). Oopses are fixed but still the same disconnect problem :-(
This is not a kernel bug but a hardware problem. And in the worst case, there is nothing which can be done in source code to prevent the disconnect. Is this the right place to discuss about it, then?
If I read this correctly all dib0700 based devices have a hardware problem causing this bug. This includes the many usb-dongles and also the nova-t 500. In this case the bug can be closed and the driver should be marked unstable and of course dib* be avoided (don't buy if you want to use it w/ linux).
I said "in the worst case" - meaning we have not yet figured out where exactly is the problem. We see that the disconnects are comming only with some devices (not all of our ref-designs are affected) on some USB hosts and under some circumstances. Unfortunately this list is far from being complete.
It would be great if the devices known working are listed somewhere and/or when the driver loads a warning would be printed for devices not in this 'whitelist'.
I have the AverMedia Volar (usb, dvb-t) and the Haupagge nova-t-500, both with this driver. The AverMedia works fine, over weeks, never had a problem. The nova-t-500 was buggy but with lastest drivers I only had one isue that I had to reboot to make it work 3 weeks ago, nothing since then.
I have a Hauppauge WinTV Nova-T-500 and I am experiencing this problem frequently, so I would very much like to do what I can to help fix it. If anyone needs any further information or has any suggestions as to what I can do, please contact me. Thanks.
the Hama DVB-T USB 2.0 Stick, WinTV-Nova-T-Stick and AverMedia DVB-T USB 2.0 also have this problem.
I'm noticing unrecoverable problems when the signal quality drops. Running: Nova T 500 PCI Debian 2.6.22-1 (etch) HG drivers 2007-08-26 Nova T 500 Firmware 03-beta1 Normal working output: beastie:~# tzap -a 0 "ABC TV Melbourne" using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 226500000 Hz video pid 0x0200, audio pid 0x028a status 07 | signal 8cd6 | snr 0000 | ber 001fffff | unc 00000022 | status 1f | signal 8d1e | snr 0000 | ber 00000b90 | unc 00000038 | FE_HAS_LOCK status 1f | signal 8d06 | snr 0000 | ber 00000670 | unc 0000002f | FE_HAS_LOCK status 1f | signal 8d14 | snr 0000 | ber 00000100 | unc 0000002f | FE_HAS_LOCK status 1f | signal 8d12 | snr 0000 | ber 00005af0 | unc 00000000 | FE_HAS_LOCK status 1f | signal 8d1a | snr 0000 | ber 000005d0 | unc 00000108 | FE_HAS_LOCK status 1f | signal 8d1d | snr 0000 | ber 00000310 | unc 00000000 | FE_HAS_LOCK status 1f | signal 8d1e | snr 0000 | ber 000005f0 | unc 00000000 | FE_HAS_LOCK status 1f | signal 8d77 | snr 0000 | ber 00000160 | unc 00000000 | FE_HAS_LOCK Created problem by turning down amplifier on antenna, then turning it back on to its original position. This then created problems locking onto a channel in Mythtv. tzap output shows: beastie:~# tzap -a 0 "ABC TV Melbourne" using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 226500000 Hz video pid 0x0200, audio pid 0x028a status 1f | signal 820c | snr 0000 | ber 001fffff | unc 00000011 | FE_HAS_LOCK status 1f | signal 8268 | snr 0000 | ber 0001b5b0 | unc 00000db5 | FE_HAS_LOCK status 1f | signal 8231 | snr 0000 | ber 00017a80 | unc 00000000 | FE_HAS_LOCK status 1f | signal 8219 | snr 0000 | ber 0001d500 | unc 00000000 | FE_HAS_LOCK status 1f | signal 8221 | snr 0000 | ber 0001ea70 | unc 00000000 | FE_HAS_LOCK status 1f | signal 823a | snr 0000 | ber 00022b80 | unc 00000000 | FE_HAS_LOCK Problem still occurred with a reboot, only way to fix it was with a cold boot.
Is this one fixed ?
I am not sure. I don't have this same hardware setup anymore. However yesterday I tried with a win tv usb 2.0 dongle and kaffeine over night and it seemed to work... For the record, firmware was dvb-usb-dib0700-1.10.fw on 2.6.27-rc7.
Re-open if this turns out not to be fixed