USB errors disabling driver on Raspberry Pi

[SevenW]

When scanning services with TVHeadEnd, after one or two minutes a USB error occurs which disables the driver. I am using raspbian on Raspberry PI.
mediaserv.log

Code: [Auswählen]

2012-08-14 22:27:32 [2787] USB Transfer problem, shutting down driver instance (-1 - 14)debug log

Code: [Auswählen]

Aug 14 22:27:27 -------- kernel: [ 2742.787516]  usb 1-1.2.4: usbfs: USBDEVFS_CONTROL failed cmd mediasrv rqt 192 rq 0 len 5 ret -844680027I am aware of USB issues on the raspberry. So I already did the following:
- Using a 4-port powered USB hub.
- Using dtvtransfermode=bulk
- Enable HW pidfiltering, as per this post http://support.sundtek.com/index.php/topic,941.msg6515.html#msg6515

I observed BTW that the file /etc/sundtek.conf apparently does not have effect. Both enabling loglevel=max and hwpidfiltering does not take effect after a reboot.

I hope there is more tweaking possible on usb timing parameters, or maybe the driver can be made more robust for incidental USB errors.

regards,
SevenW

[Sundtek]

USB Hub problem. The Raspberry PI is very picky about the USB Hub.

- Using a 4-port powered USB hub.

Please write more details about the hub.
The RPI requires a USB Hub which is powered by an external AC adapter, and by experience not all active hubs are suitable for the RPI for constant data transfer.

[SevenW]

By now I tested with three different USB Hubs, and the error occurs in all cases in the same way. I also changed several usb cables and played around with different power supplies for the hubs. All three hubs are externally powered by an AC adapter. The hubs tested are:

• ICIDU AI-707906 4-ports usb hub, powered by 5V, 2A adapter
• Conceptronic C4USB2 4 port USB2.0 Hub, powered bu 5V, 1A and 5V, 2A adapter
• SITECOM CN-019 4port usb 2.0, powered by 6V, 2.1A adpater (5V at USB-out!)

The error most of the time occurs changing the transponder, after setting the demodulator to 3. It can happen after ten seconds of transponder scanning, but also after two minutes. Besides the driver shutting down itself, very often it totally hangs the raspberry, so I need to remove and reconnect power to restart.

Can the driver be made a bit more fault tolerant?

Regards,
SevenW

[Sundtek]

Did you switch the device to bulk mode?

/opt/bin/mediaclient --dtvtransfermode=bulk

Can the driver be made a bit more fault tolerant?

not in that case, when the device is gone it's gone from the system the driver won't have access to the device anymore.

So far we tested HAMA USB Hubs and they worked fine for our purpose

you might try to contact us via skype "sundtek" in order to doublecheck that everything is set up to what we would call best setup.

[marnixdv]

These were the exact problems I was having. I just gave up in the end.

Did you switch the device to bulk mode?

/opt/bin/mediaclient --dtvtransfermode=bulk

Can the driver be made a bit more fault tolerant?

not in that case, when the device is gone it's gone from the system the driver won't have access to the device anymore.

So far we tested HAMA USB Hubs and they worked fine for our purpose

you might try to contact us via skype "sundtek" in order to doublecheck that everything is set up to what we would call best setup.

Do you guys have the Raspberry Pi working with tvheadend and the stick? If so, I might very well buy the hub

[Sundtek]

We don't even have one, but other customers do and have it running. We only checked it remotely

[marnixdv]

We don't even have one, but other customers do and have it running. We only checked it remotely

Okay, just ordered one! Lets see how it works.

[Komet]

Okay, just ordered one! Lets see how it works.

I tried the same and experienced the same issues...
Did you got the new hub already? Any success in using the Raspberry Pi with a Sundtek stick?

[Sundtek]

Okay, just ordered one! Lets see how it works.

I tried the same and experienced the same issues...
Did you got the new hub already? Any success in using the Raspberry Pi with a Sundtek stick?

1. Try switching off the loglevel and enable hardware pid filtering:
echo "loglevel=off" > /etc/sundtek.conf
echo "use_hwpidfilter=on" >> /etc/sundtek.conf
2. Run following command to configure the DTV firmware:
/opt/bin/mediaclient --dtvtransfermode=bulk
3. Use an active USB Hub since the RPi only provides 125mA (not 500mA as specified by the USB 2.0 standard)!
4. Restart the RPi

everything should work.

[Komet]

That's exactly what I did. But after another error

Code: [Auswählen]

usb 1-1.2.2: usbfs: USBDEVFS_CONTROL failed cmd mediasrv rqt 192 rq 0 len 5 ret -845703067my Raspberry Pi just crashed with this log (sorry for the picture)
http://www.kvibes.net/pi/kernel_log1.jpg

I'll try experimenting with different distributions or kernel version.

[Sundtek]

That's an excellent trace!

Maybe you can start a topic on the RPi Forum Raspberry PI USB Host controller/driver bugs
What you got here is a plain programming error in the USB Host Controller driver - possibly triggered by another USB host driver issue of course. Our driver is definitely not the reason for that.

PC is at unlink1+0x20/0x144 <--
LR is at usb_hcd_flush_endpoint+0x134/160 <- usb host controller flush endpoint

I don't have the sources for 3.1.9 here which are used for your system but this issue should definitely be cleared up. Is there any public repository available for that RPI 3.1.9 version?

I even guess in order to work around that issue you just have to keep the data transfer up and running just by doing /opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 | /opt/bin/mediaclient --pipecount 1000

[marnixdv]

Thanks guys for finding the culprit. Hope I'll have some time to test that configuration tonight.

[marnixdv]

Okay, just ordered one! Lets see how it works.

I tried the same and experienced the same issues...
Did you got the new hub already? Any success in using the Raspberry Pi with a Sundtek stick?

Sorry for the late reply. I ordered the wrong HAMA hub, thought it was powered, but it wasn't (or I still had to buy an adapter for it). Hadn't gotten around to order a new one.

But as we speak, I'm testing the settings Sundtek support has sent me. So far so good!

Update: Although searching went better, watching was not possible. I got the usual continuity errors of not being able to cope with the data stream. SD channels were barely watchable and HD was not possible at all.

[Komet]

I don't have the sources for 3.1.9 here which are used for your system but this issue should definitely be cleared up. Is there any public repository available for that RPI 3.1.9 version?

I think these are the "official" Raspberry kernel sources found here: https://github.com/raspberrypi/linux (some older commit) It was the default kernel installed with the Raspberry Debian (http://www.raspberrypi.org/downloads).

I compiled the latest sources from their git repository and the bug
I installed tv headend as backend but during the initial scan there are often errors like

Code: [Auswählen]

dvb: "/dev/dvb/adapter0" tuning to "442,000 kHz" -- Front configuration failed -- Datenübergabe unterbrochen (broken pipe), frequency: 442000000These will continue until I reboot.
When watching a stream (with VLC or XBMC on another machine) every few seconds I get artifacts and stuttering. On the RPi are errors like

Code: [Auswählen]

Sep  5 13:18:26 raspberrypi tvheadend[1469]: TS: Sundtek DVB-C/Cable Network: 706,000 kHz/Das Erste HD: H264 @ #5101: Continuity counter error
Sep  5 13:18:26 raspberrypi tvheadend[1469]: TS: Sundtek DVB-C/Cable Network: 706,000 kHz/Das Erste HD: AC3 @ #5106: Continuity counter error
Sep  5 13:18:26 raspberrypi tvheadend[1469]: TS: Sundtek DVB-C/Cable Network: 706,000 kHz/Das Erste HD: TELETEXT @ #5104: Continuity counter error
Sep  5 13:18:26 raspberrypi tvheadend[1469]: TS: Sundtek DVB-C/Cable Network: 706,000 kHz/Das Erste HD: MPEG2AUDIO @ #5102: Continuity counter error
Sep  5 13:18:26 raspberrypi tvheadend[1469]: TS: Sundtek DVB-C/Cable Network: 706,000 kHz/Das Erste HD: MPEG2AUDIO @ #5103: Continuity counter error


[Sundtek]

You need to watch dmesg, and as mentioned you might even try to keep the transfer enabled in the background with the command given a few posts before.

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.

When asking us for support please prepare all information you can collect, we are even willing to forward the information to the corresponding people.

The tvheadend or driver logfile is not enough, yes it shows that the datastream is gone, but it does not reveal what is happening on your system, at least dmesg is also needed.

Currently our guess is that the specific USB Host controller triggers an interrupt at the wrong time and the host controller implementation runs against the wall. NULL pointer issues in the kernel are usually avoidable and software bugs from the Linux Kernel system (not even from our driver or application).