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