| View previous topic :: View next topic |
| Author |
Message |
dsd
Developer
Joined: 30 Mar 2003
Posts: 2162
Location: nr London
|
|
| Back to top |
|
 |
troymc
Guru
Joined: 22 Mar 2006
Posts: 552
|
 Posted: Sun May 21, 2006 3:21 am Post subject: |
 |
|
Nice! I think that will help a lot of people with multiple interfaces! 
troymc |
|
| Back to top |
|
|
I.C.Wiener
Tux's lil' helper
Joined: 25 Jul 2004
Posts: 115
Location: Furtwangen (Germany)
|
| Posted: Fri Jun 09, 2006 12:43 pm Post subject: |
|
|
Please, provide at least some option in udev.conf or somewhere else to turn this autoloading-shit off.
Since I upgraded udev my network cards get swapped every time I boot. eth0 becames eth1 and twice versa - EVERY TIME!!! No way to adopt!
My soundcards are getting loaded in the wrong order, even though I set things up in /etc/modules.d/alsa like:
| Code: |
alias snd-card-0 snd-emu10k1
alias snd-card-1 snd-intel8x0
|
Alsa worked fine and handled the module-loading properly, since udev interfered everthing goes wrong!
I am the User, damnit! I want to decide what modules are being loaded during boot and which are not. |
|
| Back to top |
|
|
letzterfreiercoolername
n00b
Joined: 24 Jul 2005
Posts: 9
Location: Munich
|
| Posted: Thu Jul 13, 2006 10:09 pm Post subject: |
|
|
| I.C.Wiener wrote: | Please, provide at least some option in udev.conf or somewhere else to turn this autoloading-shit off.
Since I upgraded udev my network cards get swapped every time I boot. eth0 becames eth1 and twice versa - EVERY TIME!!! No way to adopt!
My soundcards are getting loaded in the wrong order, even though I set things up in /etc/modules.d/alsa like:
| Code: |
alias snd-card-0 snd-emu10k1
alias snd-card-1 snd-intel8x0
|
Alsa worked fine and handled the module-loading properly, since udev interfered everthing goes wrong!
I am the User, damnit! I want to decide what modules are being loaded during boot and which are not. |
Well, I won't swear here, but I'd like to, too!
My networkadapters (NIC, wireless, and that eth1394 thingie) change at every boot, too.
Especially evil is that I have to use vmware (I use gentoo in my daytime job) with a "bridged to primary NIC" network setup.
Guess how hard it is to guess the correct NIC id at next boot, so that I can configure the vmware config files correctly...
So I want to double my preposters demand (in a friendlier way):
* either give us a way to exclude certain hardware from being autoloaded in random order
* or give us a way to provide the loading order in a config file etc. I'd even use kernel command line options, but they only work for compiled-in drivers.
Pleeeeeeaseeeeee!
_________________
I am what I am |
|
| Back to top |
|
|
letzterfreiercoolername
n00b
Joined: 24 Jul 2005
Posts: 9
Location: Munich
|
| Posted: Thu Jul 13, 2006 11:47 pm Post subject: |
|
|
Ok, I am done now, and it works!
I read http://www.reactivated.net/writing_udev_rules.html , especially section http://www.reactivated.net/writing_udev_rules.html#example-netif ,
then investigated my NICs' hardware/MAC addresses,
then put
| Code: |
# this is my ethernet NIC, recognized by MAC address
KERNEL=="eth*", SYSFS{address}=="00:11:d8:59:d1:f9", NAME="eth0"
# this is TCP over firewire (eth1394)
KERNEL=="eth*", SYSFS{address}=="00:11:d8:00:00:03:5b:e1", NAME="eth1"
# this is my PCI wireless card
KERNEL=="ra*", SYSFS{address}=="00:11:d8:58:8e:db", NAME="ra0"
|
into /etc/udev/rules.d/10-local.rules
Then I removed any ethX related "alias ethX drivername" mapping from /etc/modules.d/aliases and ran modules-update.
I tried for 5 completely coldstarts now, no flipping ethX names anymore!
Yeehaa!
CAUTION: _Your_ device IDs will be different, these above are altered examples!
What basically happens here, is that if a device named eth? is loaded and it fits a MAC address, I assign a fixed name to it.
@I.C.Wiener: you could do the same to your NICs and sth similar to your sound cards: I'd try to either use the pci bus address or the driver name (you have different cards, don't you?) instead of a MAC address.
Time needed for this 2h 35min. I should have done earlier. If only Daniel Drake (dsd) had not put the solution to my problems in one of the last paragraphs of his wonderful documentation ... 
_________________
I am what I am |
|
| Back to top |
|
|
Polynomial-C
Developer
Joined: 01 Jun 2003
Posts: 1341
Location: germany
|
| Posted: Tue Jul 18, 2006 1:39 pm Post subject: |
|
|
Hi,
alright I was also hit by this fscking bug (yes, I call this a big, fat bug in udev).
It seems as all this trouble is caused by udevtrigger. If you let udev get started with udevstart, no unnecessary module is loaded at boottime.
Of course you have to alter the startscript of udev which is located in /lib/rcscripts/addons/udev-start.sh
| Code: | --- /usr/portage/sys-fs/udev/files/udev-start-096.sh 2006-07-15 19:16:52.000000000 +0200
+++ /usr/local/portage/sys-fs/udev/files/udev-start-096.sh 2006-07-18 15:26:49.000000000 +0200
@@ -17,18 +17,18 @@
populate_udev() {
# populate /dev with devices already found by the kernel
- if [ $(get_KV) -gt "$(KV_to_int '2.6.14')" ] ; then
- ebegin "Populating /dev with existing devices through uevents"
- local opts=
- [[ ${RC_COLDPLUG} != "yes" && $(udev_version) -ge "96" ]] && \
- opts="--no-scan-bus"
- /sbin/udevtrigger ${opts}
- eend $?
- else
+# if [ $(get_KV) -gt "$(KV_to_int '2.6.14')" ] ; then
+# ebegin "Populating /dev with existing devices through uevents"
+# local opts=
+# [[ ${RC_COLDPLUG} != "yes" && $(udev_version) -ge "96" ]] && \
+# opts="--no-scan-bus"
+# /sbin/udevtrigger ${opts}
+# eend $?
+# else
ebegin "Populating /dev with existing devices with udevstart"
/sbin/udevstart
eend $?
- fi
+# fi
# loop until everything is finished
# there's gotta be a better way... |
I can only hope that the udev-devs will work on a way to stop this nasty behaviour in a smarter way than I did (above all, udevstart is seen as deprecated and will unfortunately be removed in a future version of udev).
Cheers
Poly-C
_________________
The manual said "WindowsXP or better" so I installed GNU/Linux...
my portage overlay
Need a stage1 tarball? (Unofficial builds) |
|
| Back to top |
|
|
Philantrop
Retired Dev
Joined: 21 Dec 2004
Posts: 1129
Location: Germany
|
| Posted: Sat Jul 22, 2006 4:21 pm Post subject: |
|
|
| Polynomial-C wrote: | | alright I was also hit by this fscking bug (yes, I call this a big, fat bug in udev). |
Looks more like a bug in Gentoo, IMHO. However udev is started, it shouldn't autoload any modules. That's not its job. |
|
| Back to top |
|
|
__jata__
n00b
Joined: 08 Jan 2006
Posts: 10
|
| Posted: Sat Jul 22, 2006 6:20 pm Post subject: |
|
|
| Polynomial-C wrote: | Hi,
alright I was also hit by this fscking bug (yes, I call this a big, fat bug in udev).
|
And it seems, I am in as well. I have Apacer 12in1 card reader and PVR-350 card in my box. Now very funny situation is happening:
udev initialize usb subsystem and the appropriate modules are loaded and, more-less in the same time ivtv driver is loaded as well. It seems, the initializing routines are in collision, so if ivtv is activated first, everything works. If my card reader is found earlier, the initialisation of ivtv is messed up and my system freezes totally with message 'ivtv0 warning: Decoder firmware dead!". At that moment there is only one help: hard reset of computer. At the moment I have to start computer approximately 10 times to reach useable system! Once booted, all works well without any problems. In the past I was able to choose the modules loading order and, based on experience, I never had such screwed PC if ivtv was initialized first.
Very nice, I like it  |
|
| Back to top |
|
|
Polynomial-C
Developer
Joined: 01 Jun 2003
Posts: 1341
Location: germany
|
| Posted: Sun Jul 23, 2006 2:23 am Post subject: |
|
|
Okay,
in this comment was said that this (mis)behaviour could be switched off by setting in /etc/conf.d/rc. On my two ~x86 machines with udev-096-r1 this works but there are reports that this doesn't work as well (maybe because >=udev-096 is needed for that as udevtrigger has to be called with --no-scan-bus option which was introduced in gentoo's udev-096 first). Also the module-blacklisting mentioned in that comment doesn't work either.
So before you alter the udev-startscript you maybe update to >=udev-096-r1 (don't use =udev-096 as it has errors concerning the paths of some helper-apps) and try that RC_COLDPLUG="no" first.
[edit]>=udev-099 is using a new syntax for udevtrigger which replaces --no-scan-bus option: udevtrigger --attr-match=dev[/edit]
Cheers
Poly-C
_________________
The manual said "WindowsXP or better" so I installed GNU/Linux...
my portage overlay
Need a stage1 tarball? (Unofficial builds)
Last edited by Polynomial-C on Fri Sep 08, 2006 11:39 pm; edited 1 time in total |
|
| Back to top |
|
|
__jata__
n00b
Joined: 08 Jan 2006
Posts: 10
|
| Posted: Sun Jul 23, 2006 7:57 am Post subject: |
|
|
| Polynomial-C wrote: | Okay,
in this comment was said that this (mis)behaviour could be switched off by setting in /etc/conf.d/rc. On my two ~x86 machines with udev-096-r1 this works but there are reports that this doesn't work as well (maybe because >=udev-096 is needed for that as udevtrigger has to be called with --no-scan-bus option which was introduced in gentoo's udev-096 first). Also the module-blacklisting mentioned in that comment doesn't work either.
So before you alter the udev-startscript you maybe update to >=udev-096-r1 (don't use =udev-096 as it has errors concerning the paths of some helper-apps) and try that RC_COLDPLUG="no" first.
|
Okay, and I am the one, RC_COLDPLUG does not work for... I tried before I sent the post. Analogically, blacklisting of ivtv module does not work as well. My udev IS 0.96-r1.
So far, there is only one reliable way: the comment-out the appropriate lines in udev-start.sh, as you wrote above. |
|
| Back to top |
|
|
Philantrop
Retired Dev
Joined: 21 Dec 2004
Posts: 1129
Location: Germany
|
| Posted: Sun Jul 23, 2006 8:05 am Post subject: |
|
|
| No, __jata__, you're not alone. I've tried both RC_HOTPLUG and RC_COLDPLUG before I even knew about this thread and that bug. I will try it again soon as the might have been a baselayout update since I last tried but abusing udev like it is currently done is annoying. |
|
| Back to top |
|
|
Philantrop
Retired Dev
Joined: 21 Dec 2004
Posts: 1129
Location: Germany
|
| Posted: Sun Jul 23, 2006 11:46 am Post subject: |
|
|
| Polynomial-C wrote: | | this (mis)behaviour could be switched off by setting in /etc/conf.d/rc. [..] Also the module-blacklisting mentioned in that comment doesn't work either. |
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. Shouldn't be that hard, should it?
_________________
If you feel the issues discussed in this thread have been resolved, please add a "[Solved]" to the subject of your original posting. |
|
| Back to top |
|
|
__jata__
n00b
Joined: 08 Jan 2006
Posts: 10
|
| Posted: Wed Jul 26, 2006 8:54 pm Post subject: |
|
|
| Philantrop wrote: | | Blacklisting doesn't work for me either. |
And THIS seems to me to be crucial point: if blacklisting was working, we would have always a chance to blacklist modules with some specialty (special parameters, special order of loading e.t.c). And the rest of modules could be even loaded automatically (or automagically?), because there is low risk of confusion. And, of course, the mechanism of loading should respect 'static' assignments, i.e. if eth0 is certain NIC with certain module, connected somewhere and eth1 is another NIC, they should be initialized in this order to fullfil expected functionality. The same is about sound cards e.t.c. It is really bad, when every restart of the system means, you have to seek carefully, if the physically the same hardware is (logically) stll the same for OS (and regularly modify your settings accordingly to the result of udev actions). |
|
| Back to top |
|
|
Gergan Penkov
Veteran
Joined: 17 Jul 2004
Posts: 1464
Location: das kleinste Kuhdorf Deutschlands :)
|
| Posted: Wed Jul 26, 2006 9:37 pm Post subject: |
|
|
how are you guys blacklisting? as it should work no matter what for kernel or udev, or baselayout you are having.
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack |
|
| Back to top |
|
|
Philantrop
Retired Dev
Joined: 21 Dec 2004
Posts: 1129
Location: Germany
|
| Posted: Wed Jul 26, 2006 9:52 pm Post subject: |
|
|
/etc/hotplug/blacklist
| Quote: | # Syntax: driver name alone (without any spaces) on a line. Other
# lines are ignored.
|
Exactly like that. |
|
| Back to top |
|
|
Gergan Penkov
Veteran
Joined: 17 Jul 2004
Posts: 1464
Location: das kleinste Kuhdorf Deutschlands :)
|
| Posted: Wed Jul 26, 2006 9:59 pm Post subject: |
|
|
| Gergan Penkov wrote: | This has nothing to do with udev, at least in my case (or it is even more complicated), somehow earlier kernels, do not load the modules in this way.
Writing some udev rule did not help in my case, as the modules are loaded before udev kicks in, so it does not create the devices with these rules but the modules are loaded, or at least this was after a short debugging, what really helped now, is this file:
| Code: | cat /etc/modules.d/blacklist
blacklist ath_hal
blacklist ath_pci
blacklist ath_rate_amrr
blacklist wlan
blacklist wlan_scan_sta
|
and probably this udev rule (I haven't tested it without them for now and it is probably superfluous)
| Code: | cat /etc/udev/rules.d/01-atheros.rules
SUBSYSTEM=="module", DRIVER=="ath*", OPTIONS="ignore_device,last_rule"
SUBSYSTEM=="module", DRIVER=="wlan*", OPTIONS="ignore_device,last_rule" |
but now at least all works as I want it. |
and this works for me
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack |
|
| Back to top |
|
|
Philantrop
Retired Dev
Joined: 21 Dec 2004
Posts: 1129
Location: Germany
|
| Posted: Wed Jul 26, 2006 10:24 pm Post subject: |
|
|
| Quote: | cat /etc/modules.d/blacklist
blacklist bttv
blacklist video_buf
blacklist firmware_class
blacklist compat_ioctl32
blacklist v4l2_common
blacklist btcx_risc
blacklist ir_common
blacklist tveeprom
blacklist videodev
|
| Quote: | | SUBSYSTEM=="module", DRIVER=="bttv", OPTIONS="ignore_device,last_rule" |
| Quote: | * Updating /etc/modules.conf ... [ ok ]
* Updating /etc/modprobe.conf ...
* Warning: could not generate /etc/modprobe.conf! [ !! ]
* Updating /etc/modprobe.conf by hand ... [ ok ]
* Updating modules.dep ... |
| Code: | rmmod tuner tvaudio bttv video_buf firmware_class compat_ioctl32 v4l2_common btcx_risc ir_common tveeprom videodev
killall udevd
ls -l /dev/v4l* |
| Quote: | ls: /dev/v4l*: No such file or directory
|
| Code: | udevd &
udevtrigger
lsmod | grep -i "bttv"
|
| Quote: | bttv 172148 0
video_buf 22148 1 bttv
firmware_class 10560 1 bttv
compat_ioctl32 1280 1 bttv
v4l2_common 7744 2 tuner,bttv
btcx_risc 4872 1 bttv
ir_common 9668 1 bttv
tveeprom 14672 1 bttv
videodev 9600 1 bttv
|
_________________
If you feel the issues discussed in this thread have been resolved, please add a "[Solved]" to the subject of your original posting. |
|
| Back to top |
|
|
Gergan Penkov
Veteran
Joined: 17 Jul 2004
Posts: 1464
Location: das kleinste Kuhdorf Deutschlands :)
|
| Posted: Wed Jul 26, 2006 10:46 pm Post subject: |
|
|
hm well it seems it is not an universal solution, although it works very well for me.
look if /etc/modules.conf & /etc/modprobe.conf get regenerated at all or if it has the blacklist entries.
[EDIT]Probably it works for me because the ndiswrapper "takes" the device a little bit later on, I should try also to blacklist the ndiswrapper moduke and see if anything gets loaded - probably this is the problem[/EDIT]
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack |
|
| Back to top |
|
|
Philantrop
Retired Dev
Joined: 21 Dec 2004
Posts: 1129
Location: Germany
|
| Posted: Wed Jul 26, 2006 10:55 pm Post subject: |
|
|
Yes, mod*.conf get updated but it doesn't work anyway.
I'm curious to hear about your ndiswrapper test. :-) |
|
| Back to top |
|
|
Gergan Penkov
Veteran
Joined: 17 Jul 2004
Posts: 1464
Location: das kleinste Kuhdorf Deutschlands :)
|
| Posted: Wed Jul 26, 2006 11:30 pm Post subject: |
|
|
well it does not work, I assume that I'm just lucky to have found some sort of solution 
It loads ndiswrapper even after blacklisting it, but I'm not sure when, I haven't had the time to debug it and didn't want to stop all the services, which depend on net.wlan0 so it could be that net.wlan0 is forcing the module loading.
At least the madwifi-drivers don't get loaded for me as was the case before the blacklisting - but I still don't see what have made them change the behaviour in this rather controversial way.
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack |
|
| Back to top |
|
|
t0mcat
Tux's lil' helper
Joined: 12 Feb 2004
Posts: 111
Location: Catania, Italy
|
| Posted: Fri Nov 17, 2006 6:08 pm Post subject: |
|
|
are there any updates on this?
actually the only way to prefer ndiswrapper module to the kernel one (bcm43xx, wich i need to use kismet, but it's quite slower than ndiswrapper driver) was to downgrade udev to the stable ebuild...
i just wanted a blacklist function... turning totaly off module-autoloading isn't viable imho.
_________________
il gattaccio
a.k.a etienne |
|
| Back to top |
|
|
Gergan Penkov
Veteran
Joined: 17 Jul 2004
Posts: 1464
Location: das kleinste Kuhdorf Deutschlands :)
|
| Posted: Fri Nov 17, 2006 9:11 pm Post subject: |
|
|
Well, I gave up on this one, after some upgrade nothing was able to prevent the loading of the madwifi-drivers and I had to unload them (there are 6-7 modules) and load ndiswrapper per hand. So I ended searching for solution and found snapshot drivers not in portage for madwifi, which at the end worked for me. So now I'm using madwifi-ng with a custom build
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack |
|
| Back to top |
|
|
theomega
Tux's lil' helper
Joined: 26 Jan 2006
Posts: 88
Location: Germany
|
| Posted: Thu Nov 23, 2006 2:59 pm Post subject: |
|
|
Is there realy no solution for this problem? I realy dont want my wireless-lan-modules to be loaded all the time. So please(!) tell me how to fix this?
_________________
A64 3700+ SanDiego@Ninja Passive, Asus A8V Deluxe, 2x1024MB MDT-Ram, Saphire Radeon 9800 pro@VF700CU, Samsung 200GB IDE, LianLi PC7SE (2x120mm fans) |
|
| Back to top |
|
|
Philantrop
Retired Dev
Joined: 21 Dec 2004
Posts: 1129
Location: Germany
|
| Posted: Thu Nov 23, 2006 3:20 pm Post subject: |
|
|
See this bug:
http://bugs.gentoo.org/show_bug.cgi?id=130766
It doesn't seem to be a problem considering for how long it's been open... Sensible module auto-loading with Gentoo? Hardly possible.
_________________
If you feel the issues discussed in this thread have been resolved, please add a "[Solved]" to the subject of your original posting. |
|
| Back to top |
|
|
Element Dave
n00b
Joined: 10 Nov 2006
Posts: 74
|
| Posted: Mon Jan 22, 2007 7:06 am Post subject: |
|
|
| dsd wrote: | | troymc wrote: | | The udev team seems to be conflating dynamic device node creation and module loading in a way that is short-circuiting this behaviour. |
seems a little odd to bring this up now, given that its been happening for years, and its not related to coldplugging. but yes, this is how udev does things.
| Quote: | | I've had floppy.o built as a module for almost 10 years now, and the only time it is ever loaded is when I've mounted a floppy. Now, if I have the module built, it has to be loaded at boot? or I have to go back to loading it manually, and creating the device node manually? |
my advice to you, and every other manual compile kernel user we have, is avoid modules where possible. build floppy support directly into your kernel image, and accept the fact that it uses near zero memory until you actually mount a floppy. this wasnt the case with 2.4, but 2.6 contains a new driver model which means there is almost zero expense for loading modules that you arent using.
if you insist on living any other way without good reason, then you'll have to make some sacrifices, tinker with things, or whatever else. |
This attitude is completely idiotic. Why on earth would anyone assume that one would want to use a device simply because it is attached to the system? Only a subset of devices present are ever used on most systems. There are many reasons for not wanting certain device drivers and/or other modules loaded all of the time: preventing resource conflicts is certainly one. How does one even know which modules are going to be automagically loaded, and when?
It's quite a mess when users are creating module blacklists in multiple directories (which probably aren't even parsed) and swapping trade secrets in forums ('psst: set RC_COLDPLUG="no"') in an attempt to override the default module loading behavior. If only people would prepare documentation before even coding the software. |
|
| Back to top |
|
|
|
Kernel & Hardware
