[pvrusb2] Tracking down a problem?

[Mike Isely]

On Tue, 24 Apr 2007, G Mc.Pherson wrote:

> Hi Mike,
> 
>     It's been a while since I posted in this mailing list, you can 
> account that to the fine driver you have there :-)

Thanks.


> 
>     That being said, I recently installed Ubuntu Feisty 7.04 the other 
> day and now I'm having a problem with the pvrusb2 driver there in. 
> Unfortunately modinfo doesn't tell me what version it is. The srcversion 

The driver version is not tracked in the in-kernel variant.  Rather, 
just note which version of the kernel you are dealing with (try "uname 
-r").  It is of course possible that a distro might have rolled in a 
later driver version though I imagine it unlikely.  If the distro did do 
that using a standalone version then you can find the driver version by 
looking at the banner that is sent to the system log when the driver is 
first loaded (it will be obvious).  (If the distro did that using the 
latest v4l-dvb snapshot - which I find at least as unlikely - then we're 
out of luck there...)


>   reports "A37F238824B472CB1FC0B4D". This driver is frequently reporting 
> the following:

That's a pretty meaningless hash.  But don't worry about that.

> 
> ---(cut here)---
> > Apr 23 09:00:24 vsrv kernel: [156900.373289] pvrusb2: ***WARNING*** device's encoder appears to be stuck (status=000000003)
> > Apr 23 09:00:24 vsrv kernel: [156900.373296] pvrusb2: Encoder command: 0x81
> > Apr 23 09:00:24 vsrv kernel: [156900.373298] pvrusb2: Giving up waiting.  It is likely that this is a bad idea...
> > Apr 23 09:00:24 vsrv kernel: [156900.373301] pvrusb2: Error recovery initiated
> ---(cut here)---

This is not necessarily a fatal problem.  A short explanation is in 
order: A long time ago around July 2005 I was having trouble where the 
cx23416 mpeg encoder would just mysteriously hang after being given a 
command to start streaming.  I spent quite a while trying to understand 
and fix this.  I still haven't found the root cause, however back then I 
came up with a workaround, and that workaround has generally worked so 
well that I haven't paid much attention to it since then.  The messages 
you copied above happen when the driver detects the encoder being hung.  
The programmed "recovery action" for this is to force the chip into 
reset, reload its firmware, reconfigure it, and command it to start 
streaming again.  The whole sequence takes less than a second to 
complete so aside from these messages in the log it would be hard to 
even know it is happening at all.

For those here who might know more about cx23416 operation, the exact 
failure here is that the chip fails to set is "I'm done" flag after the 
command is issued and the pvrusb2 driver has timed out polling for that 
flag.

I still haven't found the root cause.  It *ONLY* happens on attempt to 
initiate streaming, so once it is streaming further commands always 
succeed.  This all means that you won't even notice this except for 
maybe a fraction of a second longer time to start streaming.  A few 
months ago I gained some additional knowledge about the part and used 
that to try to better refine the communications implementation but that 
didn't help.  (The code is somewhat cleaner now but the same rare but 
persistent problem still happens.)

To date, I have never successfully traced back any other issue to this 
particular problem.  Said another way, I haven't had any reports at all 
that this workaround is hurting anything.  Do you see any other 
misbehaviors that might correlate to this?

There is another change I need to put into the driver relating to better 
handling of some less common video standards.  When I put that change in 
(hopefully by this weekend) I'll see about taming down these encoder 
recovery messages.  I initially wrote the messages like that because I 
was concerned that this might be a symptom of a larger issue (which it 
might still be), however in almost 2 years of operation now this 
workaround seems to have held pretty well.  So perhaps it is time to 
trim the message...

> 
> With no usable version information in this precompiled driver, I can't 
> tell if it's current or an older one.

What is the result of running "uname -r" on this system?

I am of course still interested in learning things that might explain 
this benign behavior; it would be interesting to figure out what change 
in your upgrade caused it to start happening for you.  Though I suspect 
it might just have been relative timing changes, i.e. something is 
running slightly faster or slower now which makes the hang & recovery 
more likely now.

  -Mike

-- 
                        |         Mike Isely          |     PGP fingerprint
     Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                        |                             |