When I install RHEL4.4 (x86_64) on a Bensley SDV w/ Clovertown G0 chip upgrade, and have DBS (Speedstep) enabled in the BIOS, it crashes on boot. Call trace is: __down_read+52 notifier_call_chain+31 cpufreq_notify_transition+147 centrino_target+263 __cpufreq_driver_target+32 cpufreq_governor_userspace+487 __cpufreq_governor+76 __cpufreq_set_policy+347 cpufreq_set_policy+89 cpufreq_adddev+571 handle_update+0 sysdev_driver_register+134 cpufreq_register_driver+136 init+474 child_rip+8 init+0 child_rip+0 Crashed at: time_cpufreq_notifier+132 Kernel panic - Not syncing : Oops It doesn't happen w/ 4.5. I tried updating the BIOS from a 5/27/07 version to the latest 7/31/07 version that I could get, and it still happened. The box can boot if I disable DBS in the BIOS. 4.5 comes up fine. I could try 4.6, I could try 4.3, I could try i386, etc, if desired. Since it appears to have been fixed later, this isn't really a concern to Intel, but I wanted to give you a heads up. You might want to at least create a kbase entry that points out the workaround of disabling DBS or upgrading. Maybe that's obvious to an experienced support person based on that stack trace. Potentially, the fix could be isolated from 4.5 and an errata done if 4.4 support is important. Of course, I can't really know whether OEM platforms would be affected or not, without tracking down the bug.
Geoff, Bear in mind that G0 commences with the 4.5 errata kernel. Test that rev. and 4.6.
as for kbase entries, we have the following two Knowledge Base (kBase) articles that describe this minimum Red Hat Enterprise Linux support: - http://kbase.redhat.com/faq/FAQ_85_11695 - http://kbase.redhat.com/faq/FAQ_85_11696 so that people should upgrade to 4.5+ Please feel free to close the bug if you think the above kbase entry is sufficient.
There's a BIOS update I should be able to try tomorrow, perhaps that will fix this problem anyway. Also I have recently installed RHEL4.6, RHEL5.1, F-8, both x86_64 and i386 and didn't see this problem on any of those. Given the kbase minimum, yeah this isn't such a big deal now. I'd still prefer to understand what was going on if possible; I guess I could probably do a binary search of kernels if I'm that interested.