[pvrusb2] No data from HVR-1900 encoder

[Magnus Ekhall]

See below:

tor 2011-06-16 klockan 17:10 -0500 skrev Mike Isely:
> See below...
> 
> On Thu, 16 Jun 2011, Magnus Ekhall wrote:
> 
> > Hello,
> > 
> > I'm using the pvrusb2 driver (excellent work by the way!) to use a
> > Hauppauge HVR-1900 model 73xxx.
> > 
> > The driver identifies the tuner (TDA18271HD/C2), the demodulator
> > (cx25840) at boot and generally everything works great.
> > 
> > However approx. once per week something odd happens. When mythtv tries
> > to use the analogue tuner there is no data coming out of /dev/video0.
> > 
> > Not even if I cat /dev/video0 I get anything in that case.
> 
> Those two symptoms are consistent - if cat doesn't work then mythtv 
> won't be able to stream from it either.
> 
> 
> > 
> > I've even tried to reload the pvrusb2 driver and yanking the USB-cable.
> > 
> > The only thing that works is a reboot.
> 
> Power-cycling just the tuner *should* also clear things up.  But you 
> should not even need to do that.  Read further...
> 
> 
> > 
> > Now, that sounds a bit like the mystery bug written on the FAQ, but I'm
> > not sure.
> > 
> > Also, I know that pvrusb2 is sort of a higher level driver which uses
> > sub-drivers, so maybe I'm at the wrong forum here...
> > 
> > Anyway, the problem is really annoying, so any input is most welcome!
> > 
> > In the kernel log there are a message that I believe might have
> > something to do with the issue:
> > 
> > "
> > May  1 08:49:33 digimatrix kernel: [383494.928478] pvrusb2:
> > ***WARNING*** device's encoder appears to be stuck (status=0x00000003)
> > May  1 08:49:33 digimatrix kernel: [383494.928485] pvrusb2: Encoder
> > command: 0x81
> > May  1 08:49:33 digimatrix kernel: [383494.928489] 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.
> > "
> 
> This is a longstanding behavior in the driver.  What's happening here is 
> that the pvrusb2 driver has detected that the mpeg encoder chip has 
> stopped responding.  That chip is its own processor with a firmware 
> program that gets loaded to it.  When (if) it crashes this is the 
> result.
> 
> The pvrusb2 driver detects this situation and prints the warning to the 
> kernel log.  But the recovery is (should be) automatic - other logic in 
> the driver then resets the mpeg encoder, sends it a fresh firmware 
> image, and restarts it for you.  (Actually what happens is that the 
> driver marks internal state to track what it thinks has happened, e.g. 
> dead mpeg encoder, and then the driver's normal internal state machine 
> just sequences whatever steps it thinks are needed to bring the video 
> pipeline back up into a working condition.)  This is normally what is 
> supposed to happen.  You should see further messages in the kernel log 
> as the driver reinitializes the encoder.  Do you see that?
> 
> The "concern" mentioned there is if the recovery is attempted and then 
> the chip immediately crashes again (or perhaps just fails to start).  
> "Normally" that never happens.  Of course if the hardware is misbevaing 
> or if it is overheating then well anything is possible.
> 
> 
> > 
> > 
> > I don't know how to reload the firmware and do a re-initialization. I
> > assume a modprobe -r would do that? In that case this does not help me.
> 
> If the hardware is truly fouled up, then reloading the driver might not 
> help.  But power-cycling the tuner would probably clear it up.  But the 
> driver should be recovering this for you automatically...
> 
>   -Mike
> 
> 



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?

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 

I'm starting to suspect problematic hardware, but I would like to look
at all other possibilities before I open my wallet. :)

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.

Thanks for your fast reply by the way!!

Regards,
Magnus