Terratec DT USB XS Diversity/DiB0070+vdr: "URB status: Value too large for defined data type"+USB reset

Hi folks,

yesterday I bought a Terratec Cinergy DT USB XS Diversity and the device works just plug&play and without problems under Windows AND linux mplayer+ tzap but resets the whole USB bus very shortly after I starting vdr. I don't think this has something to do with vdr itself, so I posting here.

My configuration is Debian on testing, kernel is 2.6.29-4.slh.1-sidux-686, DVB drivers aren't self compiled, vdr is "(1.6.0-2/1.6.0)", device info: ID 0ccd:0081 TerraTec Electronic GmbH. log entries:

Jun  1 01:14:47 vdr kernel: dib0700: loaded with support for 8 different device-types
Jun  1 01:14:47 vdr kernel: dvb-usb: found a 'Terratec Cinergy DT USB XS Diversity' in warm state.
Jun  1 01:14:47 vdr kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
Jun  1 01:14:47 vdr kernel: DVB: registering new adapter (Terratec Cinergy DT USB XS Diversity)
Jun  1 01:14:47 vdr kernel: DVB: registering adapter 1 frontend 0 (DiBcom 7000PC)...
Jun  1 01:14:47 vdr kernel: DiB0070: successfully identified
Jun  1 01:14:47 vdr kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
Jun  1 01:14:47 vdr kernel: DVB: registering new adapter (Terratec Cinergy DT USB XS Diversity)
Jun  1 01:14:47 vdr kernel: DVB: registering adapter 2 frontend 0 (DiBcom 7000PC)...
Jun  1 01:14:47 vdr kernel: DiB0070: successfully identified
Jun  1 01:14:47 vdr kernel: dvb-usb: Terratec Cinergy DT USB XS Diversity successfully initialized and connected.
Jun  1 01:14:47 vdr kernel: usbcore: registered new interface driver dvb_usb_dib0700
vdr start -> Jun  1 01:16:24 vdr logger: runvdr get_modulenames: dvb_usb#012videobuf_dvb#012cx88_dvb dvb_core
USB reset -> Jun  1 01:18:00 vdr kernel: usb 1-2: USB disconnect, [... all devices reconnecting to the bus ....]
Jun  1 01:18:28 vdr kernel: DiB0070 I2C write failed
Jun  1 01:18:28 vdr kernel: DiB0070 I2C read failed
Jun  1 01:18:28 vdr kernel: DiB0070 I2C write failed
Jun  1 01:18:28 vdr kernel: DiB0070 I2C write failed
Jun  1 01:18:28 vdr kernel: DiB0070 I2C write failed

[...]

This logs aren't very helpful, but I find something interesting with Wireshark and usbmon:
device -> host
URB type: URB_COMPLETE ('C')
URB transfer type: URB_BULK (3)
Endpoint: 0x83
Device: 13
Data: present (0)
URB status: Value too large for defined data type (-EOVERFLOW) (-75)
URB length [bytes]: 39424
Data length [bytes]: 39424

after this URB I get a "URB transfer type: URB_INTERRUPT (1)" and all goes to hell.

Its also interesting that the URB+data length in the failure package is 39424 but "URB length [bytes]: 39480" in every package before that.

As I know this device works without problems under linux for other people, so I'm wondering why. I searched but found nothing about such a problem.

The wireshark capturefile is downloadable here: http://rapidshare.com/files/239429647/terratec-xs-usb-overflow.html

Thanks for hints,
Marco Borm

I "played" a little bit with my problem and tried the latest source from the repository, but EOVERFLOW still occurs seconds after starting vdr. I activated the debug options of all, I hope, relevant modules now and got a more detailed kern.log.
Maybe some expert can help me and take look at it.
Interesting section:

Jun  1 23:16:14 vdr kernel: function : dvb_dvr_poll
Jun  1 23:16:14 vdr kernel: function : dvb_dvr_poll
Jun  1 23:16:14 vdr kernel: function : dvb_dvr_poll
Jun  1 23:16:14 vdr kernel: dmxdev: section callback 4e f2 6c 40 0a e7
Jun  1 23:16:14 vdr kernel: dmxdev: section callback 50 f2 55 40 13 e1
Jun  1 23:16:14 vdr kernel: dmxdev: section callback 00 b0 1d 03 01 d1
Jun  1 23:16:14 vdr kernel: stop pid: 0x00a0, feedtype: 1
Jun  1 23:16:14 vdr kernel: setting pid (no):   160 00a0 at index 7 'off'
Jun  1 23:16:14 vdr kernel: function : dvb_dmxdev_filter_set
Jun  1 23:16:14 vdr kernel: start pid: 0x00e0, feedtype: 1
Jun  1 23:16:14 vdr kernel: setting pid (no):   224 00e0 at index 7 'on'
Jun  1 23:16:14 vdr kernel: function : dvb_dvr_poll
Jun  1 23:16:14 vdr kernel: function : dvb_dvr_poll

BOOM -> Jun 1 23:16:14 vdr kernel: urb completition error -75.

Quoted 11 lines

This logs aren't very helpful, but I find something interesting with Wireshark and usbmon:
device -> host
URB type: URB_COMPLETE ('C')
URB transfer type: URB_BULK (3)
Endpoint: 0x83
Device: 13
Data: present (0)
URB status: Value too large for defined data type (-EOVERFLOW) (-75)
URB length [bytes]: 39424
Data length [bytes]: 39424

Quoted 3 lines

after this URB I get a "URB transfer type: URB_INTERRUPT (1)" and all goes to hell.

Its also interesting that the URB+data length in the failure package is 39424 but "URB length [bytes]: 39480" in every package before that.

Quoted 1 line

As I know this device works without problems under linux for other people, so I'm wondering why. I searched but found nothing about such a problem.

Hi Marco,

Quoted 8 lines

Quoted 8 lines

[...]This logs aren't very helpful, but I find something interesting with Wireshark and usbmon:
device -> host
URB type: URB_COMPLETE ('C')
URB transfer type: URB_BULK (3)
[...]
URB status: Value too large for defined data type (-EOVERFLOW) (-75)
[...]

Quoted 3 lines

Quoted 3 lines

after this URB I get a "URB transfer type: URB_INTERRUPT (1)" and all goes to hell.

Its also interesting that the URB+data length in the failure package is 39424 but "URB length [bytes]: 39480" in every package before that.

Definitely interesting. This is a known issue for the dib0700 device, which happens on some USB host controllers. Actually which one do you use?

Quoted 2 lines

Quoted 2 lines

As I know this device works without problems under linux for other people, so I'm wondering why. I searched but found nothing about such a problem.

Yeah, but are they using 2.6.29?

In fact, since 2 days I'm having the T5 Terratec device, which seems to be similar to your device, I'm going to try it soon. To experience whether there are similar problems.

Do you connect the device directly to the PC or is there an extension cable or another USB hub in between?

Quoted 1 line

Definitely interesting. This is a known issue for the dib0700 device, which happens on some USB host controllers. Actually which one do you use?

"USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller"

Hmm, looks bad: http://www.google.com/search?q=dib0700+sb700
But I am wondering if this could really be some bigger linux USB-stack problem, because it runs with Linux/totem for hours (mplayer was wrong). For me it looks like vdr uses some feature the driver doesn't handle correctly. Isn't the EOVERFLOW some local error value from the usb stack generates if some given buffer was to small?

Quoted 1 line

Do you connect the device directly to the PC or is there an extension cable or another USB hub in between?

I tried it with a longer and the short cable which was in the package, never directly and never with a hub.

Hi Marco,

Quoted 6 lines · Marco Borm

Quoted 1 line

Definitely interesting. This is a known issue for the dib0700 device, which happens on some USB host controllers. Actually which one do you use?

"USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller"

Hmm, looks bad: http://www.google.com/search?q=dib0700+sb700
But I am wondering if this could really be some bigger linux USB-stack problem, because it runs with Linux/totem for hours (mplayer was wrong). For me it looks like vdr uses some feature the driver doesn't handle correctly. Isn't the EOVERFLOW some local error value from the usb stack generates if some given buffer was to small?

:(. It is a long story for the SB700 ATI HC ... It turned out for DiBcom that ATI fixed the HC-driver for Windows to make things work correctly.

At some point in time they provided a patch for Linux and it was actually included in 2.6.21 or 22 .

There is some work going on on 2.6.30 for almost similar problems for another device, maybe it is worth to either:

1) try out latest 2.6.30 releases
2) do a (manual) bisect with older kernel to find out which change has made things worse (this is extremely long)

Quoted 2 lines

Quoted 1 line

Do you connect the device directly to the PC or is there an extension cable or another USB hub in between?

I tried it with a longer and the short cable which was in the package, never directly and never with a hub.

Knowing that you have the SB700, I can surely say, it's not the cable, but the controller.

Hi Marco,

Quoted 6 lines · Marco Borm

Quoted 1 line

Definitely interesting. This is a known issue for the dib0700 device, which happens on some USB host controllers. Actually which one do you use?

"USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller"

Hmm, looks bad: http://www.google.com/search?q=dib0700+sb700
But I am wondering if this could really be some bigger linux USB-stack problem, because it runs with Linux/totem for hours (mplayer was wrong). For me it looks like vdr uses some feature the driver doesn't handle correctly. Isn't the EOVERFLOW some local error value from the usb stack generates if some given buffer was to small?

:(. It is a long story for the SB700 ATI HC ... It turned out for DiBcom that ATI fixed the HC-driver for Windows to make things work correctly.

At some point in time they provided a patch for Linux and it was actually included in 2.6.21 or 22 .

There is some work going on on 2.6.30 for almost similar problems for another device, maybe it is worth to either:

1) try out latest 2.6.30 releases

Hi Marco,

Quoted 6 lines · Marco Borm

Quoted 1 line

Definitely interesting. This is a known issue for the dib0700 device, which happens on some USB host controllers. Actually which one do you use?

"USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller"

Hmm, looks bad: http://www.google.com/search?q=dib0700+sb700
But I am wondering if this could really be some bigger linux USB-stack problem, because it runs with Linux/totem for hours (mplayer was wrong). For me it looks like vdr uses some feature the driver doesn't handle correctly. Isn't the EOVERFLOW some local error value from the usb stack generates if some given buffer was to small?

:(. It is a long story for the SB700 ATI HC ... It turned out for DiBcom that ATI fixed the HC-driver for Windows to make things work correctly.

At some point in time they provided a patch for Linux and it was actually included in 2.6.21 or 22 .

There is some work going on on 2.6.30 for almost similar problems for another device, maybe it is worth to either:

1) try out latest 2.6.30 releases
2) do a (manual) bisect with older kernel to find out which change has made things worse (this is extremely long)

Quoted 2 lines

Quoted 1 line

Do you connect the device directly to the PC or is there an extension cable or another USB hub in between?

I tried it with a longer and the short cable which was in the package, never directly and never with a hub.

Knowing that you have the SB700, I can surely say, it's not the cable, but the controller.

Patrick.

Signature · 6 lines

  Mail: [email protected]
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
-- 
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html