| Summary: | modules.autoload.d/kernel-2.6 and udev-089-r2: module loaded without options | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Volker Hemmann <volkerarmin> |
| Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | artedogesto, deluge, dominique.c.michel, heiko.baums, ikelos, jrmalaq, ladanyi, manschwetus, Martin.vGagern, perry, philantrop, polynomial-c |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 130766, 145962 | ||
| Bug Blocks: | 126089 | ||
| Attachments: | Conexant CX23880/1/2/3 PCI Video and Audio Decoder | ||
|
Description
Volker Hemmann
2006-04-06 10:05:40 UTC
Add bttv to the module blacklist list so that it is not automatically loaded by udev/modprobe during the boot process. Then, the modules.autoload stuff will still load the module properly. Or you can add that option to the modules.config file so that when it is automatically loaded, it will be loaded with the proper option. Hi, thanks, blacklist did the trick. Adding the option to /etc/modules.conf did not change anything, but blacklist gave back the desired behaviour. Hm, it would be nice to have blacklist mentionend in the udev-guide, or have at least an ewarn about modules.autoload.d not working when the modules are not blacklisted. Because the problem appeared after the last update and this seems to be a change of behaviour, or am I totally wrong? *** Bug 130031 has been marked as a duplicate of this bug. *** Yes, it's a potentially big change in behavior (different for different motherboard/BIOS combinations from recent observations). The problem described below was not fixed by blacklisting any modules either (since the problem occurs when udev probes things right after init starts but before the modules script or any real hotlpug stuff is run). Two machines with the udev update (one with the newest baselayout, one without) had this problem: Two ethernet interfaces using different modules and controlled by alias entries: alias via-rhine eth0 alias 8139too eth1 works fine with the old coldplug/udev setup, but the new udev probes too soon and randomly brings up one or the other interface as eth0 (so obviously the normal network connection dorks up). One of the above machines (one with an older BIOS) also had problems with the above probing of the usb controllers, which caused it to dork up a USB stick when inserted (the endless looping of usb addresses). As above, unloadiing the modules and then reloading the desired ones (via-rhine in the case of the ethernet problem, and uhci-hcd in the case of the usb problem) made everything work as expected. It looks like the answer is the new baselayout (conf.d/rc) option called RC_COLDPLUG, however, the new udev/no-coldplug thing does not depend on this version of baselayout (so you can get caught with the new udev behavior and no real way to control it). Let me repeat, this problem occurs too early in the init process for any hotplug or module/alias settings to have any effect. The default for the above option is Yes, which is about as far from the old behavior as possible. I tried setting it to No, but udev still seemed to probe just as much as when it was set to Yes (and the problems still occured). It was only when I tried one of the examples (RC_COLDPLUG="!net-*") that udev stopped probing everything under the sun and I got what resembles a normal bootup. I haven't rebooted it yet (daughter's machine :) but I'll post any updates after testing on this box a few times. It seems that the last poster has a few different issues here. Care to just file individual bugs? Oh, and use udev to handle naming your network devices, don't rely on the module config file to do that. Hi, I don't know if his problem is different, but mine is back with udev-090, which is very frustrating. I just don't want udev&co load some modules - blacklist worked for a short time, but since last night, bttv&scsi modules are loaded again - and bttv without any options. Seems that udev changes behaviour with every release . . . And the blacklisting of modules does not work? udev did not change in that regards for the 090 release, it works the same as 089 did. Make sure your modules.conf file is still correct. Hi, I had it 'working' with 089 like it should. bttv and aic7xxx added to /etc/hotplug/blacklist and both were not loaded by udev. bttv in modules.autoload.d/kernel-2.6 with card=25 as option. I updated to 090 and suddenly blacklist is ignored. Both are loaded by udev, with bttv loaded without any options, so I am forced to rmmod and modprobe it again to get my card working and aic7xxx delaying boot 15seconds. here is some dmesg parts: bttv loaded by udev: [ 148.837974] Freeing unused kernel memory: 160k freed [ 151.788754] Linux video capture interface: v1.00 [ 151.855996] bttv: driver version 0.9.16 loaded [ 151.856048] bttv: using 8 buffers with 2080k (520 pages) each for capture [ 151.856128] bttv: Bt8xx card found (0). [ 151.856187] GSI 19 sharing vector 0xD9 and IRQ 19 [ 151.856235] ACPI: PCI Interrupt 0000:04:06.0[A] -> GSI 21 (level, low) -> IRQ 217 [ 151.856334] bttv0: Bt848 (rev 18) at 0000:04:06.0, irq: 217, latency: 32, mmio: 0xd7eff000 [ 151.856431] bttv0: using: *** UNKNOWN/GENERIC *** [card=0,autodetected] [ 151.856513] bttv0: gpio: en=00000000, out=00000000 in=00ffffff [init] [ 151.860898] tveeprom 0-0050: Huh, no eeprom present (err=-121)? [ 151.860947] bttv0: using tuner=-1 [ 151.860992] bttv0: i2c: checking for MSP34xx @ 0x80... not found [ 151.863229] bttv0: i2c: checking for TDA9875 @ 0xb0... not found [ 151.865449] bttv0: i2c: checking for TDA7432 @ 0x8a... not found [ 151.867676] bttv0: i2c: checking for TDA9887 @ 0x86... not found [ 151.869932] bttv0: registered device video0 [ 151.869990] bttv0: registered device vbi0 bttv rmmod'ed and modprobed by hand after boot: [ 205.043665] bttv0: unloading [ 208.155402] bttv: driver version 0.9.16 loaded [ 208.155406] bttv: using 8 buffers with 2080k (520 pages) each for capture [ 208.155641] bttv: Bt8xx card found (0). [ 208.155650] ACPI: PCI Interrupt 0000:04:06.0[A] -> GSI 21 (level, low) -> IRQ 217 [ 208.155659] bttv0: Bt848 (rev 18) at 0000:04:06.0, irq: 217, latency: 32, mmio: 0xd7eff000 [ 208.155669] bttv0: using: Terratec TerraTV+ Version 1.0 (Bt848)/ Terra TValue Version 1.0/ Vobis TV-Boostar [card=25,insmod option] [ 208.155689] bttv0: gpio: en=00000000, out=00000000 in=00ffffff [init] [ 208.663503] bttv0: tea5757: read timeout [ 208.663507] bttv0: using tuner=5 [ 208.663549] bttv0: i2c: checking for MSP34xx @ 0x80... not found [ 208.664627] bttv0: i2c: checking for TDA9875 @ 0xb0... not found [ 208.665702] bttv0: i2c: checking for TDA7432 @ 0x8a... not found [ 208.666776] bttv0: i2c: checking for TDA9887 @ 0x86... not found [ 208.684728] tuner 0-0060: All bytes are equal. It is not a TEA5767 [ 208.684732] tuner 0-0060: chip found @ 0xc0 (bt848 #0 [sw]) [ 208.684966] tuner 0-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles)) [ 208.701238] bttv0: registered device video0 [ 208.701344] bttv0: registered device vbi0 The modules.conf file is from 04/13 and was not touched since then - and it worked until the 090 update. Besides - I don't see the point in editing a file that is automatically generated. (In reply to comment #8) I'm having the same problem with my bttv module. The modules are in the blacklist and it worked with udev-089 but broke with udev-090. This is still an issue... all mine... Hi, first of all, sorry Greg but I gotta tell that here. This new behavoiur of udev is a real p.i.t.a. and I'm very glad that I found a solution against this nasty autoloading of all these modules. The whole problem is caused by udevtrigger which is used for kernels >=2.6.14 in favour of udevstart. And that's what I changed to get rid of modules autoloading during boot. I altered the udev startscript, which is /lib/rcscripts/addons/udev-start.sh, to use udevstart for all kernels even 2.6.14 or higher instead of udevtrigger. It's easy to reproduce. Boot up your machine, rmmod some modules you don't wanna have loaded at all and run udevtrigger... voila the modules are back again. Then repeat these steps but this time use udevstart... bingo... no unwanted modules were loaded. If you wanna alter udev-start.sh yourself, I posted a patch @ http://forums.gentoo.org/viewtopic-p-3456233.html#3456233 I know that this is no solution for you Greg, but I do not like this new behavoiur of udev in any way. udev for me was always a daemon to handle devicenodes, nothing else. And as long as there is no easy way to prevent udev from loading all that crap at bootup, I will continue using the above mentioned method. Cheers Polynomial-C (In reply to comment #12) > I know that this is no solution for you Greg, but I do not like this new > behavoiur of udev in any way. udev for me was always a daemon to handle > devicenodes, nothing else. Agreed. Module autoloading is something that has traditionally been handled by the kernel and should *not* be handled by udev. (In reply to comment #13) > > Agreed. Module autoloading is something that has traditionally been handled by > the kernel and should *not* be handled by udev. Sorry, but no, it has not been "traditionally" done by the kernel, the startup scripts and coldplug did it, combined with hotplug during runtime. udev replaces all of this into one simpler package, and provides more flexibility. If you don't like certian modules being autoloaded at boot time, just put them in your module blacklist, or change the rc value to not have modules loaded automatically at startup time. Greg, you know, there really was Linux *before* Gentoo. :-) During those dark times, it was the kernel which autoloaded modules. Wonderously, it still has this capability. And even after my enlightenment and coming to Gentoo, it was my *kernel* that loaded my modules because I wasn't forced to use coldplug and/or hotplug. Only lately did someone decide it would be a good idea to take away my choices and any meaning for kernel modules by loading them unconditionally on startup. Blacklisting them is *not* a solution as the problem was artificially introduced. It may be easier for you but it makes it harder for the users. Which rc option would it be, btw? I've played with both RC_HOTPLUG and RC_COLDPLUG but both of them failed to stop this module madness (mm). Alright, excuse me Greg, I really said some stupid things. But to be honest I got very mad when I realized that udev caused my three soundcards to be mashed up every boot again. I did that RC_COLDPLUG="no" and everything works(tm) again :) Maybe RC_COLDPLUG should be set to "no" by default? b.t.w. modules-blacklisting doesn't work on any machine with udev here. I tried that with my laptop (yenta_socket module) but the module still got loaded by udev. At least this seems to be an issue... regards Poly-C Okay, for me RC_COLDPLUG="no" works now - sort of. Now udev doesn't load any modules anymore but it doesn't create the device nodes either which is even worse because the kernel can't autoload the modules anymore when I try to access them. Blacklisting doesn't work for me either. I just want udev to create the device nodes and leave the rest to me. How do I achieve that? Philantrop, As of udev-094 (or 096, I'm not certain) and the latest baselayout, here's a rundown of what does what: * RC_COLDPLUG="no" will stop the modules being automatically loaded by udev. * /etc/modules.autoload.d/kernel-2.6 should still allow to you add specific modules, which should create the devices nodes you're after, and should make use of the module options specified in your modules.d files. * RC_PLUG_SERVICES will then allow you to specify when services are started when devices are detected (and I believe this includes both "hot" and "cold" plugged devices). * Blacklisting modules seems not to do anything what-so-ever anymore. As such, can this bug now be closed? (In reply to comment #17) > I just want udev to create the device nodes and leave the rest to me. How do I > achieve that? I believe it is technically impossibly to just create the appropriate device nodes for plugged hardware. The kernel only knows which modules to use for which hardware component, and only the modules themselves know what device nodes they want. At least that's my understanding. So you would have to load the modules. On the other hand, if you know what hardware you might have around, you could probably make use of RC_DEVICE_TARBALL="yes" in /etc/conf.d/rc and create your device nodes manually while setting RC_COLDPLUG="no". I haven't tried it, mind. (In reply to comment #18) > * Blacklisting modules seems not to do anything what-so-ever anymore. Judging by the discussion here that's a bug. (Or at least I hope so. :) ) It would be great if that could be fixed. > As such, can this bug now be closed? That would be up to the reporter (Volker) or Greg to decide, I guess. Hi, I have the modules I do not want to have loaded in /etc/hotplug/blacklist AND set RC_COLDPLUG="no" and it works for now. But I also use unstable - and I don't know if this bug is still present with stable. IMHO, even with RC_COLDPLUG="yes", blacklist should be honored. If it does not (does it? I don't know, too tired to try at the moment) honor blacklist, this bug should stay open. And I don't know what happens, when RC_COLDPLUG is set yes, and you want the modules loaded with certain options. imho of course... I am just a stupid user who does not want several modules loaded... only a selected few - and that selected few modules with certain options. So it is really up to Greg to close this bug. I hadn't tried to load modules with options yet, so I don't know if this really fits to this bug, but I think the whole udev/hotplug problems appear because both udev and hotplug/coldplug are installed parallel. I had several issues with the new udev until I had the idea to uninstall not only coldplug but also hotplug. Now I don't have any problems with udev's hotplug/coldplug functionality. I described it in the forum at http://forums.gentoo.org/viewtopic-p-3534506.html#3534506 and in bug #143660. Possibly this could solve this bug. If yes then udev should not only block coldplug but also hotplug. (In reply to comment #21) > IMHO, even with RC_COLDPLUG="yes", blacklist should be honored. If it does not > (does it? I don't know, too tired to try at the moment) honor blacklist, this > bug should stay open. Those blacklisting problems are bug 130766 which is a dependency for this one. This bug here is probably not the place to discuss that issue by itself, only in relation to module options. I haven't tried those so far. My 2 cents contribution: Udev will not check for the options in modules.conf or in modules-autoload, it have its own rules in /etc/udev/*. I get the same problem with alsasound and my webcam. When the snd-usb-audio is in the hotplug blacklist file, the order of my sound cards is correct. But when it is not blacklisted, udev load it first and don't care of the index=1 in modprobe.conf, so I get it as card 0. If I run "/etc/init.d/alsasound restart", the sound cards order is correct according to modprobe.conf. A quick fix will be maybe at "alsasound start" first check if it is some already loaded sound modules and unload them before to load them according to modprobe.conf. So it would work in any cases and it would be no need to blacklist. *** Bug 157355 has been marked as a duplicate of this bug. *** Created attachment 103479 [details]
Conexant CX23880/1/2/3 PCI Video and Audio Decoder
My device also does not load with the certain parameters, then use this fast solution.
Comment on attachment 103479 [details]
Conexant CX23880/1/2/3 PCI Video and Audio Decoder
My device also does not load with the certain parameters, then use this fast solution.
I have the same problem as Comment #24. I have four soundcards in my system. Before upgrading to the new udev, the index=# was honoured and my different cards got the same id at ever boot. Now the id's are random after every time I boot. Doing "/etc/init.d/alsasound restart" after every boot is not fun. Blacklisting drivers in udev, doesn't feel completely right either. This is a bug and is going to be fixed, right? (In reply to comment #28) I think I got the problem to disappear. I changed the line "RC_PLUG_SERVICES="!*"" in /etc/init.d/rc. I think all this new udev functionality needs to be documented somewhere for everyone to see. There seems to be more than one thread on the forums discussing different problems due to these changes. Hi, update system, udev to 104, baselayout to 1.12.9. modules are loaded without options again. I have to reload them after boot. That is not pretty. (In reply to comment #30) > Hi, > > update system, udev to 104, baselayout to 1.12.9. > > modules are loaded without options again. > > I have to reload them after boot. That is not pretty. > This should be fixed with udev-104-r1... *** Bug 138162 has been marked as a duplicate of this bug. *** Try w/ 104-r3 and report back please. Hi! I'm using udev-104-r12 and baselayout-1.12.9 and module options still get ignored. In my case it happens with 3c59x. This module gets loaded by udev right after init is started but the option enable_wol=1 is ignored although it is listed in modprobe.conf. Please ignore my previous comment. It works for me now (so options do _not_ get ignored by udev). |
