[pvrusb2] Problem with wintv-hvr-1950

[Mike Isely]

On Tue, 10 Mar 2009, jim steele wrote:

> I started writing my email reply after I got the debug output, and I
> had left the cp command running, and eventually the errors stopped
> repeating. It took a while but now it is working fine. I just had to
> wait about 45 seconds. Subsequent runs do not produce any errors.

What the %$$#!#???

Oh wow.  There's something seriously wrong here.  Look at the firmware 
size being loaded.  It's way too small, and it isn't consistent:

pvrusb2: upload of v4l-cx2341x-enc.fw : 12288 / 12288
pvrusb2: upload of v4l-cx2341x-enc.fw : 16384 / 16384
pvrusb2: upload of v4l-cx2341x-enc.fw : 16384 / 16384
pvrusb2: upload of v4l-cx2341x-enc.fw : 16384 / 16384
pvrusb2: upload of v4l-cx2341x-enc.fw : 12288 / 12288
pvrusb2: upload of v4l-cx2341x-enc.fw : 20480 / 20480

Those numbers should be somewhat north of 256000 each time; the firmware 
loader must be having a serious problem reading the firmware image file.  
That size is not known ahead of time by the driver.  Rather, the pvrusb2 
driver is relying on the kernel's generic firmware loading mechanism 
(which cooperates with userspace) to retrieve the firmware file and load 
it into memory, whereupon the pvrusb2 driver spoonfeeds it into the 
encoder's memory.  The number to the left of the '/' is the number of 
bytes it sent to the encoder while the number to the right of the '/' is 
the file image size as reported by the kernel firmware loading module.  
The fact that they equal each other means that the pvrusb2 driver is 
doing its job - but it's clearly being handed garbage because the actual 
file size is WAY larger than these values (and in any case it should be 
consistent).

There are other firmware images that the pvrusb2 driver loads, however 
they are all far smaller than the thresholds here.  For example the FX2 
firmware is only 8KB, and the cx25840 firmware is less than 16KB - so if 
your system is having trouble reading large files then those cases 
likely won't be affected.

Obviously if less than 10% of the encoder's firmware code is actually 
getting loaded, then there's no way it's going to work.  You said it 
started working after 45 seconds.  That sounds to me like after dozens 
of attempts it somehow managed to read the entire firmware image.

I think you need to look at your beagleboard setup and ask yourself if 
there's any way that file I/O on the system could be having problems.  I 
can see an NFS client mount with soft error behavior on a flakey network 
connection doing this - but beyond that nothing comes to mind that 
ultimately wouldn't relate to flakey disk hardware.


> 
> Thanks for your assistance on this.

I don't think you're out of the woods yet :-(

  -Mike

-- 

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