[pvrusb2] HVR-1950 gets wedged

[stan schultz]

It looks like bad hardware.  I installed it on a windows box, and it seems
to come up, the red light on the front even comes on, but it won't detect
channels in the scan mode.  So,  back to the store.

Stan

On Thu, Mar 26, 2009 at 4:25 PM, stan schultz <sschultz.or at gmail.com> wrote:

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