But are you saying that with most desktop mobos one doesn't usually have
the
different power states available at all? So basically the only means to
conserve power is to scale the frequency?
Please update your BIOS and try.
I updated my Asus P5B Deluxe BIOS with no luck (this latest BIOS is
I'm probably missing something crucial here. So how do I enable power
states? I'm using 64-bit Gentoo. My mobo is Asus P5B Deluxe. Otherwise
ACPI works fine.
The BIOS has to expose this support in ACPI, if it doesn't (which is often
the case on desktop boards) you won't get any C-state
For some reason I'm not able to enable processor power states (c1, c2 etc.)
for my Core 2 Duo. This is what I get::
cat /proc/acpi/processor/CPU1/info
processor id:0
acpi id: 1
bus mastering control: no
power management:no
throttling control: no
limit
But are you saying that with most desktop mobos one doesn't usually have
the
different power states available at all? So basically the only means to
conserve power is to scale the frequency?
Please update your BIOS and try.
I updated my Asus P5B Deluxe BIOS with no luck (this latest BIOS is
For some reason I'm not able to enable processor power states (c1, c2 etc.)
for my Core 2 Duo. This is what I get::
cat /proc/acpi/processor/CPU1/info
processor id:0
acpi id: 1
bus mastering control: no
power management:no
throttling control: no
limit
I'm probably missing something crucial here. So how do I enable power
states? I'm using 64-bit Gentoo. My mobo is Asus P5B Deluxe. Otherwise
ACPI works fine.
The BIOS has to expose this support in ACPI, if it doesn't (which is often
the case on desktop boards) you won't get any C-state
Mark Lord wrote:
This is mostly a problem with the WD Raptor drive, and some other WD
drives.
I have not yet encountered/noticed the problem with other brands.
Sounds like this is a serious bug in the WD firmware.
For personal systems, yes. For servers, probably not a bug.
In my case the
Mark Lord wrote:
This is mostly a problem with the WD Raptor drive, and some other WD
drives.
I have not yet encountered/noticed the problem with other brands.
Sounds like this is a serious bug in the WD firmware.
For personal systems, yes. For servers, probably not a bug.
In my case the
Q: What conclusion can I make on "hdparm -t" results or can I make any
conclusions? Do I really have lower performance with NCQ or not? If I do,
is this because of my HD or because of kernel?
What IO scheduler are you using? If AS or CFQ, could you try with deadline?
I was using CFQ. I now
I'm using Linux 2.6.20.4. I noticed that I get lower SATA hard drive
throughput with 2.6.20.4 than with 2.6.19. The reason was that 2.6.20
enables NCQ by defauly (queue_depth = 31/32 instead of 0/32). Transfer rate
was measured using "hdparm -t":
With NCQ (queue_depth == 31): 50MB/s.
Without
I'm using Linux 2.6.20.4. I noticed that I get lower SATA hard drive
throughput with 2.6.20.4 than with 2.6.19. The reason was that 2.6.20
enables NCQ by defauly (queue_depth = 31/32 instead of 0/32). Transfer rate
was measured using hdparm -t:
With NCQ (queue_depth == 31): 50MB/s.
Without
Q: What conclusion can I make on hdparm -t results or can I make any
conclusions? Do I really have lower performance with NCQ or not? If I do,
is this because of my HD or because of kernel?
What IO scheduler are you using? If AS or CFQ, could you try with deadline?
I was using CFQ. I now
12 matches
Mail list logo
