Description of problem: We need a udev rule to handle hotplugging of devices (which includes CPUs) and restarting rtctl scripts.
This udev rule seems to work on my laptop to cause 'rtctl' to be run when a device with an IRQ attribute is detected: # rule to run rtctl when IRQ threads are started ATTRS{irq}=="*",RUN+="/sbin/service rtctl restart" I put this in /etc/udev/rules.d/99-threaded-irqs.rules and it was run following a resume and properly set the irq values.
*** Bug 458276 has been marked as a duplicate of this bug. ***
Clark, what do you think about this?
I think it should go in.
Let's revive this bug as part of the ongoing documentation effort...we taking which rule then?
well, should we do this, or should we update rtctl and have the udev rule send a dbus message to an rtctl runin in --daemon mode?
addressed in rt-setup-1.3
Removed in rt-setup-1.4 due to problems with older udev not liking the ATTR{irq} attribute.
Moving this one to Clark, since he owns the script :)
added in v1.8
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: * Cause: kthreads default to SCHED_FIFO:50 priority * Consequence: when drivers that register IRQ handlers are reloaded, IRQ priority changes by rtctl are lost * Fix: cause rtctl to be re-run via a udev rule when IRQ threads are noticed by udev * Result: rtctl priority settings are maintained
Cool
Verified by code review against rt-setup-1.7-2. Found mechanisms triggering '/usr/sbin/rtctl reset' to be called on udev SYSFS{irq} events. 'rtctl reset' will make sure that all configured processes and threads do have the right priorities and CPU affinities. Verified by tweaking rtctl and reloading USB modules. The following patch was applied: --- /usr/sbin/rtctl.orig 2010-10-07 05:14:31.000000000 -0400 +++ /usr/sbin/rtctl 2010-10-07 05:16:43.000000000 -0400 @@ -8,6 +8,8 @@ exit 1 } +logger -t rtctl-review "rtctl called: $*" + RTGROUPFILE=/etc/rtgroups case "$1" in --file) The the following commands where issued: # modprobe -r uhci_hcd ohci_hcd ehci_hcd # modprobe ehci_hcd # modprobe uhci_hcd # modprobe ohci_hcd /var/log/messages was then inspected with grep: [root@hp-dl360g6-01 ~]# grep rtctl-review /var/log/messages Oct 7 05:22:36 hp-dl360g6-01 rtctl-review: rtctl called: reset Oct 7 05:22:51 hp-dl360g6-01 rtctl-review: rtctl called: reset Oct 7 05:22:52 hp-dl360g6-01 rtctl-review: rtctl called: reset Oct 7 05:22:57 hp-dl360g6-01 rtctl-review: rtctl called: reset Oct 7 05:22:57 hp-dl360g6-01 rtctl-review: rtctl called: reset Oct 7 05:22:58 hp-dl360g6-01 rtctl-review: rtctl called: reset Oct 7 05:22:59 hp-dl360g6-01 rtctl-review: rtctl called: reset Oct 7 05:22:59 hp-dl360g6-01 rtctl-review: rtctl called: reset Oct 7 05:23:00 hp-dl360g6-01 rtctl-review: rtctl called: reset
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,4 +1 @@ -* Cause: kthreads default to SCHED_FIFO:50 priority +When drivers that register IRQ handlers were reloaded, IRQ priority changes made by the rtctl scripts were lost. To prevent this, an appropriate udev rule has been added to run rtctl whenever the IRQ threads are started, and the priority settings are now maintained as expected.-* Consequence: when drivers that register IRQ handlers are reloaded, IRQ priority changes by rtctl are lost -* Fix: cause rtctl to be re-run via a udev rule when IRQ threads are noticed by udev -* Result: rtctl priority settings are maintained
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0762.html