I've been using the 6106 driver for a few days, and so far I've been mostly happy with it. The driver seems stable, I don't see tearing in xv anymore, and my ut2004 benchmark runs about 0.4% faster. The one problem I have is that the kernel module refuses to load when rivatv has already been loaded.

This is the error:
====BEGIN====
NVRM: the NVIDIA probe routine was not called for 1 device(s)!!
NVRM: no devices probed, aborting!
NVRM: this often occurs when rivafb is loaded and claims the device's resources.
NVRM: try removing the rivafb module (or reconfiguring your kernel to remove
NVRM: rivafb support) and then try loading the NVIDIA kernel module a gain.
====END=====

Note that that says rivaFB, and not rivaTV; I don't have rivafb loaded at all. If I 'rmmod rivatv' and then 'modprobe nvidia' again, the nvidia module loads without complaint. I can then 'modprobe rivatv', which loads but no longer detects my card, and no longer provides an i2c bus driver.

I presume the problem is that because the nvidia driver now supports temperature monitoring for nvidia-settings, it loads its own i2c driver that prevents rivatv from accessing the i2c bus. If rivatv can't access the i2c bus, then lm_sensors can't read from the lm99 chip in my graphics card.

Though providing a temperature display in nvidia-settings may be useful for some, the sysfs entries lm_sensors provides can be used in a variety of ways not possible with the nvidia-settings program, and is thus much more useful. In my spare time recently I've been working on a couple shell scripts: one script reads sensor data from sysfs and stores the results in a mysql database; the other script reads the database and formats the results into pretty graphs like this one:http://fatooh.org/files/pretty-graph.png

Ironically, the inclusion of temperature monitoring support in the nvidia driver is now preventing me from monitoring the temperature of my nvidia card, and I will probably revert to 1.0-5341 until the problem is fixed; I can think of several solutions.

Solution 1 (if possible):
Move the i2c bus driver from the kernel module to nvidia-settings. I'm pretty sure that it would be able to run in userspace without any special privileges. If so, rivatv could work again and all users would benefit.

Solution 2 (if possible):
Have the nvidia kernel module allow other queries to the i2c bus to "pass through" it. I don't know if that is possible, but then rivatv could work again and all users would benefit.

Solution 3:
Remove the i2c driver from the kernel module and have nvidia-settings read sensors data from sysfs like other well-behaved Linux programs. Rivatv would work again and Linux fans would applaud the cooperation with existing open-source programs, but newbies might have trouble resolving the dependencies.

Solution 4:
Do the same as solution 3, but have nvidia-settings fall back on internal i2c driver if no sysfs data is available. Newbies wouldn't have trouble anymore.

Solution 5:
Have the kernel module attempt to grab the i2c bus, but continue to load even if it can't. Thus, users who want rivatv and lm_sensors instead of nvidia-settings can 'modprobe rivatv' before loading nvidia. Users who don't know better won't load rivatv at all but will still be able to see temperature data in nvidia-settings. Print some appropriate messages in appropriate places to educate users.

I would really appreciate it if somebody were to pay attention to this. Andy? Please?

Both drivers attempt to register a pci_driver for your device and call request_mem_region for BAR0/BAR1; since the device is not a shared resource, only one driver can succeed. This has nothing to do with i2c or nvidia-settings.

Both drivers attempt to register a pci_driver for your device and call request_mem_region for BAR0/BAR1; since the device is not a shared resource, only one driver can succeed. This has nothing to do with i2c or nvidia-settings.

Ok. I guess the correlation between the temperature monitoring in nvidia-settings and rivatv not working was merely coincidental.

I guess you could hack either driver to not claim the device as described above, but I wouldn't recommend that (two drivers accessing the same piece of hardware is one too many).

Thank you for both your replies. I confess that I am rather ignorant about the low-level operation of drivers.

I understand that two drivers shouldn't access the same hardware; however, I know that rivatv and previous versions of the nvidia driver intereroperated without any problems (of which I am aware). I pursued the issue here instead of contacting the rivatv developers because I percieved it to be the change in nvidia's driver breaking rivatv.

I looked in the source files of both rivatv and the interface to the nvidia driver, but my knowlege of C is way too limited for me to even be able to figure out a hack. Do you happen to know what the right fix for the situation would be, or should I ask the rivatv folks?

The NVIDIA driver claims resources using Linux mechanisms designed, in part, to prevent multiple drivers from driving the same resource. Though earlier driver releases didn't do this to the same extent, future releases will continue to do so. If you wish to use rivatv, I guess you'll need to hack either driver (nvidia, rivatv - at your own risk) or use the XFree86 nv driver, instead.

Hi,
same pb for me, and certainly for all guys who have a vidin+nvidia ship graphic card, so I am a bit disappointed by the answer...

It seems to me that hacking a driver is not a reasonable solution for standard linux user. My opinion is that nvidia should take care of existing driver like rivatv, or help them to develop compatible drivers !!