Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Executing udev rules on boot:RUN executed before module load
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
cz0
Apprentice
Apprentice


Joined: 13 Jun 2005
Posts: 252
Location: /earth/russia/moscow

PostPosted: Fri Nov 04, 2016 8:47 am    Post subject: Executing udev rules on boot:RUN executed before module load Reply with quote

Hi folks!
I have National Instruments USB<->GPIB bridge. It is an USB board that need special procedure to became usable. I have linux_gpib package installed that provide two kernel modules: gpib_common and ni_usb_gpib. Besides, the gpib_config tool mast be executed before I can talk to any instrument on the GPIB bus. The trick is that board needs about 2 seconds after it was plugged into USB for internal initialization before gpib_config command will take effect. So, I have the following 99-gpib.rules udev rule that does the job perfect:
Code:
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="3923", ATTR{idProduct}=="709b", RUN+="/bin/sh -c '/usr/bin/sleep 2; /usr/sbin/gpib_config --minor 0'"
KERNEL=="gpib[0-9]*", MODE="0660", GROUP="gpib"

The problem is it only work if I plug the board when host system is up and running. When I reboot with the dongle plugged in I can see both kernel modules loaded, but the board is unusable, meaning that gpib_config tool wasn't executed. If I run it by hand it work perfectly.

Since reboot scenario is more real, then plugging it while the system is running, I need the correct way to make udev do this on boot. Sure, I can write some init script that will check if the board is plugged and kernel modules are loaded and run the tool during loading process, but this is udev job cause it something to deal with hardware, I think. Any ideas?

UPD: udev executes RUN before module loading.


Last edited by cz0 on Fri Nov 04, 2016 7:35 pm; edited 2 times in total
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3290
Location: Illinois, USA

PostPosted: Fri Nov 04, 2016 1:04 pm    Post subject: Reply with quote

Maybe do a modprobe of the driver in /etc/local.d ? I had a problem with a TV card and blacklisted the module, then modptobed it at the end of boot in /etc/local.d. If you are using systemd, forget I responded.
Back to top
View user's profile Send private message
cz0
Apprentice
Apprentice


Joined: 13 Jun 2005
Posts: 252
Location: /earth/russia/moscow

PostPosted: Fri Nov 04, 2016 6:03 pm    Post subject: Reply with quote

I use OpenRC.
I tried to investigate this a little bit feather and found an interesting thing. First of all, in my system udev is at sysinit runlevel (which seem to be the right thing) and modules is at boot runlevel. As expected, udev starts before modules load, giving it zero chances to execute my rule properly.
I made an experiment: booted in interactive mode and before udev was started, I exited to console and stated modules (actually modules-load, but this is another question) manually and then exited console and started udev - my card initialized properly and was operational immediately after boot process finished.

So, the obvious question: is the boot is the correct runlevel for modules? Should I move it to sysinit?

Another question: my system is a couple years old and I have to scripts: modules and modules-load. The last one is the newest one and it loads more modules (well, at least virtualbox). Which should I use?
Back to top
View user's profile Send private message
cz0
Apprentice
Apprentice


Joined: 13 Jun 2005
Posts: 252
Location: /earth/russia/moscow

PostPosted: Fri Nov 04, 2016 7:06 pm    Post subject: Reply with quote

Well, it seems to be nothing about /etc/init.d/modules. udev seem to load appropriate kernel module by itself without any extra actions. But the problem is that udev executes RUN before modules get loaded.

UPD: confirmed. I kicked out both modules by rmmod and replaced the gpib_config command in the RUN parameter with lsmod to see module list at the moment command inside RUN is executed and nop, non of the gpib stuff is there. FAIL.
Back to top
View user's profile Send private message
cz0
Apprentice
Apprentice


Joined: 13 Jun 2005
Posts: 252
Location: /earth/russia/moscow

PostPosted: Fri Nov 04, 2016 10:38 pm    Post subject: Reply with quote

Heh, moved modules-load from boot to sysinit and udev now initialize my board correctly. Have no idea if this is a solution or just a crutch.
In my personal opinion udev should do this by itself: load correct modules and execute configuration utility. Dunno..
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3290
Location: Illinois, USA

PostPosted: Fri Nov 04, 2016 10:55 pm    Post subject: Reply with quote

In the example I cited, the module was having trouble finding the firmware at boot time. But you don't have to blacklist it. Blacklisting just makes the boot faster.
/etc/modules.d files are executed last, so booting and sysinit are really done except for your locally defined stuff. Files with suffix .start are executed in alphabetical order. Same for files with .stop at shutdown. Here's my cx18.start (executes after 000.start and baselayout1.start ).
Code:
modprobe ivtv &
modprobe cx18 &
When the module loads, udev, eudev, or mdev will detect it and take their actions. If you don't want to blacklist the module then just put an rmmod at the start of the script just like you did manually.

I gave you the wrong name for blacklisting. I'm sorry. It's /etc/modprobe.d/blacklist.conf.
Code:
# NIC Kludge Stop r8169 loading so that r8168 will
blacklist r8169

#try to speed up udev
blacklist cx18
blacklist ivtv
#blacklist cx18-alsa
#blacklist ivtv-alsa
cx18-alsa and ivtv-lsa are loaded by ivtv and cx18 so they don't need to be blacklisted if the parent is blacklisted.

The blacklist file prevents udev from loading the module.
Back to top
View user's profile Send private message
cz0
Apprentice
Apprentice


Joined: 13 Jun 2005
Posts: 252
Location: /earth/russia/moscow

PostPosted: Fri Nov 04, 2016 11:11 pm    Post subject: Reply with quote

Well, I don't have to load firmware to my board, it's modern one that has everything on board "from the box".
If rewind what I wrote above, the problem is in udev, that executes RUN stuff before actual module loading and interface creation therefore, gpib_config fails. I did another check: put 5 sec sleep before lsmod | grep gpib >> /root/log to RUN to see if udev even try to load modules before executing RUN thing - not a sausage!
So I see two possible solution:
1) move modules-load to sysinit runlevel and make it load modules before udev start, therefore udev executes gpib_config on top of preloaded modules and succeeds - this solution is now working$
2) somehow force udev to load modules first and after modules are loaded execute the RUN stuff - probably, this is the correct desired solution (just cause udev should deal with the modules on itself, I think), but I have no clue how to do this.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3290
Location: Illinois, USA

PostPosted: Fri Nov 04, 2016 11:36 pm    Post subject: Reply with quote

Well, I think my way is simpler, unless you need the device to boot, but it's certainly your choice. Since you are on OpenRC, have you tried using eudev instead of udev?
I see lots of complaints on this board that udev only plays well with systemd.
Back to top
View user's profile Send private message
cz0
Apprentice
Apprentice


Joined: 13 Jun 2005
Posts: 252
Location: /earth/russia/moscow

PostPosted: Sat Nov 05, 2016 8:31 am    Post subject: Reply with quote

I don't understand your solution, actually. Why should I blacklist it and how then I will get the board working?

Can you point me out to the threads about this board, googling gives nothing particular.

P.S. The board is pesky.. I spent hours and hours understanding why the heck gpib_config is failing when executed on board connect before I guessed to introduce a delay. And I never seen a recipe with a delay, so it is probably version related to. But once modules are loaded and board is configured it seem to work rock stable.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum