# kernel module auto loading cached?

## Gentree

Hi,

after recently updating world I have a couple of problem that appear to be due to some kind of caching of kernel modules loaded during startup. 

Firstly nvidia (proprietory) keeps getting loaded before I try to start X. I recently decided to move to using nv but each time I start X it fails saying a module (ie nvidia) is already claiming the hardware. 

I have to su, rmmod nvidia, then exit and all works correctly. 

I can't see why this module is getting loaded during start up when I just boot to console. 

Where should I look?

TIA, Gentree.   :Cool: 

(the other issue is wlan0 which I will post separately)

----------

## ppurka

Simply add nvidia to /etc/modprobe.d/blacklist.conf. And it will be never loaded automatically.

----------

## Gentree

 *ppurka wrote:*   

> Simply add nvidia to /etc/modprobe.d/blacklist.conf. And it will be never loaded automatically.

 

thanks, but that's not my question. 

I want to know why it is being loaded in the first place. My impression is that there must be somewhere where this has been stored as being "used last time" or something. In fact it was not used last time since I now have to remove this module by hand every damn time I boot. But it must be in a config somewhere. 

xorg.conf is configured for nv , so why is this getting loaded at all?

 :Cool: 

----------

## ppurka

I suppose it might be loaded by udev. Did your system upgrade also update udev?

----------

## Gentree

Yes, there was a udev update and I found the following in /etc/conf.d/udev

#rc_device_tarball="NO"  

#rc_coldplug="YES"

 commented out , presumably this is the default. Uncommenting tarball did not change anything.

from dmesg:

```

8139too Fast Ethernet driver 0.9.28

8139too 0000:01:06.0: PCI INT A -> Link[APC3] -> GSI 18 (level, high) -> IRQ 18

eth0: RealTek RTL8139 at 0xc000, 00:08:a1:73:74:e9, IRQ 18

8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)

forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64.

ACPI: PCI Interrupt Link [APCH] enabled at IRQ 22

forcedeth 0000:00:04.0: PCI INT A -> Link[APCH] -> GSI 22 (level, high) -> IRQ $

forcedeth 0000:00:04.0: setting latency timer to 64

nv_probe: set workaround bit for reversed mac addr

udev: renamed network interface eth0 to eth_real

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver

ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver

[b]nvidia: module license 'NVIDIA' taints kernel.

Disabling lock debugging due to kernel taint[/b]

ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19

nvidia 0000:02:00.0: PCI INT A -> Link[APC4] -> GSI 19 (level, high) -> IRQ 19

```

So it looks like udev is the culprit, but why?

Where is it getting the idea someone asked it to auto the proprietory nvidia kernel modules ?

 :Confused: 

----------

## pigeon768

 *Gentree wrote:*   

> So it looks like udev is the culprit, but why?
> 
> Where is it getting the idea someone asked it to auto the proprietory nvidia kernel modules ?

  The hardware exists, and a driver exists for the hardware, therefore the driver is loaded. I believe this is a function of the kernel module autoloader; once the module is loaded the kernel tells udev to deal with the new devices. I would not presume that udev is causing the module to be autoloaded.

----------

## Jaglover

 *Quote:*   

> The hardware exists, and a driver exists for the hardware, therefore the driver is loaded.

 

This logic is not flawless. Hardware exists but is not used, no need to load the module. nVidia driver used to load when X started, why load it if user is at console.

----------

## roarinelk

 *Jaglover wrote:*   

>  *Quote:*   The hardware exists, and a driver exists for the hardware, therefore the driver is loaded. 
> 
> This logic is not flawless. Hardware exists but is not used, no need to load the module. nVidia driver used to load when X started, why load it if user is at console.

 

Simple: udev is looking for a module which claims to support the PCI ID of the nvidia

card.  A nvidia module which supports those is present for the running kernel and so

it is loaded.   Most of the time you need to load a driver for device nodes to appear in the

first place.  Same as with every other piece of hardware.

The easiest way to solve this is to simply delete the nvidia.ko file from /lib/modules/`uname -r`/ tree

and rerun "depmod -ae".

----------

## Gentree

the proprietory driver is not "in the kernel" any more that nv is.  

nvidia_agp may be relevant to the PCI device but the video driver should not get loaded until I start X. Then (and only then) should it load what is in the modules section of xorg.conf in the section matching the hardware.

I want to keep the option of using either driver so simply working around the problem by blacklisting or totally removing the driver is not what I need. 

I want to understand and solve the problem not fudge around it. 

What is loading nvidia driver when I boot to console?

 :Cool: 

----------

## ppurka

 *Gentree wrote:*   

> the proprietory driver is not "in the kernel" any more that nv is.  

 I don't think the nv driver has a specific kernel component or module. That could explain why nvidia gets loaded first.

----------

## Gentree

hi,

nouveau.ko and drm.ko are kernel modules. The proprietory drivers serve a whole range of products  What do you mean by "specific"?

 *Quote:*   

> That could explain why nvidia gets loaded first.

 

My question is not which gets loaded "first" but why and HOW nvidia module is getting loaded before I start X.

I can understand the linux nvidia_agp module getting loaded for the AGP (ie PCI) hardware. That is not a problem.

What I need to know  rather than guess with hand-wavey arguments is what mechanism is loading nvdia unecessarily so I can FIX it. 

I have not found anything that suggests that having the two modules installed is anyway incompatible and that either one or the other must be physically removed. 

This must be a configuration problem. Something is stored , cached or configured to pull in nvidia prematurely. It should not be loaded before X does it from information in xorg.conf.

 :Mad: 

----------

## roarinelk

 *Gentree wrote:*   

> 
> 
> My question is not which gets loaded "first" but why and HOW nvidia module is getting loaded before I start X.
> 
> 

 

udev does, based on information provided by the kernel that a PCI device with a nvidia VID/PID exists which a

kernel module that resides in /lib/modules/`uname -r`/  claims to support.

So, delete the nvidia.ko file in /lib/modules/`uname -r`/video/  or emerge --unmerge nvidia-drivers.

----------

## ppurka

 *Gentree wrote:*   

> hi,
> 
> nouveau.ko and drm.ko are kernel modules. The proprietory drivers serve a whole range of products  What do you mean by "specific"?

 Ha! I didn't realise you were speaking of nouveau and not nv. nouveau of course has a kernel component. In fact in some posts in nvnews.net u will find that people are complaining that nouveau gets loaded before nvidia. Sorry, can't help you any further since I lack the knowledge of how exactly it works.

----------

## Jaglover

This is outrageous, I boot to the console and nvidia is loaded, which is an X driver. Then I put in a DVD and it doesn't mount because udf module is not loaded and I have to load it by hand.   :Evil or Very Mad:  What happened to kernel module autoloading?

----------

## roarinelk

 *Jaglover wrote:*   

> This is outrageous, I boot to the console and nvidia is loaded, which is an X driver. 

 

This is where you're wrong: "nvidia" is also kernel driver. PCI is plug-and-play so when udev sees a matching

kernel module for a kernel reported pci device it loads the kernel driver.

UDF on the other hand can't be autoloaded on demand since unless a filesystem handler

for a particular format has been registered (module loaded in your case) there is no way

to identify the filesystem in the first place.  So unless the udf module is loaded there is no

way the kernel can ask the fs core to identify the fs on the dvd as udf.

----------

## Gentree

 *roarinelk wrote:*   

>  *Jaglover wrote:*   This is outrageous, I boot to the console and nvidia is loaded, which is an X driver.  
> 
> This is where you're wrong: "nvidia" is also kernel driver. PCI is plug-and-play so when udev sees a matching
> 
> kernel module for a kernel reported pci device it loads the kernel driver.
> ...

 

Isn't agpart the PCI driver and nvidia the video (xorg) driver ?

BTW, forget nouveau, I was confused by a lot places where it is referred to as the new version of nv. I thought it was the same thing. I now realise it is a completely independent project.  I'm trying to use nv here. 

 :Rolling Eyes: 

----------

## Ant P.

If you want to stop nvidia from autoloading, just make sure the nv module and nvidia framebuffer module gets loaded first or built in. Or just uninstall nvidia-drivers until you need it again.

----------

## roarinelk

 *Gentree wrote:*   

>  *roarinelk wrote:*    *Jaglover wrote:*   This is outrageous, I boot to the console and nvidia is loaded, which is an X driver.  
> 
> This is where you're wrong: "nvidia" is also kernel driver. PCI is plug-and-play so when udev sees a matching
> 
> kernel module for a kernel reported pci device it loads the kernel driver.
> ...

 

agpgart is a support module to handle AGP-specific functions (GART management, setting bus speed, ...)

nvidia is the name for both the X driver and the kernel module, the X part requires the kernel part to work.

nv on the other hand is a pure X driver and afaik doesn't need a kernel counterpart. I think it doesn't

even work when a kernel driver has claimed the graphics device, so remove nouveau, nvidiafb/rivafb from

the kernel config.

----------

## augury

 *Quote:*   

> I want to keep the option of using either driver so simply working around the problem by blacklisting or totally removing the driver is not what I need. 

 

You have two modules for what I would assume is one device.  Neither one is "compatible" with the other.  

The solution is blacklisting one of them.  You could do that in anyway you choose.  Two modules with identical form/function/purpose is obviously what you want to avoid.

----------

## Jaglover

 *roarinelk wrote:*   

> 
> 
> This is where you're wrong: "nvidia" is also kernel driver. PCI is plug-and-play so when udev sees a matching
> 
> kernel module for a kernel reported pci device it loads the kernel driver.
> ...

 

Alright, maybe you are right about nvidia, although I remember it did not get loaded before, this behavior is new.

But UDF is where you are wrong, I always had udf, loop and some other seldom needed functionality built as modules. And I did not need to load them by hand.  Now udf and loop do not load automatically on demand any more.   :Evil or Very Mad: 

----------

## Gentree

 *ppurka wrote:*   

> Simply add nvidia to /etc/modprobe.d/blacklist.conf. And it will be never loaded automatically.

 

finally this was the best solution. This prevents kernel autoloading but not later loading by xorg as needed. 

So now I can edit xorg.conf and toggle between nvidia and nv whilst keeping both on the system which is what I required. 

thank ppurka   :Wink: 

 *roarinelk wrote:*   

> agpgart is a support module to handle AGP-specific functions (GART management, setting bus speed, ...) 

 

nvagpart was a total redherring, it deals with the mother board chipset controlling the AGP slot. This also happens to be nvidia (GeForce2) on this mobo but has nothing to do directly with support for the graphics card itself.  It would still be required if I was using an ATI card (however unlikely that may be  :Wink:  ).

----------

