Bug#660983: Licensed Symbol Conflicts with Some Non-GPL Modules
On Friday 02 March 2012 11:18:12 Jonathan Nieder wrote:
> David Baron wrote:
> > Most of the discussion of the -rt seems to be amount linux-audio-users
> > and such. I am not in touch with NC or process control but these will
> > want it also. I believe that they would also be involved with non-gpl
> > software.
> Sorry to have veered so far off-topic. I believe many -rt
> applications have programs in userspace talking to hardware (for
> example using a serial port).
> > I like nouveau very much but unfortunately, there is no openGL in it.
> Depends on your card.
Looked this over, interesting, though I have never figured out how to do
anything explicitely involving the Gallium stuff.
What is the status of Nouveau on Debian Sid and on Experimental for 3.1 and
3.2 kernels. Easy enough to try out but I have not had hardware 3D in the past
with 2.6 kernels.
> > Switching to nouveau means removing its modprobe blacklist and changing
> > xorg.conf. Simple enough but I would like to be able to do this at boot
> > time, either by command or by uname -r (in this case). Otherwise, this
> > becomes a bit of a pain.
> Hm, that sounds like a reasonable request. Blacklisting a driver in
> modprobe.conf does not prevent it being loaded explicitly, and the
> nouveau driver in X explicitly runs "modprobe nouveau" if I remember
> correctly, so there should be no need to unblacklist nouveau, but
> there would still be a need to prevent the nvidia driver from being
> loaded and let X know what's going on.
I have had to take the blacklist off to run it.
> Does DKMS offer a way to build a module only for some kernels? If so,
> perhaps the nvidia X driver could be taught to take care of falling
> back to fbdev or vesa when the kernel-side driver is not loaded.
I do not know. Will simply fail with a message citing the log file.
> > One other regression issue though, maybe to file another bug:
> > mpu401 module will not load. It is there but says "no such device"
> > Loads fine on the non-rt kernel.
> Yep, sounds worth a bug. Be sure to attach full "dmesg" output from
> booting a working and non-working kernel when reporting it.
I will place the bug. Not much information is given by the modprobe, however.