[pvrusb2] HVR-1950 gets wedged

[Mike Isely]

On Wed, 25 Mar 2009, stan schultz wrote:

> I have a brand new HVR-1950 and am trying to install it on Linux version
> 2.6.27.19-170.2.35.fc10.i686
> 
> When my system comes up, I get the following in /var/log/message:
> 
> Mar 25 23:48:55 localhost kernel: usbcore: registered new interface driver
> pvrusb2
> Mar 25 23:48:55 localhost kernel: pvrusb2: 20081019 (from
> www.isely.net):Hauppauge
> WinTV-PVR-USB2 MPEG2 Encoder/Tuner
> Mar 25 23:48:55 localhost kernel: pvrusb2: Debug mask is 31 (0x1f)

> Mar 25 23:48:55 localhost kernel: pvrusb2: WARNING: Detected a wedged
> cx25840 chip; the device will not work.

I think you're the first person besides me to actually encounter that 
message.  Some history...

Way back when I implemented support for the 24xxx models, I added 
cx25840 support.  This was the first pvrusb2-driven device type to have 
this chip in it (now it's far more common than the saa7115+msp3400 
combination is replaced).  The changes turned out to have been a bit of 
a challenge.  What I had learned at the time was that this was a 
"sensitive" part, and by "sensitive" what I mean is that it will become 
unresponsive if mistreated.  While the cx25840 v4l-dvb module of course 
was not going to mistreat it, I soon discovered that if msp3400 started 
first, it would probe the cx25840's I2C address, treating it like an 
msp3400 of course, and screw it up.  Later when the cx25840 showed up, 
it would fail because by then the chip had already been inadvertently 
wedged by the msp3400 module.  Once the cx25840 part got into this 
state, the only recourse was to power cycle the device.

To defend against this problem, I implemented several addtional features 
in the driver.  The pvrusb2 driver will monitor I2C transfers to this 
chip.  If it sees an attempt to read the chip's version register, and if 
the response is "wrong", then the driver will report the failure you are 
seeing - this is the sign that the chip is wedged.  Also during 
initialization, the pvrusb2 driver will "guard" access to the chip.  It 
will only allow specific expected transfers to reach the part; by doing 
this it blocks any attempts by msp3400 to mess with it, while allowing 
the cx25840 module to get in.  Once the cx25840 module has successfully 
attached and set up, then the pvrusb2 driver will cease any further 
monitoring of the traffic to that part (thus there is normally no 
performance / CPU hit in doing this).

If the guard algorithm is working correctly, then the chip should always 
work and thus you should never see the wedged chip warning.

This strategy has been in place since IIRC late winter 2006.  It has 
worked perfectly over that time.  So now the question is what is the 
problem now?  It could be one of several things:

1. The chip really is getting wedged or the hardware has a problem.  If 
you can try the device in Windows then that would give you an 
independant means to verify the hardware.

2. Or, there's something different about the particular cx25840 you have 
and the driver is falsely detecting a problem.

3. Or, the cx25840 module is having trouble initializing the chip and 
crashing it.

Right now I can't tell which of the 3 this situation is :-(  However I 
can say that if it is (2) then likely there will soon be many other 
reports of problems.  (Anyone?)

One thing which may affect this going forward.  One reason for all that 
careful guarding was to prevent incorrect access to the cx25840 part 
during initialization.  There's a new I2C layer in the kernel now that 
makes it possible to better control who is probing what.  I've recently 
made a large pile of driver changes to take advantage of this (the 
"v4l2-subdev" work mentioned a short while ago).  With the new mechanism 
in place, I can drop this extra logic out of the driver and the 
wedge-detection hack will go away.  Thus (2) would be removed.  However, 
(1) that code blob is not removed yet (was planning on still waiting a 
bit), and (2) unless you're using the latest standalone driver against 
kernel 2.6.29 or later or you are using v4l-dvb, then the new 
v4l2-subdev stuff can't be used.

Anyway, those are my thoughts on this right now.  Verifying the device 
under Windows would eliminate (1).  I can also at least temporarily get 
rid of those monitor/guard hacks (with some caveats) which would allow 
us to eliminate (2) as a cause.

What kernel are you using?  Are you using a v4l-dvb snapshot?


   [...]

> Mar 25 23:48:55 localhost kernel: firmware: requesting
> v4l-cx23885-avcore-01.fw
> Mar 25 23:48:55 localhost kernel: cx25840' 1-0044: firmware load i2c failure

The driver is already screwed up by this point, so it isn't not a 
surprise that the firmware will fail to load.

   [...]

> 
> I have since fetched the *avcore* firmware, but I didn't think I needed
> that. and, the load fails anyways.

Right now, about any cx25840 type of firmware image should work fine.  
(Eventually there is the hope that we'll have the FM radio working, but 
that will definitely require attention paid to the exact cx25840 
firmware used.)


> 
> I pulled both your 2008/10/19 drivers and your 2009/3/15 drivers.  Currently
> using the 10/19 version as it referenced the fix for the wedged chip.

The issue related to the 10/19 driver version was due to a change in the 
2.6.27 kernel that causes EVERYTHING to wedge, not just one chip.  It's 
a different problem, long since solved and only affects you if you tried 
a standalone driver older than 10/19 but using a kernel newer than 
2.6.26.

  -Mike

-- 

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