USB errors disabling driver on Raspberry Pi

[RomanLu]

hi!

I also tested some things with the raspberry pi ...
It works now without hanging and dmesg errors (i think the power supply should work now)
I am using Kernel 3.2.27

I am using tvheadend and i have the problem, that i get a lot of this messages

Code: [Auswählen]

2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (0 // 0)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (1356 // 0)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (0 // 25)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (244 // 25)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (1411 // 25)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (0 // 0)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (0 // 64)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (0 // 172)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (0 // 64)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (0 // 44)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (976 // 44)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (0 // 24)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (207 // 24)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (0 // 44)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (1936 // 44)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (0 // 64)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (0 // 64)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (312 // 64)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (508 // 64)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (0 // 0)
2012-09-07 15:50:19 [1064] TS Sync byte not aligned, realigning stream (1148 // 0)

Transfermode is bulk.

[Sundtek]

Are you sure it's bulk? We only got those issues with ISO (RPi too slow for reading all the data). But bulk shows up fine.

Double check that the signal is okay:

/opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0

If the BER is a low value it should be okay (0 is perfect) and the only issue can be the data transfer.

[RomanLu]

what distribution are you using???
I am using raspbmc with compiled tv-headend on rpi

[Sundtek]

none, just by checking remotely with some other customers. What's the cpu usage?

for doublechecking isochronous vs bulk you can run lsusb -vvv eb1a:51b2 as soon as it shows up bulk somewhere it's set to bulk.

[marnixdv]

Any error you get in DMESG should be handled as Raspberry PI Bug and filed in their corresponding bugtracking system or even the Linux Kernel Mailinglist.

It took me a while to get the stick running again on the RPi. Raspbian for some kind of reason did not work anymore with the stick and tvheadend. With ArchLinux I get the following error in dmesg:

usb 1-1.3.1: usbfs: USBDEVFS_CONTROL failed cmd mediasrv rqt 192 rq 0 len 5 ret -845276059

Unable to handle kernel NULL pointer dereference at virtual address 00000030
pgd = cda2c000
[00000030] *pgd=0db34831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] PREEMPT
Modules linked in: videodev media ipv6 uinput
CPU: 0    Not tainted  (3.1.9-20-ARCH+ #1)
pc : [<c033d0cc>]    lr : [<c033dae4>]    psr: 60000093
sp : cdae3d30  ip : cdae3d58  fp : cdae3d54
r10: 449db908  r9 : cd9de800  r8 : cd8e68c0
r7 : cdae2000  r6 : cd9de834  r5 : cd8e68c0  r4 : cd9de834
r3 : 00000000  r2 : ffffff94  r1 : cd9de834  r0 : cd8e68c0
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 00c5387d  Table: 0da2c008  DAC: 00000015
Process mediasrv (pid: 990, stack limit = 0xcdae2268)
Stack: (0xcdae3d30 to 0xcdae4000)
3d20:                                     cd9d1ae4 cd9d1af4 cd9de834 cdae2000
3d40: cd8e68c0 449db908 cdae3d7c cdae3d58 c033dae4 c033d0c0 00000000 cd9d1ae4
3d60: cd9de800 00000000 cd9de800 00000000 cdae3d9c cdae3d80 c034016c c033d9d4
3d80: cd9d1ae4 00000084 00000003 cd9e34ac cdae3dc4 cdae3da0 c03401e8 c0340120
3da0: 00000003 cd9d1980 c056d420 cd9d1960 cd9de800 cd9d6560 cdae3de4 cdae3dc8
3dc0: c0341b4c c03401b0 cd9d1980 c056d420 00000001 80045510 cdae3dfc cdae3de8
3de0: c02fbe98 c0341a90 cd9d19b4 cd9d1980 cdae3e14 cdae3e00 c02fbf0c c02fbe44
3e00: cd9d1980 cd9d6560 cdae3e3c cdae3e18 c0341c08 c02fbef4 c0010270 c0011630
3e20: 00000000 00000000 cd9d6560 cd9d1960 cdae3e5c cdae3e40 c03454e4 c0341b88
3e40: 00000000 cd9de89c 00000000 00000000 cdae3efc cdae3e60 c0346e34 c034549c
3e60: cdae3e84 cdae3e70 c0028750 c001b730 c0060358 c0567dac cdae3ea4 cdae3e88
3e80: c000eb20 c00286e4 c00b4390 c00b3e18 20000013 cda603a8 cdae3eb4 cdae3ea8
3ea0: c0008190 c000eaf0 cdae3f7c cdae3eb8 c000de34 c000818c 00005452 00000013
3ec0: 0000550b 41e6b738 0000550b cdba6b60 41e6b738 80045510 cdba6b60 449db908
3ee0: cdba6b60 c000e424 cda603a8 449db908 cdae3f7c cdae3f00 c00b3e6c c0346370
3f00: 00000001 cdae2000 cdae3f3c cdae3f18 c0010270 c0011630 00000000 c001b788
3f20: cdae3f7c cdae3f58 c001b788 c00a4af4 cdae3f54 cdae3f40 c001b788 c0010240
3f40: 00000002 cdba6b60 cdae3f7c cdae3f58 c00a4af4 80045510 00000013 449db908
3f60: cdba6b60 c000e424 cdae2000 00000000 cdae3fa4 cdae3f80 c00b4390 c00b3df4
3f80: 002be568 00000001 80045510 449db908 00000224 00000036 00000000 cdae3fa8
3fa0: c000e2a0 c00b4360 80045510 449db908 00000013 80045510 449db908 401b9684
3fc0: 80045510 449db908 00000224 00000036 449db908 00000000 80045510 449db924
3fe0: 449db8d0 449db8c0 401b8024 40293920 60000010 00000013 00000000 00000000
Backtrace:
Function entered at [<c033d0b4>] from [<c033dae4>]
Function entered at [<c033d9c8>] from [<c034016c>]
 r8:00000000 r7:cd9de800 r6:00000000 r5:cd9de800 r4:cd9d1ae4
r3:00000000
Function entered at [<c0340114>] from [<c03401e8>]
 r6:cd9e34ac r5:00000003 r4:00000084 r3:cd9d1ae4
Function entered at [<c03401a4>] from [<c0341b4c>]
 r8:cd9d6560 r7:cd9de800 r6:cd9d1960 r5:c056d420 r4:cd9d1980
r3:00000003
Function entered at [<c0341a84>] from [<c02fbe98>]
 r7:80045510 r6:00000001 r5:c056d420 r4:cd9d1980
Function entered at [<c02fbe38>] from [<c02fbf0c>]
 r5:cd9d1980 r4:cd9d19b4
Function entered at [<c02fbee8>] from [<c0341c08>]
 r5:cd9d6560 r4:cd9d1980
Function entered at [<c0341b7c>] from [<c03454e4>]
 r6:cd9d1960 r5:cd9d6560 r4:00000000
Function entered at [<c0345490>] from [<c0346e34>]
 r6:00000000 r5:00000000 r4:cd9de89c r3:00000000
Function entered at [<c0346364>] from [<c00b3e6c>]
Function entered at [<c00b3de8>] from [<c00b4390>]
Function entered at [<c00b4354>] from [<c000e2a0>]
 r7:00000036 r6:00000224 r5:449db908 r4:80045510
Code: e24cb004 e5913028 e1a04001 e1a05000 (e5933030)
---[ end trace 9d92c50ed7b455fc ]---

Considering it's a hardware problem, the distro should not matter too much right?

Almost forgot, Sundtek, thanks for helping us solve these problems. Most could learn a lot from your customer support. I, for one, really appreciate it!

Update:
It crashes much less with:

/opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 | /opt/bin/mediaclient --pipecount 1000

Also, watching SD video is possible on some channels, but HD gives only transport errors. Although, I guess when I would map the channels in tvheadend, it would crash again after a while.

Futhermore, I've checked the BER counts and they are 0

[Sundtek]

Considering it's a hardware problem, the distro should not matter too much right?

it might depend on the kernel version / status of USB host controller driver support for the device. Since our driver is only an application it cannot cause any issues directly in the kernel, those can only result by hitting other existing kernel bugs.

We just got a RPI for testing and will see that we can get some further traces for the usb kernel  developers.

BER = 0 means the signal on your TV cable and data which can be delivered by the USB stick is perfect.

[Sundtek]

It seems like they fixed this issue in the RPI Kernel

We also tested the RPI here and figured out there's still some issue left, however we also modified our driver to ignore this error and keep everything running (before we detached the device from the driver when an error occurred).

[SevenW]

I can confirm that the USB issues are improved on the Raspberry, but not to the extend that it makes DVB-C usable. I have performed several tests on Raspberry Pi and on a Pogoplug v2.

The updated sundtek driver now indeeds keeps working, but USB communication gets messed up and even breaks the communication to the USB connected SmartCard reader.

Raspberry PI, kernel 3.1.19+, old sundtek driver:
Sundtek Media Pro: Not able to pass channel scanning in TVHeadEnd
Cinergy HTC USB XS (with linuxTV drivers): Able to scan channels, but contunity errors.

Raspberry PI, kernel 3.2.27+, new sundtek driver:
Sundtek Media Pro: Works reasonably well, but one continuty error per 2 seconds (Image distortion). SD unencrypted and encrypted working, HD unencrypted working.

Raspberry PI, kernel 3.6, new sundtek driver:
SD unencrypted and encrypted working, HD unencrypted working for all DVB-C sticks tested. HD encrypted is a too heavy load and does not work with any of the tested sticks.
Sundtek Media Pro: one continuity error every two seconds.
Cinergy HTC USB XS: more frequent continuty erros.
Anysee E30 Combo plus: Sometimes it works, but caused frequent hangups in TVHeadEnd.

Pogoplug, archlinux 3.1.x: with old sundtek driver and LinuxTV driver for Cinergy:
Both the Sundtek Media Pro and the Cinergy HTC USB XS worked, without continutiy erros for:
SD unencrypted and encrypted, and HD unencrypted. HD encrypte caused timeouts and was not usable.

To summarize: Regarding computing power the raspberry pi and pogoplug are sufficient to even decrypt a SD channel. The Raspbberry Pi USB port makes it unusable, and the pogoplug is just fine.

Currently the jury is still out on whether the Raspberry Pi USB can be fixed, but I am not going to hold my breath.

[Sundtek]

Try to tweak it a little bit.

/opt/bin/mediaclient -P on  (switching on pid filter to issue less USB traffic)

[kallewirsch]

I know that is a late reply, but sice I have a lot pain with similar problems (and same log events) here my experience:

I have a 7 pot powered xystec hub and had to cut the red wire which was back-powering the Raspberry Pi !

After that my frequent network (usb) crashes went away. But after ~half a day the network interface /wlan and lan) went down and came again after about 50 pings. Sometimes it crashed completely.

Now using a stronger Power supply and it seem to be stable.

So be very careful with eowersupply on Raspberry, it seems to be extremly sensitive and causes very weird problem symptoms..

BTW any information about power consumption of the Sundtec sticks?

Example logs (out of millions of lines)

Code: [Auswählen]

Mar 17 14:14:49 rasperik kernel: [65706.784785] usb 1-1.2.2: usbfs: USBDEVFS_CONTROL failed cmd mediasrv rqt 192 rq 13 len 4 ret -71
Mar 17 14:14:50 rasperik kernel: [65706.820697] usb 1-1.2.2: usbfs: USBDEVFS_CONTROL failed cmd mediasrv rqt 64 rq 2 len 2 ret -71
Mar 17 14:14:50 rasperik kernel: [65707.066324] hub 1-1.2:1.0: cannot reset port 1 (err = -71)
Mar 17 14:14:50 rasperik kernel: [65707.066577] hub 1-1.2:1.0: cannot reset port 1 (err = -71)
Mar 17 14:14:50 rasperik kernel: [65707.066855] hub 1-1.2:1.0: cannot reset port 1 (err = -71)
Mar 17 14:14:50 rasperik kernel: [65707.067053] hub 1-1.2:1.0: cannot reset port 1 (err = -71)
Mar 17 14:14:50 rasperik kernel: [65707.067392] hub 1-1.2:1.0: cannot reset port 1 (err = -71)
Mar 17 14:14:50 rasperik kernel: [65707.067419] hub 1-1.2:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
Mar 17 14:14:50 rasperik kernel: [65707.067759] hub 1-1.2:1.0: cannot disable port 1 (err = -71)
.....

regards
E.

[Sundtek]

- DVB-C 225mA (very low power!)
- AnalogTV 350mA
- Composite / S-Video 195mA
- Without driver 80mA
- With driver 85mA

we are also doing some tests with the RPI now in our lab, however such tests take some time

[kallewirsch]

I just want to mention, that I had very (very!) weird problems with USB and the Raspberry due to the backpowering of powered USB hubs to the Raspberry.

After weeks of searching I found that hint in a Raspi forum and cut the red wire inside the USB cable from the hub to the Raspi.
After that it works very stable.
I have tvheadend backend running on Raspi.

I have a xystec 7 port powered hub.