Bug 7986 - dvb_usb_dib0700 based devices get disconnected from usb bus
dvb_usb_dib0700 based devices get disconnected from usb bus
Status: CLOSED CODE_FIX
Product: v4l-dvb
Classification: Unclassified
Component: dvb-usb
i386 Linux
: P2 high
Assigned To: Mauro Carvalho Chehab
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-11 11:01 UTC by Soeren Sonnenburg
Modified: 2008-12-22 09:52 UTC (History)
9 users (show)

See Also:
Kernel Version: 2.6.19.3+ dvb-stable or 2.6.20
Tree: Mainline
Regression: ---


Attachments

Description Soeren Sonnenburg 2007-02-11 11:01:00 UTC
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.
Comment 1 Markus Rechberger 2007-04-05 05:07:17 UTC
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
Comment 2 Soeren Sonnenburg 2007-05-07 00:55:53 UTC
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
Comment 3 Natalie Protasevich 2007-06-21 22:38:12 UTC
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.
Comment 4 Markus Rechberger 2007-06-22 05:34:04 UTC
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
Comment 5 Mauro Carvalho Chehab 2007-08-20 12:31:53 UTC
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
Comment 6 Soeren Sonnenburg 2007-08-20 12:39:43 UTC
I already did (including the new firmware dvb-usb-dib0700-03-pre1.fw). Oopses are fixed but still the same disconnect problem :-(
Comment 7 Patrick Boettcher 2007-08-22 03:07:51 UTC
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?
Comment 8 Soeren Sonnenburg 2007-08-22 03:17:11 UTC
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).
Comment 9 Patrick Boettcher 2007-08-22 04:28:54 UTC
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.

Comment 10 Soeren Sonnenburg 2007-08-22 05:06:52 UTC
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'.
Comment 11 Hugo 2007-08-23 05:06:05 UTC
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.
Comment 12 Nick Griffiths 2007-08-30 04:23:35 UTC
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.
Comment 13 Soeren Sonnenburg 2007-08-30 04:44:55 UTC
the Hama DVB-T USB 2.0 Stick, WinTV-Nova-T-Stick and AverMedia DVB-T USB 2.0 also have this problem.
Comment 14 Dan Harper 2007-09-23 21:18:05 UTC
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.
Comment 15 Alan 2008-09-24 11:15:11 UTC
Is this one fixed ?
Comment 16 Soeren Sonnenburg 2008-09-29 04:15:30 UTC
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.
Comment 17 Alan 2008-12-22 09:52:52 UTC
Re-open if this turns out not to be fixed

Note You need to log in before you can comment on or make changes to this bug.