Bug 401541

Summary:	bensley/clovertown g0 sdv crashes on boot w/ DBS enabled
Product:	Red Hat Enterprise Linux 4	Reporter:	Geoff Gustafson <grgustaf>
Component:	kernel	Assignee:	Red Hat Kernel Manager <kernel-mgr>
Status:	CLOSED NOTABUG	QA Contact:	Martin Jenner <mjenner>
Severity:	high	Docs Contact:
Priority:	medium
Version:	4.4	CC:	jvillalo, jwest, keve.a.gabbert, peterm, rpacheco, tao
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-06-07 04:48:32 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Geoff Gustafson 2007-11-27 17:46:00 UTC

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.

Comment 1 Ronald Pacheco 2007-11-27 22:12:08 UTC

Geoff,

Bear in mind that G0 commences with the 4.5 errata kernel.  Test that rev. and 4.6.

Comment 2 Linda Wang 2008-02-13 04:40:51 UTC

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.

Comment 3 Geoff Gustafson 2008-02-14 22:03:54 UTC

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.