[pvrusb2] Compile issue
cardboil
cardboil at gmail.com
Thu Dec 8 22:13:16 CST 2005
I tried the 20051126 snapshot, but am getting same messages. Here is some
info from /var/log/messages:
<snip>
Dec 9 09:34:47 192 kernel: usb 1-5: new high speed USB device using
ehci_hcd and address 3
Dec 9 09:34:49 192 kernel: Linux video capture interface: v1.00
Dec 9 09:34:49 192 kernel: v4l1_compat: no version for
"struct_module" found: kernel tainted.
Dec 9 09:34:49 192 kernel: pvrusb2: disagrees about version of symbol
tveeprom_hauppauge_analog
Dec 9 09:34:49 192 kernel: pvrusb2: Unknown symbol tveeprom_hauppauge_analog
Dec 9 09:34:49 192 modprobe: 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)
Dec 9 09:34:49 192 usb.agent[3393]: ... can't load module pvrusb2
Dec 9 09:34:49 192 usb.agent[3393]: missing kernel or user mode driver pvrusb2
<snip>
On 12/9/05, cardboil <cardboil at gmail.com> wrote:
>
> 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
> >
>
>
More information about the pvrusb2
mailing list