Bug 1008052 - kernel not generating udev events for CPUs during boot any more
kernel not generating udev events for CPUs during boot any more
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-13 20:21 EDT by markzzzsmith
Modified: 2013-10-08 12:06 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-08 12:06:04 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description markzzzsmith 2013-09-13 20:21:52 EDT
Description of problem:

Quite a while ago, I created the following udev rule file to change the cpufreq governor from 'ondemand' to 'conservative' for all CPUs, to save battery power on my Dell XPS 13 laptop. I also installed it on my Dell Optiplex 755, to also save a bit of power:

--
[mark@opy rules.d]$ cat 80-cpu-power-settings.mrs.rules 
# Adjust CPU power related settings

# Conservative scaling governer to trade performance for battery life
SUBSYSTEM=="cpu", TEST{}=="cpufreq/scaling_governor", ATTR{cpufreq/scaling_governor}="conservative"



[mark@opy rules.d]$ 
--

Initially it worked a number of months ago, however it is not working now. For example, directly after booting, 'cpupower frequency-info' shows the governor still set to 'ondemand':

--
[mark@opy ~]$ sudo cpupower frequency-info
[sudo] password for mark: 
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 2.40 GHz
  available frequency steps: 2.40 GHz, 2.13 GHz, 1.87 GHz, 1.60 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance
  current policy: frequency should be within 1.60 GHz and 2.40 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
  boost state support:
    Supported: no
    Active: no
[mark@opy ~]$ 
--

If I then run 'udevadmin trigger', udev has now executed this CPU rule file:

--
[mark@opy ~]$ sudo cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 2.40 GHz
  available frequency steps: 2.40 GHz, 2.13 GHz, 1.87 GHz, 1.60 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance
  current policy: frequency should be within 1.60 GHz and 2.40 GHz.
                  The governor "conservative" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
  boost state support:
    Supported: no
    Active: no
[mark@opy ~]$ 
--

Initially I also had the ACTION=="add" parameter on the rule so that it would only be applied at CPU add event time, rather than every time a udev event occurred.

Other rule files I have are being applied at boot, for example, the following one always creates a wifi tap interface at boot:

--
[mark@opy rules.d]$ cat 80-wifi-monitor-interface.mrs.rules 
# Automatically create wifi monitor (tap) interface(s)

# Need per-interface rules, as udev events are also generated for newly created monitor interface, and they
# also have a DEVTYPE of wlan.
ACTION=="add", SUBSYSTEM=="net", ENV{DEVTYPE}=="wlan", ENV{INTERFACE}=="wlan0", RUN+="/usr/sbin/iw dev $env{INTERFACE} interface add $env{INTERFACE}mon type monitor"

[mark@opy rules.d]$ ip link show dev wlp3s0mon
6: wlp3s0mon: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ieee802.11/radiotap b0:48:7a:f5:55:80 brd ff:ff:ff:ff:ff:ff
[mark@opy rules.d]$ 


--

which seems to indicate that it is only CPU related kernel events that are not occurring during boot.


Version-Release number of selected component (if applicable):

kernel 3.10.11-200.fc19.x86_64

How reproducible:

Upon every boot, on both a Dell Optiplex 755 desktop and Dell XPS 13 laptop.


Steps to Reproduce:
1. Have above udev rule file.
2. Boot system
3. Observe current CPU frequency governor

Actual results:

CPU frequency governor left on 'ondemand' for all CPUs

Expected results:

CPU frequency governor changed to 'conservative' for all CPUs

Additional info:
Comment 1 Josh Boyer 2013-09-18 16:48:59 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 2 Josh Boyer 2013-10-08 12:06:04 EDT
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

Note You need to log in before you can comment on or make changes to this bug.