Bug 188453 - CPU locked at lowest frequency when using travel charger
CPU locked at lowest frequency when using travel charger
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jarod Wilson
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-10 03:47 EDT by barry gould
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-16 16:45:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
var-log-messages (45.50 KB, text/plain)
2007-01-11 14:30 EST, barry gould
no flags Details
dmesg (21.69 KB, text/plain)
2007-01-11 14:31 EST, barry gould
no flags Details
dmesg after booting on AC power (18.91 KB, text/plain)
2007-01-12 13:04 EST, barry gould
no flags Details
dmesg after booting on AC power (18.91 KB, text/plain)
2007-01-12 13:05 EST, barry gould
no flags Details
dmesg after booting on batt power, CPU correctly shows 1594MHz (18.73 KB, text/plain)
2007-01-12 13:11 EST, barry gould
no flags Details
another boot on batt power, but with CPU speed (incorrrectly) showing 600MHz (18.59 KB, text/plain)
2007-01-12 13:12 EST, barry gould
no flags Details
dmesg on travel charger with cpufreq.debug=7 (20.46 KB, text/plain)
2007-01-16 00:21 EST, barry gould
no flags Details
dmesg with test kernel on travel charger with cpufreq.debug=7 (20.87 KB, text/plain)
2007-01-23 00:07 EST, barry gould
no flags Details

  None (edit)
Description barry gould 2006-04-10 03:47:21 EDT
Description of problem:
After upgrading from FC4 to FC5, cpuspeed no longer works.
(it always says "Error: No speed steps could be determined!" when run manually)
CPU is always running at 600MHz.

It worked fine in FC4.

This is on a Dell Latitude D800 with a Pentium M 1.6GHz.

I have tried both "centrino" and "speedstep-centrino" in /etc/cpuspeed.conf

Version-Release number of selected component (if applicable):
cpuspeed-1.2.1-1.33
kernel-2.6.16-1.2080_FC5


How reproducible:
always

Steps to Reproduce:
1. run cpuspeed

  
Actual results:
"Error: No speed steps could be determined!" 

Expected results:
cpu should scale between 600MHz and 1.6GHz depending on load.

Additional info:

note below that max_freq is 1600000, but scaling_max_freq is 600000
(from what I can tell, that is not right)

# pwd
/sys/devices/system/cpu/cpu0/cpufreq
# find . -print -exec cat {} \;
./scaling_setspeed
600000
./scaling_cur_freq
600000
./cpuinfo_cur_freq
600000
./scaling_available_frequencies
1600000 1600000 1600000 1400000 1200000 1000000 800000 600000
./scaling_available_governors
userspace performance
./scaling_driver
centrino
./scaling_governor
userspace
./affected_cpus
0
./scaling_max_freq
600000
./scaling_min_freq
600000
./cpuinfo_max_freq
1600000
./cpuinfo_min_freq
600000


# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 9
model name      : Intel(R) Pentium(R) M processor 1600MHz
stepping        : 5
cpu MHz         : 600.000
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 mtrr pge mca cmov pat clflush
dts acpi mmx fxsr sse sse2 tm pbe est tm2
bogomips        : 1198.35


Thanks
Barry Gould
Comment 1 barry gould 2006-04-10 13:42:17 EDT
BTW, the system bios is up to date (A13)
Comment 2 barry gould 2006-04-10 16:09:01 EDT
It's working now, after yum update.
I had already updated the kernel, so I'm not sure what fixed it.

Thanks,
Barry
Comment 3 barry gould 2006-04-14 03:27:37 EDT
Still having problems after software suspend (suspend-to-RAM)...
cpuspeed dies and won't restart.

Thanks,
Barry
Comment 4 barry gould 2006-04-14 04:51:03 EDT
Sorry to keep posting, but after reboot, cpuspeed is still failing to start.
It says Error: No speed steps could be determined!
Comment 5 barry gould 2006-05-01 03:24:53 EDT
still non-deterministic... only works occasionally... very frustrating
Comment 6 barry gould 2006-05-05 02:16:10 EDT
OK, I've figured out what is happening:
when the notebook is on A/C, cpuspeed will not start (or restart), saying "no
speed steps could be determined". If already started, it will not scale.

However, if booted when on battery, it works fine, and scales the CPU properly.

If booted on A/C, cpuspeed will not start or restart even after unplugging the
A/C...
i.e. it only works if initally booted on battery, and only while running on battery.

Thanks
Comment 7 Robert Cooper 2006-05-11 02:11:28 EDT
Thanks so much for running that down Barry. I can confirm the same behavior on
my Dell Inspiron 6000 
Bios Version: A9 (same on A5)
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 1.60GHz
stepping        : 8
cpu MHz         : 800.000
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2
bogomips        : 800.21
Comment 8 barry gould 2006-07-02 00:25:32 EDT
This was mostly or competely fixed for me recently, but now is not working
reliably again when on A/C.

I suspect the latest kernel (kernel-2.6.17-1.2139_FC5) has a regression.

Thanks,
Barry
Comment 9 Amit Kulkarni 2006-07-27 16:02:43 EDT
I can confirm the same problem on Dell Latitude D400. cpuspeed works when laptop
is running on battery only and stops working when AC is connected. No messages
specific to this problem in dmesg output or in /var/log/messages.
I'm using kernel-2.6.17-12157_FC5, cpuspeed 1.2.1-1.33
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 9
model name      : Intel(R) Pentium(R) M processor 1700MHz
stepping        : 5
cpu MHz         : 600.000
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 mtrr pge mca cmov pat clflush
dts acpi mmx fxsr sse sse2 tm pbe est tm2
bogomips        : 1202.12

/etc/cpuspeed.conf:
VMAJOR=1
VMINOR=1

# uncomment this and set to the name of your CPUFreq module
#DRIVER="centrino"

# Let background (nice) processes speed up the cpu
#OPTS="$OPTS -n"

# Add your favorite options here
#OPTS="$OPTS -s 0 -i 10 -r -C"
OPTS="$OPTS -r -C -D"

# uncomment and modify this to check the state of the AC adapter
OPTS="$OPTS -a /proc/acpi/ac_adapter/*/state"

# uncomment and modify this to check the system temperature
#OPTS="$OPTS -t /proc/acpi/thermal_zone/*/temperature 75"

Comment 10 Gregory Gulik 2006-08-07 22:30:42 EDT
There is definitely a problem in the recent FC5 kernels.  I have a Compaq R3000Z
which used to have working cpu frequency scaling and I only recently noticed it
doesn't work.  I'm going to find a repo with all the old kernels and try to
download some old ones and determine when it "broke"

The Compaq R3000Z has an AMD processor:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 8
model name      : AMD Athlon(tm) XP Processor 3000+
stepping        : 2
cpu MHz         : 800.000
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush mmx fxsr sse sse2 syscall nx mmxext 3dnowext 3dnow ts fid vid ttp
bogomips        : 1597.94


In earlier FC5 kernels the cpuspeed daemon properly scaled the CPU between
800Mhz and 1600Mhz.
Comment 11 barry gould 2006-12-04 13:00:22 EST
FWIW, it's working better in FC6, although I think it's still gotten stuck at
the lower speed after suspend/resume a few times.

Barry
Comment 12 Jarod Wilson 2007-01-08 13:16:28 EST
Need to see some log output after it gets stuck to have a hope of diagnosing. If
possible, grab /var/log/messages, dmesg, ls -lR
/sys/devices/system/cpu/cpu*/cpufreq and cat
/sys/devices/system/cpu/cpu*/cpufreq/* output if/when it gets stuck...

Gregory, if you could do the same with the latest kernel and cpuspeed on your
Compaq, something might jump out as to why your system isn't working...
Comment 13 barry gould 2007-01-11 14:30:56 EST
Created attachment 145382 [details]
var-log-messages
Comment 14 barry gould 2007-01-11 14:31:41 EST
Created attachment 145383 [details]
dmesg
Comment 15 barry gould 2007-01-11 14:37:01 EST
I'm having troubles in FC6 now (it had been working for a while)... 
CPUSpeed claims to be running
# rpm -q cpuspeed
cpuspeed-1.2.1-1.43.fc6

# service cpuspeed status
Frequency scaling enabled using ondemand governor

but the Gnome CPU Frequency Scaling Monitor is always showing 600MHz.


]# ls -lR /sys/devices/system/cpu/cpu*/cpufreq
/sys/devices/system/cpu/cpu0/cpufreq:
total 0
-r--r--r-- 1 root root 4096 Jan 11 11:01 affected_cpus
-r-------- 1 root root 4096 Jan 11 11:01 cpuinfo_cur_freq
-r--r--r-- 1 root root 4096 Jan 11 11:01 cpuinfo_max_freq
-r--r--r-- 1 root root 4096 Jan 11 11:01 cpuinfo_min_freq
drwxr-xr-x 2 root root    0 Jan 11 11:19 ondemand
-r--r--r-- 1 root root 4096 Jan 11 11:01 scaling_available_frequencies
-r--r--r-- 1 root root 4096 Jan 11 11:00 scaling_available_governors
-r--r--r-- 1 root root 4096 Jan 11 11:01 scaling_cur_freq
-r--r--r-- 1 root root 4096 Jan 11 11:00 scaling_driver
-rw-r--r-- 1 root root    0 Jan 11 11:19 scaling_governor
-rw-r--r-- 1 root root 4096 Jan 11 11:01 scaling_max_freq
-rw-r--r-- 1 root root 4096 Jan 11 11:01 scaling_min_freq

/sys/devices/system/cpu/cpu0/cpufreq/ondemand:
total 0
-rw-r--r-- 1 root root 4096 Jan 11 11:32 ignore_nice_load
-rw-r--r-- 1 root root 4096 Jan 11 11:32 sampling_rate
-r--r--r-- 1 root root 4096 Jan 11 11:32 sampling_rate_max
-r--r--r-- 1 root root 4096 Jan 11 11:32 sampling_rate_min
-rw-r--r-- 1 root root 4096 Jan 11 11:32 up_threshold


# cat /sys/devices/system/cpu/cpu*/cpufreq/*
0
600000
1600000
600000
cat: /sys/devices/system/cpu/cpu0/cpufreq/ondemand: Is a directory
1600000 1600000 1600000 1400000 1200000 1000000 800000 600000 
ondemand userspace performance 
600000
centrino
ondemand
600000
600000


/var/log/messages and dmesg attached

# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n"|grep kernel|sort
kernel-2.6.18-1.2869.fc6.i686
kernel-devel-2.6.18-1.2798.fc6.i686
kernel-devel-2.6.18-1.2869.fc6.i686
kernel-headers-2.6.18-1.2798.fc6.i386
kernel-headers-2.6.18-1.2869.fc6.i386
# uname -a
Linux brwebn13.pennysaverusa.net 2.6.18-1.2869.fc6 #1 SMP Wed Dec 20 14:51:19
EST 2006 i686 i686 i386 GNU/Linux

Please let me know if I can provide any other info.

Thanks,
Barry
Comment 16 Jarod Wilson 2007-01-11 15:23:20 EST
Looks like the big problem here is that you're winding up with scaling_max_freq
actually containing the same thing as scaling_min_freq. How that is happening
though, I'm not quite sure...

What can you see (if anything) in
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq after a 'service cpuspeed
stop' and/or on bootup if cpuspeed is chkconfig'd off?

As a last resort, I think you ought to be able to force your actual max speed by
setting MAX_SPEED=1600000 in /etc/cpuspeed.conf and restarting cpuspeed.
Comment 17 barry gould 2007-01-11 15:59:27 EST
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 
600000
[root@brwebn13 ~]# service cpuspeed stop
Disabling ondemand cpu frequency scaling:                  [  OK  ]
[root@brwebn13 ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 
600000

Setting MAX_SPEED and restarting CPUSPEED doesn't seem to help or change what's
in /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 

will try disabling cpuspeed and rebooting

Thanks,
Barry
Comment 18 barry gould 2007-01-11 16:24:15 EST
Disabled cpuspeed with chkconfig, and rebooted...
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq still read 600000

Cpuspeed had been working OK in FC6 until a few days ago.

Thanks,
Barry
Comment 19 Jarod Wilson 2007-01-11 16:26:57 EST
Damn. Anything in the bios relating to cpu speed that's been tweaked? (Or can be
tweaked?) I think its time to start digging into the kernel-side code. With
cpuspeed disabled and still only seeing 600MHz for a max freq on a fresh boot,
cpuspeed is completely eliminated as a suspect, so far as I can tell.
Comment 20 Jarod Wilson 2007-01-11 16:28:08 EST
Just had another thought... Does the value in scaling_max_freq (w/cpuspeed
chkconfig'd off) change based on whether you boot with or without ac power
connected?
Comment 21 barry gould 2007-01-11 16:33:18 EST
In case you didn't notice this in the messages log,
after restarting cpuspeed, I see this:
Jan 11 13:31:47 brwebn13 cpuspeed: Invalid governor "governor" specified,
falling back to ondemand

in /var/log/messages

Thanks,
Barry
Comment 22 barry gould 2007-01-11 16:35:18 EST
Re AC power...
In FC5, I _definately_ noticed differences in cpuspeed's behavior depending on
whether AC was plugged in on boot.
Hadn't been having that problem in FC6, but I'll check it now.

Haven't made any BIOS changes lately.

Thanks,
Barry
Comment 23 barry gould 2007-01-11 16:51:37 EST
OK... on AC power, it's always 600000
booting on battery, it's at 1600000
!

Is there a solution or workaround for this?

I checked the BIOS, it's set to always boot at 1.6 

Thanks,
Barry
Comment 24 Jarod Wilson 2007-01-11 23:00:55 EST
(In reply to comment #21)
> In case you didn't notice this in the messages log,
> after restarting cpuspeed, I see this:
> Jan 11 13:31:47 brwebn13 cpuspeed: Invalid governor "governor" specified,
> falling back to ondemand

Yeah, there's a minor screw-up in that'll be fixed in the next build, which
should get pushed out tomorrow...

(In reply to comment #23)
> OK... on AC power, it's always 600000
> booting on battery, it's at 1600000
> !
> 
> Is there a solution or workaround for this?

Not that I know of just yet, but this isn't the first I've heard of this
happening, and knowing that its reproducable is progress toward a solution... :)

I'll have to dig into this a bit tomorrow. Can you attach dmesg output from both
an AC and a battery boot? I'm hoping maybe some difference in the two will pop
up that could be relevant...
Comment 25 barry gould 2007-01-12 13:03:03 EST
I'm about to post 3 attachments.

First will be dmesg on AC. Note the Processor Speed (about 600) and the bogomips.

Next attachment will be on Batt... CPU speed about 1600, more bogomips.

Final attachment is another one on batt, but it shows 600MHz for some reason.

Thanks,
Barry
Comment 26 barry gould 2007-01-12 13:04:45 EST
Created attachment 145469 [details]
dmesg after booting on AC power
Comment 27 barry gould 2007-01-12 13:05:23 EST
Created attachment 145470 [details]
dmesg after booting on AC power
Comment 28 barry gould 2007-01-12 13:09:34 EST
Comment on attachment 145469 [details]
dmesg after booting on AC power

duplicate
Comment 29 barry gould 2007-01-12 13:11:08 EST
Created attachment 145471 [details]
dmesg after booting on batt power, CPU correctly shows 1594MHz
Comment 30 barry gould 2007-01-12 13:12:23 EST
Created attachment 145472 [details]
another boot on batt power, but with CPU speed (incorrrectly) showing 600MHz
Comment 31 barry gould 2007-01-12 13:14:31 EST
Another note:

If I boot on battery, everything is working fine.

As soon as I plug in the AC,  /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
drops to 600000
and CPU speed seems to stay at 600.

Thanks,
Barry
Comment 32 Jarod Wilson 2007-01-12 15:39:01 EST
Interesting. The dmesg output seems to indicate the real problem is well before
we get into the cpu frequency scaling code. It looks like we're having issues
with the tsc. I'm slowly cobbling together a kernel build with some extra
debugging output added in places to see if we can't further isolate the problem,
but in the interim, if you would, please see what sort of scaling_max_freq
results you get if you boot the system with 'notsc' added to your kernel options.
Comment 33 barry gould 2007-01-12 20:19:14 EST
with 'notsc', I get 1600000 in max freq with the A/C plugged in, so that's an
improvement.

Thanks,
Barry
Comment 34 barry gould 2007-01-12 21:35:58 EST
ignore #33

The whole problem for me seems to be being caused by the 65watt "travel charger"
for my Dell D800.

When on batteries, everything is fine.
When on A/C with one charger, everything is fine.
When on A/C with the "travel charger", the system will not go over 600 MHz, no
matter what I do with 'notsc', etc.

I apologize profusely for the confusion.

Since the system can run at full speed with the battery, it would follow that it
should be able to run full speed (at least for a while) with batt + travel adapter.
If anyone knows how to get this to work better, I'd be very happy.

Thanks,
Barry
Comment 35 Jarod Wilson 2007-01-15 12:01:30 EST
Hrm... I'm altering the distro to fc6, component to kernel and summary from
"CPUSPEED not working reliably on Pentium-M" to "CPU locked at lowest frequency
when using travel charger"... Not sure yet where to poke next, will ask around a
bit... DaveJ, any ideas?
Comment 36 Jarod Wilson 2007-01-15 17:02:40 EST
Seems to be different, but at least semi-similar to bug 205305. Can you grab
dmesg output from a boot using the travel adapter with cpufreq.debug=7 in your
kernel params?
Comment 37 barry gould 2007-01-16 00:21:00 EST
Created attachment 145650 [details]
dmesg on travel charger with cpufreq.debug=7
Comment 38 Jarod Wilson 2007-01-16 16:57:38 EST
Interesting... So it looks like we at least partially recognize how fast the
processor is still, and our first call to verify 600MHz to 1.6GHz succeeds, but
then we immediately decide we should re-verify for 600 to 600MHz...

----8<----
speedstep-centrino: adding state 0 with frequency 1600000 and control value 1031
speedstep-centrino: adding state 1 with frequency 1600000 and control value 1031
speedstep-centrino: adding state 2 with frequency 1600000 and control value 1031
speedstep-centrino: adding state 3 with frequency 1400000 and control value 0e2d
speedstep-centrino: adding state 4 with frequency 1200000 and control value 0c24
speedstep-centrino: adding state 5 with frequency 1000000 and control value 0a1d
speedstep-centrino: adding state 6 with frequency 800000 and control value 0815
speedstep-centrino: adding state 7 with frequency 600000 and control value 0610
speedstep-centrino: centrino_cpu_init: cur=600000kHz
[...]
cpufreq-core: setting new policy for CPU 0: 600000 - 1600000 kHz
freq-table: request for verification of policy (600000 - 1600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 1600000 kHz) for cpu 0
freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
cpufreq-core: new min and max freqs are 600000 - 600000 kHz
----8<----

This appears to trigger when we switch from the userspace governor to the
ondemand governor, within the __cpufreq_set_policy function in
drivers/cpufreq/cpufreq.c. I'm still digging into the intermediate bits between
the two verify calls to see why we're locking down at 600MHz...
Comment 39 barry gould 2007-01-16 17:09:53 EST
fwiw, this was in runlevel 1 with cpuspeed disabled, so I'm not sure if the
governor is getting changed or not.
Does the kernel change it?

Thanks,
Barry
Comment 40 Jarod Wilson 2007-01-16 17:14:15 EST
Hrm... I believe we have things set up to default to userspace, and its only
when we fire up cpuspeed that we switch to ondemand, so perhaps this was the
transition from no gov to userspace?... Lemme roll a kernel w/some extra
dprintk's in there to give a bit more info on what's going on in there...
Comment 41 Jarod Wilson 2007-01-18 10:36:21 EST
If you'd be so kind, please grab the kernel here:

http://people.redhat.com/jwilson/test_kernels/bz188453/

Install that, boot it w/cpufreq.debug=7 and slap some more dmesg output up here.
We'll get a bit more debug output around where we get locked down to 600MHz
that'll further isolate exactly where its happening...
Comment 42 barry gould 2007-01-23 00:07:56 EST
Created attachment 146268 [details]
dmesg with test kernel on travel charger with cpufreq.debug=7
Comment 43 Jarod Wilson 2007-01-25 16:01:25 EST
Hrm, okay... I'll dig into the CPUFREQ_INCOMPATIBLE section a bit more. However,
in the interim, can you see if the recent 2.6.19-based FC6 kernel improves the
situation? I have another report (bug 223816) of a similar situation that went
away after such an upgrade.
Comment 44 barry gould 2007-01-26 18:20:26 EST
No apparent change with the 2895 kernel.

$ uname -a
Linux brwebn13.pennysaverusa.net 2.6.19-1.2895.fc6 #1 SMP Wed Jan 10 19:28:18
EST 2007 i686 i686 i386 GNU/Linux

$ rpm -q kernel
kernel-2.6.19-1.2895.fc6


Thanks,
Barry
Comment 45 Jarod Wilson 2007-07-16 15:42:54 EDT
Unfortunately, this bug got lost in the shuffle for a bit... Before I get back
to poking at it, can you confirm this is still an issue with the latest
available kernel? Something 2.6.22.1 or later would be preferred.
Comment 46 barry gould 2007-07-16 16:12:56 EDT
Last I checked, it was still happening, but I'm guessing it's mainly a hardware
problem. See comment #34 above.

I'm OK if you close this bug, but if there's something else that can be done
without spending a lot of your time, it'd be nice.

Thanks!
Comment 47 barry gould 2007-07-16 16:16:44 EDT
FWIW, Dell says the travel charger will work with my D800 laptop but in a
'reduced performance' mode, so it is probably the BIOS that is restricting
something.

I would think it would be possible to get the laptop to use the battery for any
extra power needed for short bursts of higher CPU speed, but that's just a wild
guess.
Comment 48 Jarod Wilson 2007-07-16 16:45:25 EDT
Ah... Indeed, this does sound like its something Dell does in the bios, so we're
actually doing the right thing in this case. With a bit of work, one could
probably conjure up a way to override the throttling, but if we're doing what is
intended by the mfg here, its probably best not to.

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