Description of problem: While booting specific systems the kernel reports an failure "failed to set up cpufreq notifier" Host it was seen on: hp-dl585g2-01.rhts.boston.redhat.com es7000-01.lab.boston.redhat.com Version-Release number of selected component (if applicable): 2.6.18-76 How reproducible: Always Steps to Reproduce: 1. Install RHEL5-U1 on any of the above hosts. 2. Install the xen kernel and reboot Actual results: <snip> ENABLING IO-APIC IRQs SMP alternatives: switching to SMP code Initializing CPU#1 Initializing CPU#2 Initializing CPU#3 Initializing CPU#4 Initializing CPU#5 Initializing CPU#6 Brought up 8 CPUs sizeof(vma)=88 bytes sizeof(page)=32 bytes sizeof(inode)=340 bytes sizeof(dentry)=136 bytes sizeof(ext3inode)=492 bytes sizeof(buffer_head)=52 bytes sizeof(skbuff)=172 bytes Initializing CPU#7 migration_cost=491 checking if image is initramfs... it is Freeing initrd memory: 6630k freed failed to set up cpufreq notifier Grant table initialized NET: Registered protocol family 16 No dock devices found. ACPI: bus type pci registered PCI: Using configuration type 1 Setting up standard PCI resources Allocating PCI resources starting at 88000000 (gap: 80000000:60000000) ACPI (exconfig-0456): Dynamic SSDT Load - OemId [HP ] OemTableId [PNOWSSDT] [20060707] ACPI: Interpreter enabled </snip> Expected results: Additional info:
This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being proposed as a blocker for this release. Please resolve ASAP.
This is the function that fails: static int __init cpufreq_time_setup(void) { >>>>>>> if (!cpufreq_register_notifier(&time_cpufreq_notifier_block, CPUFREQ_TRANSITION_NOTIFIER)) { printk(KERN_ERR "failed to set up cpufreq notifier\n"); return -ENODEV; } return 0; } cpufreq_register_notifier will return 0 on success, which means this logic seems reversed. I assume removing the '!' will fix the issue.
Does this fail on all systems or just a few? If the logic is reversed it should fail on all systems. I didn't think I saw the issue on Anaheim Barcelona system, but I'll check again.
RHTS shows every xen system on x86 arch fails.
Yes, I see the error with -80 and the logic is incorrect. This function must have been introduced recently as I have some Xen test kernels where this wasn't an issue.
This function came as is with Rik's changes to cpufreq on xen. I put this patch in back in middle of December in -62.el5. So it should have been broken since then.
Fixed Rik's broken patch; patch posted on Feb 12 to RHML and virt-list
Based on comment 8, shouldn't this be a high or urgent priority?
Sure.
Russ, could you please add this to the AMD tracker, so I can keep this in my radar?
in kernel-$NEW_VER You can download this test kernel from http://people.redhat.com/dzickus/el5
in kernel-2.6.18-85.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
We saw this with Beta. All of our systems with snap3 or snap4 installs don't show this anymore.
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 the 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-2008-0314.html