[pvrusb2] No data from HVR-1900 encoder

[Magnus Ekhall]

Thanks for your help.

I've now enabled a bunch of debug printouts to see what actually happens
under the hood.

I took a closer look at the kernel log and I'm pretty sure I got one of
those messages regarding the stuck encoder, and the encoder was still
working just fine. Maybe the printouts are unrelated to the problem
after all...

I also downloaded the latest windows driver from Hauppauges website and
extracted the various firmwares. I found one firmware that was different
from what I was currently running. The new firmware v4l-cx25840.fw has a
md5sum of 95bc688d3e7599fd5800161e9971cc55. I don't know if that is what
"everybody else" is running?

I don't know if that will help me, but I'm running the new one now.

Now I'm just waiting for the problem to happen again so that I can take
a dive in the now slightly more verbose kernel logs. :)

Regards,
Magnus


fre 2011-06-17 klockan 20:51 -0500 skrev Mike Isely:
> See below..
> 
>   -Mike
> 
> 
> On Fri, 17 Jun 2011, Magnus Ekhall wrote:
> 
> > 
> > 
> > I can't say that I see any efforts to recover. Here is a longer,
> > consecutive part of the kernel log:
> > 
> > Jun 12 09:15:05 digimatrix kernel: [67522.143822] pvrusb2: ***WARNING***
> > device's encoder appears to be stuck (status=0x00000003)
> > Jun 12 09:15:05 digimatrix kernel: [67522.143829] pvrusb2: Encoder
> > command: 0x81
> > Jun 12 09:15:05 digimatrix kernel: [67522.143833] pvrusb2: Giving up on
> > command.  This is normally recovered via a firmware reload and
> > re-initialization; c
> > oncern is only warranted if this happens repeatedly and rapidly.
> > Jun 12 09:40:04 digimatrix kernel: [69021.735287] pvrusb2: ***WARNING***
> > device's encoder appears to be stuck (status=0x00000003)
> > Jun 12 09:40:04 digimatrix kernel: [69021.735293] pvrusb2: Encoder
> > command: 0x81
> > Jun 12 09:40:04 digimatrix kernel: [69021.735297] pvrusb2: Giving up on
> > command.  This is normally recovered via a firmware reload and
> > re-initialization; c
> > oncern is only warranted if this happens repeatedly and rapidly.
> > Jun 12 17:17:28 digimatrix kernel: [96465.946075] ath: Failed to stop TX
> > DMA in 100 msec after killing last frame
> > Jun 12 17:17:28 digimatrix kernel: [96465.946128] ath: Failed to stop TX
> > DMA!
> > Jun 15 01:30:04 digimatrix kernel: [298828.093416] pvrusb2:
> > ***WARNING*** device's encoder appears to be stuck (status=0x00000003)
> > Jun 15 01:30:04 digimatrix kernel: [298828.093423] pvrusb2: Encoder
> > command: 0x81
> > Jun 15 01:30:04 digimatrix kernel: [298828.093427] pvrusb2: Giving up on
> > command.  This is normally recovered via a firmware reload and
> > re-initialization; 
> > concern is only warranted if this happens repeatedly and rapidly.
> > Jun 15 20:59:34 digimatrix kernel: [369000.134310] pvrusb2:
> > ***WARNING*** device's encoder appears to be stuck (status=0x00000003)
> > Jun 15 20:59:34 digimatrix kernel: [369000.134317] pvrusb2: Encoder
> > command: 0x81
> > Jun 15 20:59:34 digimatrix kernel: [369000.134321] pvrusb2: Giving up on
> > command.  This is normally recovered via a firmware reload and
> > re-initialization; 
> > concern is only warranted if this happens repeatedly and rapidly.
> > 
> > 
> > 
> > As you can see the message regarding the stuck encoder is repeated, but
> > sometimes with hours between the messages, and sometimes with days.
> > 
> > What would the recovery attempt log message look like?
> 
> When the recovery happens, it typically takes less than a second.  (It 
> is usually so fast that people don't even notice it had to recover 
> unless one looks at the kernel log.)  The fact that you're going hours / 
> days between errors means it's probably recovering OK.  So you're 
> generally not getting into a situation when it's in rapid loop 
> repeatedly trying to recover.
> 
> You might not be seeing the recovery related messages because those 
> particular debug flags are likely turned off in the driver.  You can, if 
> you want, turn on additional debug flags without needing to rebuild 
> anything.  There's information on how to change that debug mask here:
> 
> http://www.isely.net/pvrusb2/usage.html#Logging
> 
> However that doesn't explain the behavior that's causing you a problem - 
> that it's just getting jammed and NOT recovering.  If you can pretty 
> regularly get it to jam, while additional debug flags are on, we might 
> be able to pin it down.  Read on...
> 
> 
> 
> > 
> > I'm running an up to date mythbuntu where the pvrusb2 module is of
> > version:
> > srcversion:     8576222596CEAD8A32E8AB8
> > vermagic:       2.6.38-8-generic SMP mod_unload modversions 
> 
> Assuming that the driver wasn't patched in this distribution then you're 
> probably running the vanilla driver that comes with the 2.6.38 kernel.  
> That's a mature, recent, driver.
> 
> > 
> > I'm starting to suspect problematic hardware, but I would like to look
> > at all other possibilities before I open my wallet. :)
> 
> One thing we have to consider here is that the logic you're looking at, 
> that is the behavior of the mpeg encoder dying and the driver recovering 
> it automatically, has been a feature of the driver for *many* years.  
> It's been a stable behavior over that time, so the fact that you're the 
> first person in, well basically forever, to be reporting this issue 
> leads me to suspect that you might indeed be dealing with marginal 
> hardware.
> 
> These pvrusb2-driver devices are never USB-powered - they always require 
> an external power brick to run.  The reason for this is that the mpeg 
> encoder chip needs a lot of juice to do its job.  It is likely the 
> hottest part inside the box.  So if, for example, the box might be 
> getting too warm, then it's reasonable to suspect that the first chip to 
> be affected by it will in fact be the encoder chip.  The encoder chip is 
> what is crashing on you...
> 
> If your tuner is already out of warranty, a good experiment I'd probably 
> try is to run it with the top removed and a fan blowing air across it.  
> This wouldn't really be a "fix", but if having the air flowing across 
> the board seems to lower the probability of these crashes then I'd say 
> you've got a pretty strong datapoint that it's getting too hot.
> 
> If you can run your tuner under Windows (yeah, I know, a pain), you can 
> also diagnose bad hardware if running it under Windows also results in 
> periodic failures.  (However the inverse may not be true - it could be 
> marginal hardware that only dies when driven hard enough and the two 
> software environments - Linux vs Windows - are certainly going to be 
> driving it differently.)
> 
> 
> > 
> > And if a hardware problem is detectable and there is a way to work
> > around it (by re-initializing it) that's fine as well.
> 
> Well the driver is already doing some of that re-initialization...
> 
>   -Mike
> 
>