[pvrusb2] HVR-1950 gets wedged

Thu Mar 26 18:25:08 CDT 2009

The Kernel I am using is 2.6.27.19-170.2.35.fc10.i686.  I will see if it
works on a windows box tonight..

Thanks!

Stan

On Thu, Mar 26, 2009 at 8:51 AM, Mike Isely <isely at isely.net> wrote:

> 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
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>