Bug 401541 - bensley/clovertown g0 sdv crashes on boot w/ DBS enabled
bensley/clovertown g0 sdv crashes on boot w/ DBS enabled
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.4
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Red Hat Kernel Manager
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-27 12:46 EST by Geoff Gustafson
Modified: 2010-10-22 16:46 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-07 00:48:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Geoff Gustafson 2007-11-27 12:46:00 EST
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 17:12:08 EST
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-12 23:40:51 EST
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 17:03:54 EST
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.

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