[pvrusb2] encoder firmware reload [was: Kernel 2.6.18 released - with pvrusb2 included]

[Mike Isely]

On Thu, 21 Sep 2006, Andreas Korinek wrote:

> On Thursday 21 September 2006 09:44, Frans Meulenbroeks wrote:
> > Congratulations Mike!
> 
> Funny, sometimes I get
> 
> pvrusb2: ***WARNING*** device's encoder appears to be stuck (status=000000003)
> pvrusb2: Encoder command: 0x81
> pvrusb2: Giving up waiting.  It is likely that this is a bad idea...
> pvrusb2: Error recovery initiated
> pvrusb2: Retrying device reconfiguration
> pvrusb2: size of v4l-cx2341x-enc.fw firmware must be a multiple of 8192B
> pvrusb2: Failure uploading encoder firmware
> 
> when changing channels. I never got that firmware message in any snapshot. 
> I can only fix this by removing and reinserting the module.
> Does anyone else see this?
> 

Several things here.

First, about the warning.  What's happened here is that the driver issued 
a command to the encoder and the encoder failed to acknowledge the 
command.  The driver polls a status register in the encoder, watching a 
bit to change.  If it never changes, the driver gives up waiting, 
concludes that the encoder has crashed, and initiates recovery by 
reloading the encoder's firmware and restarting it.  That's the first 5 
lines of the log snippet above.  And this scenario is not necessarily a 
fatal problem.  Unfortunately I've seen it happen numerous times; this is 
why I put the recovery action into the driver.  I have spent 
_considerable_ time trying to track down possible cause(s) for this but 
unfortunately the encoder is just a big barely documented black box so 
it's very difficult to handle.

Now, the new problem here is in the last 2 lines of that snippet.  That 
leaves me very worried.  Line 6 there is a message resulting from a sanity 
check in the firmware loading code within the driver.  The encoder 
firmware should be 256KB in size, in fact it should be exactly 256KB.  
The loader code merely checks that the size of the firmware data is a 
multiple of 8KB.  This sort of error should only happen if the firmware 
file you installed was somehow corrupted or truncated.  Yet, the fact that 
it loads correctly on hot-insert but then fails later suggests something 
has gone seriously wrong with the firmware loading code.  I mean, geez, 
it's the same file each time so why should the measured size of it ever 
change?

The firmware loader within the pvrusb2 driver is rather simple.  It also 
hasn't changed in any meaningful way since roughly last February (when I 
added support for loading of two possible files depending on PVR USB2 
model type).  In reality, all the firmware loader does is call out to 
another kernel module (firmware.ko) to retrieve the firmware file into a 
local buffer.  Then the loader feeds the data out to the PVR USB2 device.  
If the data retrieved from the firmware kernel module isn't a multiple of 
8KB in size, then this error results.  The actual act of retrieving the 
firmware data from the file system is "black magic" left to the firmware 
module, which has nothing specific to do with the pvrusb2 driver.

Given that (1) there's little that can go wrong in the pvrusb2 driver for 
this, (2) that the code in question hasn't changed for months, and (3) 
that it's failing only intermittently for you (meaning that you must 
actually have a correct firmware image), then my first guess is to suspect 
that a bug has surfaced in the kernel's firmware module and/or the 
userland process which helps it (hotplug or udev).

1. Has anyone else seen this behavior?  I'm not talking specifically about 
the _need_ to reload the firmware, but rather that the reload failed with 
an error like this.

2. You mentioned that you haven't seen this with any standalone pvrusb2 
snapshot.  The code in question is the same either way.  Can you try the 
standalone driver in the same kernel (just rename the existing pvrusb2.ko 
out of the way and you'll be fine) and see if the problem still happens?  
I'm betting it will.

I will try to reproduce the problem here.

One other thing which might affect this problem.  The only time the 
encoder is really being touched is when it is stopped / started.  There 
are some rules in the driver about when it stops / starts the encoder and 
that has been in some flux over time.  I'll have to check my notes but 
it's probably stopping the encoder as a prerequisite to changing channels.  
One might be able to argue that this isn't needed and I could probably 
change that behavior.  However that doesn't solve the root problem - that 
of the encoder needing to be reloaded and the reload apparently failing.

  -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
                        |                             |