Can't start vdr

[bpbastos]

Hello,

I'm getting a lot of these messagens in my kernel log:

Code: [Auswählen]

Oct  3 11:33:11 home-server kernel: [ 1082.243579] INFO: task mediasrv:1543 blocked for more than 120 seconds.
Oct  3 11:33:11 home-server kernel: [ 1082.243716]       Tainted: PF          O 3.13.0-24-generic #46-Ubuntu
Oct  3 11:33:11 home-server kernel: [ 1082.243833] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct  3 11:33:11 home-server kernel: [ 1082.243973] mediasrv        D ffff88041fc94440     0  1543      1 0x00000000
Oct  3 11:33:11 home-server kernel: [ 1082.243985]  ffff8803fe4dbc00 0000000000000002 ffff8803fc16dfc0 ffff8803fe4dbfd8
Oct  3 11:33:11 home-server kernel: [ 1082.243995]  0000000000014440 0000000000014440 ffff8803fc16dfc0 ffff8803fe4dbd30
Oct  3 11:33:11 home-server kernel: [ 1082.244004]  7fffffffffffffff ffff8803fe4dbd38 ffff8803fc16dfc0 0000000000000000
Oct  3 11:33:11 home-server kernel: [ 1082.244013] Call Trace:
Oct  3 11:33:11 home-server kernel: [ 1082.244030]  [<ffffffff81719e89>] schedule+0x29/0x70
Oct  3 11:33:11 home-server kernel: [ 1082.244039]  [<ffffffff817190d9>] schedule_timeout+0x239/0x2d0
Oct  3 11:33:11 home-server kernel: [ 1082.244049]  [<ffffffff8171ae06>] wait_for_completion_timeout+0xa6/0x170
Oct  3 11:33:11 home-server kernel: [ 1082.244059]  [<ffffffff8109a790>] ? wake_up_state+0x20/0x20
Oct  3 11:33:11 home-server kernel: [ 1082.244068]  [<ffffffff8153df2d>] usb_start_wait_urb+0x7d/0x150
Oct  3 11:33:11 home-server kernel: [ 1082.244076]  [<ffffffff8153e0c5>] usb_control_msg+0xc5/0x110
Oct  3 11:33:11 home-server kernel: [ 1082.244084]  [<ffffffff81547919>] proc_control+0x129/0x3c0
Oct  3 11:33:11 home-server kernel: [ 1082.244092]  [<ffffffff81549b85>] usbdev_do_ioctl+0x715/0xf30
Oct  3 11:33:11 home-server kernel: [ 1082.244100]  [<ffffffff8154a3ce>] usbdev_ioctl+0xe/0x20
Oct  3 11:33:11 home-server kernel: [ 1082.244109]  [<ffffffff811cc6e0>] do_vfs_ioctl+0x2e0/0x4c0
Oct  3 11:33:11 home-server kernel: [ 1082.244116]  [<ffffffff8109dd84>] ? vtime_account_user+0x54/0x60
Oct  3 11:33:11 home-server kernel: [ 1082.244125]  [<ffffffff811cc941>] SyS_ioctl+0x81/0xa0
Oct  3 11:33:11 home-server kernel: [ 1082.244133]  [<ffffffff8172663f>] tracesys+0xe1/0xe6


When tried to start VDR I got the follow messages:

Code: [Auswählen]

[3321] ERROR: invalid primary device number: 1
Oct  3 11:49:43 home-server vdr: [3321] ERROR: no primary device found - using first device!
Oct  3 11:49:43 home-server vdr: [3321] ERROR: invalid primary device number: 1


[Sundtek]

Is this a USB 3.0 port?

Seems like a USB Controller driver bug. You might have to change the Linux Kernel in order to get a better driver compatibility with your USB Controller Hardware.
This has nothing to do with the device nor the driver itself.
The driver is only application based, the worst thing that could happen is that the driver application crashes itself - but in no circumstance it would be allowed to create kernel issues because the driver does not even have enough permissions for that.
If that happens your USB Controller is very likely not well supported. We also sent one device to Intel for testing, and they are checking as well

There are some USB 2.0 through USB 3.0 issues at the moment with the Linux USB controller driver, not sure if that also affects your system.

As a quick workaround you might try to use a Raspberry PI and use the device via network:
http://support.sundtek.com/index.php/topic,179.0.html

Since the driver supports network sharing on device level you could still use VDR with the virtual device on your target system.

[bpbastos]

Is this a USB 3.0 port?

Seems like a USB Controller driver bug. You might have to change the Linux Kernel in order to get a better driver compatibility with your USB Controller Hardware.
This has nothing to do with the device nor the driver itself.
The driver is only application based, the worst thing that could happen is that the driver application crashes itself - but in no circumstance it would be allowed to create kernel issues because the driver does not even have enough permissions for that.
If that happens your USB Controller is very likely not well supported.

There are some USB 2.0 through USB 3.0 issues at the moment with the Linux USB controller driver, not sure if that also affects your system.

As a quick workaround you might try to use a Raspberry PI and use the device via network:
http://support.sundtek.com/index.php/topic,179.0.html

Since the driver supports network sharing on device level you could still use VDR with the virtual device on your target system.

No, it's a USB 2.0 port and the hardware is a HP Microserver N40L which I use as NAS.

Now I can start VDR, watch some TV but after a while the mediasrv crash with this kernel message and stops VDR.

My main problem is that this server is my only server and I don't have any other spare computer around to install another distro with a compatible kernel. But if this is the only solution, I'll have to reinstall my NAS using a compatible distro with a compatible kernel. Do you mind to tell which kernel version is compatible with your driver?

Thank you

Bruno

[Sundtek]

Wait, this also looks like the box ran out of memory. Check the initial message in dmesg. I think what you posted is only a follow up message.
There's definitely nothing wrong with the backlog which you posted (the transaction hung for 2 minutes but it's not the reason of your problem)

[bpbastos]

Wait, this also looks like the box ran out of memory. Check the initial message in dmesg. I think what you posted is only a follow up message.
There's definitely nothing wrong with the backlog which you posted (the transaction hung for 2 minutes but it's not the reason of your problem)

I've uploaded my dmesg http://paste.ubuntu.com/8492322/ please take a look. I can't find anything related to out of memory errors.

What i've found was that as soon as vdr crash the pid still be used by driver, mediaclient --lc give me the follow:

Code: [Auswählen]

root@home-server:~# mediaclient --lc
**** List of Media Clients ****
/dev/dvb/adapter0/frontend0:
  2019
  2576
  2576
  2576
  2576
/dev/dvb/adapter0/dvr0:
  2019
  2019
  2019
  2019
/dev/dvb/adapter0/demux0:
  No client connected
/dev/video0:
  No client connected
/dev/vbi0:
  No client connected
/dev/radio0:
  No client connected
/dev/rds0:
  No client connected
/dev/mediainput0:
  No client connected
/dev/dsp0:
  No client connected


[Sundtek]

Ok from the Logfile I see that this is a faulty AMD system, possibly that there's another USB controller bug hitting you.
AMD SB600 / SB700 boards are known to have various issues.

in your logfile there's one indicator for one workaround that is needed by this controller:
ehci-pci 0000:00:12.2: EHCI Host Controller
[    2.924058] ehci-pci 0000:00:12.2: new USB bus registered, assigned bus number 1
[    2.925778] ehci-pci 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
[    2.927844] ehci-pci 0000:00:12.2: debug port 1
[    2.928987] ehci-pci 0000:00:12.2: irq 17, io mem 0xfe3ff800


You might try to change the transfermode of the USB device.

/opt/bin/mediaclient --transfermode=iso -d /dev/dvb/adapter0/frontend0

Maybe that helps.

I would really advice to get some Raspberry PI and use the device via network, or try to get a workable USB PCI/PCIe controller.
A problem on our driver side is not possible in that area unfortunately (otherwise we'd prefer to fix it in order to avoid other ones having the same issue...)

If you can reproduce this issue you should report this bug on https://bugzilla.kernel.org/
But I fear this issue will be difficult without someone from AMD fixing this bug (and as far as I can tell AMD does not have the people for that anymore, I worked for them several years ago).

[bpbastos]

Ok from the Logfile I see that this is a faulty AMD system, possibly that there's another USB controller bug hitting you.
AMD SB600 / SB700 boards are known to have various issues.

in your logfile there's one indicator for one workaround that is needed by this controller:
ehci-pci 0000:00:12.2: EHCI Host Controller
[    2.924058] ehci-pci 0000:00:12.2: new USB bus registered, assigned bus number 1
[    2.925778] ehci-pci 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
[    2.927844] ehci-pci 0000:00:12.2: debug port 1
[    2.928987] ehci-pci 0000:00:12.2: irq 17, io mem 0xfe3ff800


You might try to change the transfermode of the USB device.

/opt/bin/mediaclient --transfermode=iso -d /dev/dvb/adapter0/frontend0

Maybe that helps.

I would really advice to get some Raspberry PI and use the device via network, or try to get a workable USB PCI/PCIe controller.
A problem on our driver side is not possible in that area unfortunately (otherwise we'd prefer to fix it in order to avoid other ones having the same issue...)

If you can reproduce this issue you should report this bug on https://bugzilla.kernel.org/

Humm, I have an pcie usb 3.0 installed in this server but as soon as I plug  in the mediatv a get a hell of kernel hang messages. I'll post my dmesg with the media tv plugged in, maybe you can help.

[Sundtek]

The USB 3.0 issue definitely has a better chance to be fixed, as mentioned earlier someone at intel received our device some time ago and is looking at the USB 3.0 controller driver. But also try to switch the transfermode as adviced in the previous post. To switch back use "bulk" as argument instead of "iso" after changing the mode you need to replug the device (the setting is stored on the device)

https://bugzilla.kernel.org/show_bug.cgi?id=75521

please post the USB 3.0 backlog from your system.

[bpbastos]

The USB 3.0 issue definitely has a better chance to be fixed, as mentioned earlier someone at intel received our device some time ago and is looking at the USB 3.0 controller driver.

https://bugzilla.kernel.org/show_bug.cgi?id=75521

please post the USB 3.0 backlog from your system.

Here it is: http://paste.ubuntu.com/8492548/

[Sundtek]

When starting up the system be sure nothing accesses the device

Run:
/opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 > /dev/null


this will prevent that the device will go to standby and turn off the datatransfer  (the turning off the datatransfer part causes the issue with the usb 3.0 controllers at the moment)
The tuners have no problem with that since they are very low power.

Second of all start VDR

This would be a workaround for now until the USB 3.0 controller issue will be fixed.

[bpbastos]

When starting up the system be sure nothing accesses the device

Run:
/opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 > /dev/null


this will prevent that the device will go to standby and turn off the datatransfer  (the turning off the datatransfer part causes the issue with the usb 3.0 controllers at the moment)
The tuners have no problem with that since they are very low power.

Second of all start VDR

This would be a workaround for now until the USB 3.0 controller issue will be fixed.

I've removed vdr's default init script using update-rc.d and created my own script with follow content:

Code: [Auswählen]

/opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 > /dev/null
sleep 3
/etc/init.d/vdr start
But the system is still hanging.

[bpbastos]

When starting up the system be sure nothing accesses the device

Run:
/opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 > /dev/null


this will prevent that the device will go to standby and turn off the datatransfer  (the turning off the datatransfer part causes the issue with the usb 3.0 controllers at the moment)
The tuners have no problem with that since they are very low power.

Second of all start VDR

This would be a workaround for now until the USB 3.0 controller issue will be fixed.

I've removed vdr's default init script using update-rc.d and created my own script with follow content:

Code: [Auswählen]

/opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 > /dev/null
sleep 3
/etc/init.d/vdr start
But the system is still hanging.

Nevermind, I've got it working.

I've forgotten to set it as executable, its working now. I'll test and report you back.

Thank you!