Bug 696348 - [FEAT] Load coretemp kernel module by default
Summary: [FEAT] Load coretemp kernel module by default
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: udev
Version: 6.3
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: udev-maint
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 767187
TreeView+ depends on / blocked
 
Reported: 2011-04-13 21:16 UTC by Scott McMillan
Modified: 2012-06-29 17:42 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-29 17:42:27 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Scott McMillan 2011-04-13 21:16:25 UTC
Description of problem:
Currently, one must manually load the coretemp kernel module.  Please consider loading it by default so core temperature data is more widely available.

Comment 2 Neil Horman 2012-02-20 12:52:52 UTC
I don't think all people want the coretemp module.  Not everyone uses it and as such doesn't need it loaded. I'm also not sure if coretemp supports alternate x86 processors, so adding it by default becomes difficult.  If you want to get it to load all the time however, we could add a package to the EPEL repo that just added a udev rule along the following lines:

KERNEL=="cpu[0-9]*", ACTION=="add", RUN+="/sbin/modprobe coretemp"

perhaps with some additional scripting to validate that its an intel processor being used.

would that be sufficient?

Comment 3 Scott McMillan 2012-02-23 18:11:51 UTC
The key is to have a standard, widely available interface.  Otherwise it's impossible to build tools that want to query the temperature.

A script that detects whether its a supported processor, and if so, adds the udev rule, is sufficient.

Comment 4 Neil Horman 2012-02-23 19:53:35 UTC
ok, well, lets start by re-assigning this to udev, to see if the maintainer wants to just directly add this

Comment 5 Neil Horman 2012-02-23 19:56:54 UTC
udev team- is its acceptable to add a rule to the standard udev files, such as the one in comment 2?  Looking at the module code it appears to dynamically detect cpu support so we can just blindly modprobe it and have it "do the right thing"

Comment 6 Kay Sievers 2012-02-23 23:59:56 UTC
No, rules like that make no real sense.

Every system has a CPU, and it will always trigger. That's no job for udev
rules, or event handlers.

Modules are global, and we might have many CPUs, we must not hook into every
possible CPU and cause work there; the module can only be loaded one single
time.

That job can just go to the static module loading in /usr/lib/modules-load.d/,
which is simple and efficient. Check 'man modules-load.d'.

In case the module depends on a specific CPU feature, that can be discovered,
we could be able to auto-load the module with the upcoming CPU modaliases the
next kernel release will provide. Just mentioning that here, I have no idea how
coretemp works.

Comment 7 Harald Hoyer 2012-02-24 15:03:30 UTC
(In reply to comment #6)
> That job can just go to the static module loading in /usr/lib/modules-load.d/,
> which is simple and efficient. Check 'man modules-load.d'.

That is not available in RHEL-6.

RHEL-6 should use /etc/rc.d/rc.local or /etc/rc.modules or a initscript.

Comment 8 RHEL Program Management 2012-05-03 05:13:52 UTC
Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 9 Harald Hoyer 2012-06-29 17:42:27 UTC
udev cannot ship this. If you want that drop a shell script in /etc/sysconfig/modules/ , which does the modprobe.


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