[pvrusb2] No data from HVR-1900 encoder

[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


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8