[pvrusb2] Compile issue

Thu Dec 8 21:34:12 CST 2005

You're right, I did have a another instance floating around under
lib/modules/2.6.../updates/driver/media/video.  So, I renamed those files
and did a depmod -a.  I checked modules.dep file to ensure that the modules
were pointing to the /lib/modules/2.6.../kernel/drivers/media/video
directory where I had copied the tveeprom.ko, tuner.ko, msp3400.ko and
saa7115.ko files created by the ivtv make from your snapshot.

Then, loaded each modules using modprobe (tveeprom, saa7115, msp3400 and
tuner) and then loaded pvrusb2.  Now, I'm back to my old error messages:

# modprobe pvrusb2
FATAL: Error inserting pvrusb2 (/lib/modules/2.6.14-
1.1644_FC4/kernel/drivers/pvrusb2/pvrusb2.ko): Unknown symbol in module, or
unknown parameter (see dmesg)

# dmesg|grep -i pvrusb2
pvrusb2: disagrees about version of symbol tveeprom_hauppauge_analog
pvrusb2: Unknown symbol tveeprom_hauppauge_analog
V4L installed: yes, I did a yum install
Here is the info you requested:

Distro: FC4
Kernel: 2.6.14-1.1644_FC4
Arch: i686
ivtv installed version: ivtv.i386 1:0.4.0-98.rhfc4.at and ivtv-kmdl 1:
0.4.0-98.rhfc4.at
Video4Linux: I did install v4l from rpm -- video4linux.i386 1:
20051112-61.rhfc4.at and video4linux-kmdl-2.6.14-1.1644_FC4.i686  1:
20051112-61.rhfc4.at

Should I not have installed ivtv and v4l?  Appreciate the help.

On 12/9/05, Mike Isely <isely at isely.net> wrote:
>
> On Thu, 8 Dec 2005, cardboil wrote:
>
> > Mike, I can't seem to find the /dev/video0 device, despite a seemingly
> OK
> > hotplug loading.
>
> Unless you've created /dev/video0 yourself, you need udev installed so
> that it will magically appear when appropriate.  Using udev is not a
> strict requirement, but without it you need to manually create the entry.
>
>
> >
> > Also, I noticed the following problems (?) in the dmesg output.
> >
> > pvrusb2 i2c_attach [client=saa7115 @ 0x21 id=0x49]
> >
> > <snip>
> >
> > pvrusb2 upload of pvrusbf2 : 262144 / 262144
> > pvrusb2 Probing for ivtv video decoder driver
> > pvrusb2 pvr2_i2c_saa7115_cmd failed with status -22
> > pvrusb2 Failed to select a viable v4l video decoder driver
> >
> >
> > As you can see saa7115 is not getting attached (there is no "pvrusb2
> > attaching saa7115 I2C client" as in the case of the others like
> tveeprom,
> > msp3400 and tda 9887).
> >
> > Any pointers on what might be happening?
>
> I think you kicked over a fairly big rock here.  Your observation is right
> on the money.  There are two things going on here.
>
> First, any time an I2C chip driver attaches to the I2C bus exported by the
> pvrusb2 driver, the pvrusb2 driver attempts to recognize which driver it
> is and squirrel away its handle for future use.  In this case it failed to
>
> recognize the saa7115 module at all.
>
> Second, there are (AFAIK) two saa7115 modules floating around and they
> have utterly incompatible APIs.  The version that is from ivtv (and also
> supplied by pvrusb2 but it is really ultimately from ivtv) is the older
> and more mature version.  Unfortunately that older version uses a
> completely non-standard API.  The V4L folks are pulling this module into
> the V4L tree, but in doing so they've reworked the API to be consistent
> with other chip drivers that are already in V4L.  Thus two modules, two
> incompatible APIs.  The pvrusb2 driver, wanting to be robust in the face
> of change, tries to detect which type of driver it is talking to.  It does
>
> this by sending a command to it and looking at the response; e.g. to
> detect the newer driver it will send a standard query which is
> unimplemented in the ivtv version thus the response can be used to tell
> them apart.  The pvrusb2 driver can be configured at compile time to look
> for either or both versions (examine compat.h for comments on how to
> control this).  By default it looks for everything.  Anyway, this
> detection process can result in the -22 status message you see, and in
> that case it's OK.
>
> However in your case since the module completely failed to be recognized
> by the driver, the subsequent detection to figure out *which* version it
> had was a waste of time and failed.
>
> The root cause is to figure out why the chip driver wasn't recognized.  A
> key clue here is the id of 0x49 that was reported.  That's a value I
> didn't expect.  The pvrusb2 driver uses that id (mostly) to recognize chip
> drivers.  We need to figure out where 0x49 came from.  I have a suspicion,
>
> but I'll have to chase that down later.
>
> To dig deeper, I need to know what kernel you compiled against, whether or
> not you have ivtv installed (and which version), and also whether or not
> you have patched up or otherwise built & installed a later V4L version
> into the kernel.  All those things affect where saa7115 comes from.
>
> You might be able to work around this by using the saa7115.ko that can be
> built with the pvrusb2 driver.  If you try that, make sure you unload the
> existing driver from memory, rename conflicting instances of the driver
> that might be floating around in your modules tree, and rerun depmod -a
> after you change things.
>
> If we can figure out where this ID of 0x49 is coming from, I can attempt
> to adjust the pvrusb2 driver to account for it.
>
> I know there's other e-mail here that I haven't answered yet.  I will
> fully catch up on everything later tonight.
>
>    -Mike
>
>
> --
>                          |         Mike Isely          |     PGP
> fingerprint
>       Spammers Die!!     |                             | 03 54 43 4D 75 E5
> CC 92
>                          |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5
> C1 E8
>                          |                             |
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>