[pvrusb2] Error messages

Mike Isely isely at isely.net
Sat Oct 31 18:23:31 CDT 2009


On Fri, 30 Oct 2009, Ken Bass wrote:

> What causes and is there any concern that I am seeing the following in my
> logs:
> 
> cx25840 3-0044: firmware: requesting v4l-cx25840.fw
> cx25840 3-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
> cx25840 3-0044: 0x0000 is not a valid video input!
> cx25840 3-0044: firmware: requesting v4l-cx25840.fw
> cx25840 3-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
> cx25840 3-0044: 0x0000 is not a valid video input!
> cx25840 3-0044: firmware: requesting v4l-cx25840.fw
> cx25840 3-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
> cx25840 3-0044: 0x0000 is not a valid video input!
> cx25840 3-0044: firmware: requesting v4l-cx25840.fw
> cx25840 3-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
> cx25840 3-0044: 0x0000 is not a valid video input!
> cx25840 3-0044: firmware: requesting v4l-cx25840.fw
> cx25840 3-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
> cx25840 3-0044: 0x0000 is not a valid video input!
> 
> Why does the firmware get requested and reloaded while the box is up? I am not
> aware of any power resets. Also, the 'not a valid input'- what causes that?
> 
> This is being used under MythTv 0.22RC1.
> 
> I also have PVR-250 cards installed in the same box.


Not to worry.  Here's what is going on - assuming that you've shifting 
in / out of digital mode:

First, the cx25840 firmware is being requested by the cx25840 sub-device 
(i.e. cx25840.ko) not the pvrusb2 driver.  And this is happening due to 
switching to/from digital mode.  The cx25840 is really not used when in 
digital mode and can get into a confused state because of that.  So when 
moving back to analog mode the chip is being reinitialized.  Part of 
that initialization requires reloading of the firmware.

The "not a valid video input" message is related to the same issue.  
When in digital mode the "video input" being used is not relevant to the 
cx25840 and the pvrusb2 driver is sending it bogus information as a 
result.  To fix this the pvrusb2 driver needs to be able to propagate 
the concept of "none" for a video input when dealing with inactive 
sub-devices.  It's not a trivial fix, but also not rocket science 
either.  I've just had bigger fish to kill and this doesn't cause any 
harm - since we reinitialize the entire chip anyway when coming back to 
analog mode.

  -Mike



More information about the pvrusb2 mailing list