"[videoguard2-reader] classD0 ins40: (-2) status not ok" with kernel > 2.6.35

[liquidator87]

Revision

1.10rc-svn, build #5983

Issue Description

Hi, I get an annoying error with oscam. After some time it stops working, and from the log I always see the "TIMEOUT in IO_Serial_WaitToRead" followed by "[videoguard2-reader] classD0 ins40: (-2) status not ok".

I'm using a phoenix serial reader with an italian S*y NDS card, on Ubuntu 11.10

Note on this problem:

• Increasing the serial read timeout does not help
• If I kill and I restart oscam it works for a little, then the error shows up again
• It's present with every version of the kernel > 2.6.35 (with this version or early versions it works ok)
• It's present in EVERY version of oscam I've tried (stable/unstable)
• It's not a reader-related issue, since I've tried several readers and it's still present
• I don't think using an usb reader would help, since I know some users with an usb reader have the same exact problem

When the issue occurs

After a random amount of time (could be an hour, or a day)

How the issue is reproducable

Use a kernel > 2.6.35, and wait

[ftp21]

Also with 3.0 kernel have this problem.
I can confirm

[liquidator87]

Replying to ftp21:

Also with 3.0 kernel have this problem.
I can confirm

Yeah... I'm stuck with kernel version 2.6.35, with any newer version I've to keep killing and restarting oscam, which is unfeasible

[s3PP3L]

I've some Notes regarding this Problem. First my Setup:

• Debian Squeeze x64
• 2x Easymouse 2
• Active USB Hub
• 2x S*y Germany v13 (09c4)
• Oscam 1.20 unstable [6098]

But I figured out that those Problems occur also on lower and higher Versions of Oscam.

So here's what my tests showed:

• When only one of my readers is active everything is working perfect. Regardless of which card or reader I use. So a malfunction of one of my cards or one of my readers is impossible.
• It doen't matter if I have one Reader connected via USB-Hub and the other directly to my Server.
• The ATR Patch introduced in [6098] has no effect on this Problem.
• The Problem is independend of the Cardclock.
• Disabling / Enabling AU has no effect.

So I came to the conclusion that the handling of two or more readers has to be somehow broken.

[mof]

Hi,

I'm having the same problem with current versions.
My Setup

• freetz 7390
• S*y GER V13 (09C4)
• Smargo Smartreader+

So 1-reader-configs are also affected by this problem.
I'm currently using a very old version (OSCAM 1.00-unstable_svn build # 4711) which works very stable.

[liquidator87]

• When only one of my readers is active everything is working perfect. Regardless of which card or reader I use. So a malfunction of one of my cards or one of my readers is impossible.

This problem is also happening with only one card reader

[Mandos]

Log from ET9000, CAID 09C4, Smargo, svn 6324

[Mandos]

I had the error as well, today (30th January) is the second time. First time was with SVN 6306, now with 6324. My setup:

ET9000, openPLi with kernel 3.10
S|<y V13 (09C4) card
Smargo Smartreader+ 1.5, smartreader protocol
ET9200 with CCCam 2.30 as home sharing client

So here is another single-reader setup with the issue. Unfortunately I was at debug level 0 when it happened; I am now logging at 255 in order to catch the next event.

I did not yet see the issue with the internal reader, so when I want to record TV, I will put the card in there. The Smargo gives me better response times due to the higher ins7e11 setting (ET9000 internal reader only goes up to 13, Smargo can do 15)

After a week without any trouble, I switched the debug level to 16. Today (9th February) the error occurred again. My log includes the first occurrence of the error (a second after the receiver was switched on from standby), and also the restart of the reader by webif, which made it work again. I just removed some irrelevant parts and my serial.

[Mandos]

SVN 6358, mipsel-tuxbox, d=16, edited for readability

[Mandos]

Yet another log, this time at debug level 255

[Mandos]

At last, a log at debug level 255. I noticed that the issue sometimes occurred when waking the box from standby while a scrambled channel was set. I tried to trigger it by repeatedly sending the box to standby and waking it up again, and after a few minutes it worked. I attached the log with a few comments on what I did and where the issue is visible in the log for the first time. Still running it on an ET9000, OpenPLi with kernel 3.1.

[Admin]

Did you try to deactivate usb power management by setting /sys/bus/usb/devices/<reader>/power/control to on instead of auto (maybe also usb hubs need that if your reader is attached to one)? You could also try to disable it for all usb devices in general by adding "usbcore.autosuspend=-1" to the kernel boot line (if usb is compiled into the kernel) or adding "options usbcore autosuspend=-1" to /etc/modprobe.conf (if usb is loaded as a module). If you compile the kernel yourself you could also try to disable usb suspend in it at all.

[blueven]

I have the same issue with internal carder on ppc box. It occur with stable version (such as r5921) and with unstable version (latest, r6427).
The kernel of my image is 2.6.17-cubecafe-prime.

After some time (ramdomically), card reader is not anymore working, asnwering:
[videoguard2-reader] classD3 ins54: (-1) status not ok 91 00

Restart oscam resolve it.
I use videoguard 093b sky italia card. Overclock is disable, clock handle by oscam (default).

Please, solve this problem, a lot of italian people use script for restarting oscam when this error occurs, but it is not a solution, it is very annoying!

[Admin]

No, it's not the same issue as you have an older kernel.

[blueven]

Are you sure this problem is kernel dependent? A lot of people have the same issue on internal cardreader in dreambox, with older kernel.

So, what i have to do? Open new ticket?

[Mandos]

Replying to Admin:

Did you try to deactivate usb power management by setting /sys/bus/usb/devices/<reader>/power/control to on instead of auto (maybe also usb hubs need that if your reader is attached to one)?

I am not that deep into Linux device configurations. It may take some time until I find out how to do that, especially as the reader is connected to a hub.

You could also try to disable it for all usb devices in general by adding "usbcore.autosuspend=-1" to the kernel boot line (if usb is compiled into the kernel) or adding "options usbcore autosuspend=-1" to /etc/modprobe.conf (if usb is loaded as a module). If you compile the kernel yourself you could also try to disable usb suspend in it at all.

Where can I see whether usb is loaded as a module? Is there some .ko file I can look for?

[Mandos]

Hi,

does anyone still have this problem with the latest trunk versions? Last time I had it was last Monday with SVN 6458. That was when I changed channels on the box that runs as both server and DVBAPI client. When I saw all these DVBAPI changes by corsair, I decided to test again using SVN 6469. It seems that no matter how often I zap or switch to standby and on again, I can't reproduce this error any more. I think it may have been fixed with one of these DVBAPI changes. I am using OpenPLi with kernel 3.2.2 on an ET9000.

[mof]

Hi,

• freetz 7390
• S*y GER V13 (09C4)
• Smargo Smartreader+

The latest build work very well at my setup.
Even restarting OSCAM without ejecting and reinjecting the smartcard works perfectly.
Changed to fast mode two weeks ago and it is also running very stable.

[Ragnarok]

How about adding a work around option to under reader settings in OScam. also I'm using Kernal 2.6.32 and get this problem!!!!!

When my card craps out and need the reader disabled then renabled to get the card working again under readers.

until the permanent fix is found can someone please add a work around option of something like a simple on off option in the reader settings

Restart reader when classD0 ins40: (-2) status not ok

And / Or

Restart reader on serial IO timeout.

This will at least get things working again unattended and if it's troublesome you can disable it.

[Mandos]

@Ragnarok: yes, that would be a very nice thing. With me the reader crashes only seem to occur when switching channels in DVBAPI or starting the receiver from standby, so an automatic reader restart would help a lot with recordings (I always start them a few minutes early).

[Ragnarok]

are you saying DVBAPI could be sending something superflious. is that the Oscam DVBAPI!!

It almost never crashes when using other applications for the dvbapi interface.

[Mandos]

It is really difficult for me to pinpoint the issue. I was sure it only happened when I zap, but now I had the same crash without a change of channel. I will try to crash it using a CCCAM client and no DVBAPI at all.

[liquidator87]

Everything now works OK for me

OSCAM version=1.20-unstable_svn, build #6573
Ubuntu 12.04 Beta 64 bit, Kernel version 3.2.0-20-generic

[Mandos]

Replying to liquidator87:

That's what I thought yesterday, but last night it happened again with SVN #6576 (ET9000 mipsel, kernel 3.2.2, static libusb, smargo). As disabling and re-enabling the reader gets it working again, an automatic reader restart function would really be very helpful. It should be triggered by a certain number of consecutive "classD0 ins40: (-2) status not ok" errors. That would at least help with recordings that start after the event. At the moment I am recording the scrambled streams with ECMs and use offline decoding later.

[Mandos]

Another log of the crashed state, this time SVN 6576