1. Feature Name: update acpi-cpufreq driver 2. Description: In 2.6.23, an update to acpi-cpufreq went in that lets it either use an IO port interface from the BIOS to read P-state information (as before), or directly access registers to get the information. Currently, when the IO port interface isn't present, the driver can't be used and the old speedstep-centrino driver is the only way to get frequency scaling support. Even when speedstep-centrino can be used, though, it is outdated and doesn't work as effectively as the newer implementations. Architectures: * 32-bit x86 * 64-bit Intel EM64T 64-bit Itanium2 Dependencies: External links: Priority (H,M,L): H Target Releases: Target Release Date: Drivers or hardware dependency: Target Kernel: 3. Business Justification: Improve speedstep P-state support. 4. Status: Code upstream in 2.6.23. 5. Hardware to Red Hat? Applies to wide range of existing hardware. 6. Partner management contact: Keve Gabbert, keve.a.gabbert 7. Partner technical contact: John Villalovos jvillalo
Created attachment 308257 [details] Youquan's initial backport Here's a backport patch from Youquan at Intel.
How is going the patch integerated in RHEL5.3?
We are reviewing a patch internally for inclusion in the beta (that is what the "Post" state designates). Once the patch is reviewed and accepted internally, we will add it to the build.
in kernel-2.6.18-113.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
The acpi-cpufreq is not loaded by OS because the kernel-2.6.113.el5 still build in centrino-speedstep. The config-remove-build-in-centrino-speedstep.patch can fix this issue.
Created attachment 317143 [details] config-remove-build-in-centrino-speedstep.patch
Can you confirm this? The link order has been changed, and so acpi-cpufreq will be initialised before speedstep-centrino. Removing it from the configuration should have no affect.
Yes. I confirm it. Just Changing the link order will not change the load order if speedstep-centrino build in kernel while acpi-cpufreq build as module. Removing build in centrino-speedstep(build as module) in configuration has no affect.
Link order should have no effect on modules (i.e. non-builtins). Module load order is up to udev. Load order will be random unless a rule is created. You will need to create a udev rule to always try and load acpi-cpufreq before speedstep-centrino, i.e.: MODULES=(acpi-cpufreq speedstep-centrino) Alternately defining what to load in /etc/modprobe.conf may work too.
Ah, I see the issue. I didn't alter configurations because I wanted to see what the outcome of 459441 was. Building acpi-cpufreq in would potentially make it impossible to load powernow-k8 on some systems, but making speedstep-centrino modular would also fail without the userspace component being fixed up.
What's the userspace component issues? I do not watch any issues when I build both acpi-cpufreq and centrino-speedstep modules and then boot OS.
The cpuspeed init script will never load the centrino-speedstep module. Is the backport of the acpi-cpufreq code guaranteed to work on all hardware supported by centrino-speedstep, including those without ACPI table support?
Configuration change posted, bug #463488 covers the required cpuspeed update.
What's the status for this feature?
Youquan, a patch was posted internally for peer review. Once it is accepted internally, the developer can post a patch for you to work with.
in kernel-2.6.18-119.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
The bug was fixed at RHEL5.3 Beta.
Youquan, I found when i try to modprobe -r acpi_cpufreq on one centrino machine, it will induce kernel panic. DISTRO=RHEL5.3-Server-20081120.1 kernel is 2.6.18-124.el5PAE. this should be a centrino machine. [root@hp-xw4800-01 cpufreq]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Genuine Intel(R) CPU @ 0000 @ 2.13GHz stepping : 2 cpu MHz : 1596.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr popcnt lahf_lm bogomips : 4268.61 there are altogether 4 cores.
step to reproduce: issue "modprobe -r acpi_cpufreq" [root@hp-xw4800-01 ~]# BUG: unable to handle kernel paging request at virtual address 072559ff printing eip: c046d438 *pde = 35ef4001 Oops: 0000 [#1] SMP last sysfs file: /devices/pci0000:3f/0000:3f:00.0/irq Modules linked in: autofs4 hidp rfcomm l2cap bluetooth sunrpc ipv6 xfrm_nalgo crypto_api cpufreq_ondemand acpi_cpufreq dm_multipath scsi_dh video hwmon backlight sbs i2c_ec i2c_core button battery asus_acpi ac parport_pc lp parport floppy snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss sr_mod cdrom snd_pcm serio_raw sg snd_timer snd_page_alloc snd_hwdep snd tg3 soundcore libphy pcspkr dm_snapshot dm_zero dm_mirror dm_log dm_mod ahci libata sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd CPU: 3 EIP: 0060:[<c046d438>] Not tainted VLI EFLAGS: 00010297 (2.6.18-124.el5PAE #1) EIP is at free_percpu+0x12/0x36 eax: 00000000 ebx: 00000000 ecx: 00000202 edx: 00000000 esi: 072559ff edi: 00000000 ebp: f7c6b000 esp: f7c6bf54 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 3429, ti=f7c6b000 task=f7de0550 task.ti=f7c6b000) Stack: f8da9380 00000020 c043d7ff 69706361 7570635f 71657266 c0448000 00000000 09e8e0e0 00000081 40000003 f7de0550 f6211000 4928e8d4 20ad2bd0 f7c6bfbc 00000000 00e8e0e0 f8da9380 00000880 f7c6bfa8 00000000 09e8e0e0 00000000 Call Trace: [<c043d7ff>] sys_delete_module+0x192/0x1bb [<c0448000>] audit_syscall_entry+0x118/0x17d [<c0404f17>] syscall_call+0x7/0xb ======================= Code: 0b 89 c8 89 da e8 01 ff ff ff 8b 03 89 7c 83 14 40 89 03 56 9d 5b 5e 5f c3 56 89 c6 53 b8 40 b5 77 c0 f7 d6 e8 22 79 07 00 eb 14 <8b> 04 9e e8 7a ff ff ff ba 40 b5 77 c0 89 d8 e8 26 79 07 00 83 EIP: [<c046d438>] free_percpu+0x12/0x36 SS:ESP 0068:f7c6bf54 <0>Kernel panic - not syncing: Fatal exception
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver is acpi-cpufreq I know that in rhel4U5, rhel4U6, this machine use speedstep-centrino driver.
At my machines run "modprobe -r acpi-cpufreq", it will report "FATAL: Module acpi_cpufreq is in use". Hi Kexin, Can you provide the following informaiton? dmesg cat /proc/cpuinfo cat sys/devices/system/cpu/cpu*/cpufreq/* Can you reproduce it on x86_64 version?
Hi Youquan, please see https://bugzilla.redhat.com/show_bug.cgi?id=472844 I opened a new bug for it. the info is supplied there. thanks.
Its possible module cpufreq_ondemand may be blocking acpi-cpufreq from being unloaded. I.e. make sure to unload all governor modules before unloading acpi-cpufreq.
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/RHSA-2009-0225.html