Looks like the DSDT has a lot of code going on for the C-states. Your laptop
has 4 different CST packages so it might be getting stuck near the top which
only allow C1 - C2 states. Most laptops that I've seen usualy have 2 packages
which probably simplifies things. You could hack your DSDT (see my previous
post --How I got C3 with a P4-m & ICH-3) and include only the relevant info for
CST4 -- then it should hit C3 / C4 states most of the time. Can't gurantee it
would work and there is always the chance it won't be stable. But if it
doesn't work you've only wasted some time compiling a new kernel and once the
kernel is recompiled you can change the DSDT in a few minutes, reboot and use
the new code. Here's the relevant info from your DSDT on sourceforge:
Name (CST1, Package (0x02)
{
0x01,
Package (0x04)
{
ResourceTemplate ()
{
Register (FFixedHW, 0x08, 0x00, 0x0000000000000000)
},
0x01,
0x01,
0x03E8
}
})
Name (CST2, Package (0x03)
{
0x02,
Package (0x04)
{
ResourceTemplate ()
{
Register (FFixedHW, 0x08, 0x00, 0x0000000000000000)
},
0x01,
0x01,
0x03E8
},
Package (0x04)
{
ResourceTemplate ()
{
Register (SystemIO, 0x08, 0x00, 0x0000000000001014)
},
0x02,
0x01,
0x01F4
}
})
Name (CST3, Package (0x04)
{
0x03,
Package (0x04)
{
ResourceTemplate ()
{
Register (FFixedHW, 0x08, 0x00, 0x0000000000000000)
},
0x01,
0x01,
0x03E8
},
Package (0x04)
{
ResourceTemplate ()
{
Register (SystemIO, 0x08, 0x00, 0x0000000000001014)
},
0x02,
0x01,
0x01F4
},
Package (0x04)
{
ResourceTemplate ()
{
Register (SystemIO, 0x08, 0x00, 0x0000000000001015)
},
0x03,
0x55,
0xFA
}
})
Name (CST4, Package (0x05)
{
0x04,
Package (0x04)
{
ResourceTemplate ()
{
Register (FFixedHW, 0x08, 0x00, 0x0000000000000000)
},
0x01,
0x01,
0x03E8
},
Package (0x04)
{
ResourceTemplate ()
{
Register (SystemIO, 0x08, 0x00, 0x0000000000001014)
},
0x02,
0x01,
0x01F4
},
Package (0x04)
{
ResourceTemplate ()
{
Register (SystemIO, 0x08, 0x00, 0x0000000000001015)
},
0x03,
0x55,
0xFA
},
Package (0x04)
{
ResourceTemplate ()
{
Register (SystemIO, 0x08, 0x00, 0x0000000000001016)
},
0x03,
0xB9,
0x64
}
})
Method (_CST, 0, NotSerialized)
{
If (\C2NA)
{
Return (CST1)
}
If (\C3NA)
{
Return (CST2)
}
If (\_SB.PCI0.LPC.EC.AC._PSR ())
{
Return (CST3)
}
If (\C4NA)
{
Return (CST3)
}
Return (CST4)
}
}
}
[EMAIL PROTECTED] wrote: Send Power mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.bughost.org/mailman/listinfo/power
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Power digest..."
Today's Topics:
1. Inconsistent use of C3 (Dale Pontius)
2. Re: Inconsistent use of C3 (Arjan van de Ven)
3. Re: Power consumption of my server (Piers Kittel)
4. Re: Inconsistent use of C3 (Dale Pontius)
5. Re: Inconsistent use of C3 (Arjan van de Ven)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 Aug 2007 14:23:55 -0400
From: Dale Pontius
Subject: Inconsistent use of C3
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
I have a Thinkpad R50, running Gentoo with 2.6.22-gentoo-r2 with the
HPET patches applied.
Sometimes C3 gets used, and sometimes it doesn't - on a completely idle
machine.
When at work, the machine is plugged into a port replicator, the lid is
shut, and a flat panel connected through a KVM is used for the display.
If I do the complete boot with the display visible on the flat panel, it
appears that the processor will never go into C3. If after selecting
the kernel with grub, I switch the KVM over to the deskside, then C3
will get used. I'm not 100% certain about this pattern, but it seems
clear at the moment. Looking through the logs I don't see obvious
differences other than the recognition of the second head. Most of the
time I don't use the display, but ssh in from my deskside machine.
After heavy load, C3 is no longer used on a completely idle machine,
even though it was used prior to the heavy load.
Start the machine, switch the KVM to the deskside, get the morning
coffee. When I get back, ssh in, establish sessions, etc. The idle
laptop is using C3 with between 6 and 8 wakeups per second. Run some
sort of task that saturates the machine, and when it's done the idle
machine will only drop into C2, though still at between 6 and 8 wakeups
per second. In fact, as near as I can tell all the rest of the stats
are the same as before the heavy job, except C2 instead of C3.
Any idea why I would "lose" C3? I've run my heavy job, and the current
powertop is below.
Thanks,
Dale Pontius
PowerTOP version 1.7 (C) 2007 Intel Corporation
Cn Avg residency (30s) P-states (frequencies)
C0 (cpu running) ( 0.1%)
C1 0.0ms ( 0.0%) 1500 Mhz 0.0%
C2 132.6ms (99.9%) 1400 Mhz 0.0%
C3 0.0ms ( 0.0%) 1200 Mhz 0.0%
600 Mhz 100.0%
Wakeups-from-idle per second : 7.5
no ACPI power usage estimate available
Top causes for wakeups:
23.3% ( 2.0) afs_rxevent : schedule_timeout (process_timeout)
14.7% ( 1.3) cpufreq-set : queue_delayed_work_on
(delayed_work_timer_fn)
11.6% ( 1.0) ifplugd : schedule_timeout (process_timeout)
11.6% ( 1.0) clsbd : schedule_timeout (process_timeout)
9.7% ( 0.8) xfsbufd : schedule_timeout (process_timeout)
7.0% ( 0.6) : ehci_hcd:usb1, uhci_hcd:usb2,
uhci_hcd:usb3, uhci_hcd:usb4, Intel 82801DB-ICH4 Modem, Intel
82801DB-ICH4, eth0
------------------------------
Message: 2
Date: Mon, 27 Aug 2007 13:10:48 -0700
From: Arjan van de Ven
Subject: Re: Inconsistent use of C3
To: Dale Pontius
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Dale Pontius wrote:
> I have a Thinkpad R50, running Gentoo with 2.6.22-gentoo-r2 with the
> HPET patches applied.
>
> Sometimes C3 gets used, and sometimes it doesn't - on a completely idle
> machine.
>
> When at work, the machine is plugged into a port replicator, the lid is
> shut, and a flat panel connected through a KVM is used for the display.
> If I do the complete boot with the display visible on the flat panel, it
> appears that the processor will never go into C3. If after selecting
> the kernel with grub, I switch the KVM over to the deskside, then C3
> will get used. I'm not 100% certain about this pattern, but it seems
one question: is your KVM USB based?
USB is one of the "typical" reasons processors don't go to C3, esp if
USB selective suspend isn't active.....
------------------------------
Message: 3
Date: Tue, 28 Aug 2007 00:21:13 +0100
From: Piers Kittel
Subject: Re: Power consumption of my server
To: Rafa? Krypa
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed
Rafa?,
Thanks very much for the patch - much appreciated.
On 27 Aug 2007, at 14:13, Rafa? Krypa wrote:
> Could you try the small patch I've attached (apply it to your kernel
> sources and recompile, and then load cx88xx module with
> 'ir_disable=1')?
Was a lot better to start with, then MythTV started using the EIT
scanner, which uses the cards (just realised this, should have
thought about this before). I waited until it seemed like MythTV
stopped using the scanner, but it doesn't seem to be any different:
Cn Avg residency P-states (frequencies)
C0 (cpu running) (19.7%)
C1 0.0ms ( 0.0%)
C2 3.4ms (80.3%)
Wakeups-from-idle per second : 273.4 interval: 5.0s
no ACPI power usage estimate available
Top causes for wakeups:
31.2% ( 94.0) : cx88[1], cx88[1]
31.2% ( 94.0) : cx88[0], cx88[0], eth1
13.6% ( 41.0) mythbackend : do_nanosleep (hrtimer_wakeup)
13.4% ( 40.4) mythbackend : schedule_timeout (process_timeout)
6.0% ( 18.0) mythbackend : futex_wait (hrtimer_wakeup)
1.3% ( 3.8) : ide0
0.7% ( 2.0) : clocksource_register
(clocksource_watchdog)
0.5% ( 1.6) xfsbufd : schedule_timeout (process_timeout)
0.3% ( 1.0) apache2 : schedule_timeout (process_timeout)
0.3% ( 0.8) : ide_do_rw_disk
(ledtrig_ide_timerfunc)
0.2% ( 0.6) ifconfig : __netdev_watchdog_up (dev_watchdog)
0.2% ( 0.6) kdvb-fe-1 : schedule_timeout (process_timeout)
0.2% ( 0.6) kdvb-fe-0 : schedule_timeout (process_timeout)
0.2% ( 0.6) : neigh_table_init_no_netlink
(neigh_periodic_timer)
0.1% ( 0.4) : neigh_table_init_no_netlink
(neigh_periodic_timer)
0.1% ( 0.4) : queue_delayed_work_on
(delayed_work_timer_fn)
0.1% ( 0.2) : sk_reset_timer (tcp_delack_timer)
0.1% ( 0.2) sshd : sk_reset_timer (tcp_write_timer)
0.1% ( 0.2) mysqld : start_this_handle (commit_timeout)
0.1% ( 0.2) init : schedule_timeout (process_timeout)
0.1% ( 0.2) : page_writeback_init (wb_timer_fn)
0.1% ( 0.2) rpc.idmapd : schedule_timeout (process_timeout)
0.1% ( 0.2) : neigh_update (neigh_timer_handler)
I don't know why the cards are causing a lot of interrupts if the
backend isn't scanning for EIT data... or is it some continuous
thing? Am surprised the scanner would use both cards, not just one.
Your thoughts? Or is the cards still polling for IR stuff?
I'll have another look tomorrow morning to see if it's any better.
Thanks very much for your time again though. I think you should
submit the kernel patch - would be useful for some people I'd guess?
Regards - Piers
------------------------------
Message: 4
Date: Tue, 28 Aug 2007 08:18:09 -0400
From: Dale Pontius
Subject: Re: Inconsistent use of C3
To: Arjan van de Ven
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
Arjan van de Ven wrote:
> Dale Pontius wrote:
>> I have a Thinkpad R50, running Gentoo with 2.6.22-gentoo-r2 with the
>> HPET patches applied.
>>
>> Sometimes C3 gets used, and sometimes it doesn't - on a completely idle
>> machine.
>>
>> When at work, the machine is plugged into a port replicator, the lid is
>> shut, and a flat panel connected through a KVM is used for the
>> display. If I do the complete boot with the display visible on the
>> flat panel, it
>> appears that the processor will never go into C3. If after selecting
>> the kernel with grub, I switch the KVM over to the deskside, then C3
>> will get used. I'm not 100% certain about this pattern, but it seems
>
> one question: is your KVM USB based?
> USB is one of the "typical" reasons processors don't go to C3, esp if
> USB selective suspend isn't active.....
No, this KVM uses ps2 ports for K and M, and 15-pin VGA for V. At the
moment there are no USB devices in use. I just double-checked that. My
deskside has a 4-port hub, and that shows up on usbview. Nothing shows
on usbview on the laptop, so the port replicator does not appear as a
USB hub.
For this morning's boot I left the KVM pointed to the laptop, and indeed
C3 is visible in the listing, but is not used.
While I've been typing this, the laptop has been running Gentoo's
"emerge --sync". It just finished and I started powertop, preparing to
start unloading USB modules to see if I could get into C3. It's already
there. The listing is tacked onto the end. What seems odd to me is
that all of the numbers are essentially the same as the listing
yesterday, except that yesterday it was in C2, and today it's in C3.
Can you point me to the source that handles these state transitions, or
any documentation?
Thanks,
Dale Pontius
PowerTOP version 1.7 (C) 2007 Intel Corporation
Cn Avg residency (30s) P-states (frequencies)
C0 (cpu running) ( 0.1%)
C1 0.0ms ( 0.0%) 1500 Mhz 0.0%
C2 41.8ms ( 0.3%) 1400 Mhz 0.0%
C3 147.2ms (99.6%) 1200 Mhz 0.0%
600 Mhz 100.0%
Wakeups-from-idle per second : 6.8
no ACPI power usage estimate available
Top causes for wakeups:
25.9% ( 2.0) afs_rxevent : schedule_timeout (process_timeout)
16.2% ( 1.2) cpufreq-set : queue_delayed_work_on
(delayed_work_timer_fn)
13.2% ( 1.0) ifplugd : schedule_timeout (process_timeout)
11.0% ( 0.8) xfsbufd : schedule_timeout (process_timeout)
10.1% ( 0.8) : ehci_hcd:usb1, uhci_hcd:usb2,
uhci_hcd:usb3, uhci_hcd:usb4, Intel 82801DB-ICH4 Modem, Intel
82801DB-ICH4, eth0
6.6% ( 0.5) ip : e1000_intr (e1000_watchdog)
------------------------------
Message: 5
Date: Tue, 28 Aug 2007 09:52:40 -0700
From: Arjan van de Ven
Subject: Re: Inconsistent use of C3
To: Dale Pontius
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Dale Pontius wrote:
> While I've been typing this, the laptop has been running Gentoo's
> "emerge --sync". It just finished and I started powertop, preparing to
> start unloading USB modules to see if I could get into C3. It's already
> there. The listing is tacked onto the end. What seems odd to me is
> that all of the numbers are essentially the same as the listing
> yesterday, except that yesterday it was in C2, and today it's in C3.
>
> Can you point me to the source that handles these state transitions, or
> any documentation?
>
drivers/acpi/processor_idle.c handles this code.
The "old" code (mainline) isn't very smart, and doesn't deal with
tickless well.
One thing to try is to use the -hrt patches, they contain a rewrite of
this code, specifically the "menu governer" which is designed for use
in a tickless idle kernel.
------------------------------
_______________________________________________
Power mailing list
[email protected]
http://www.bughost.org/mailman/listinfo/power
End of Power Digest, Vol 4, Issue 27
************************************
---------------------------------
Pinpoint customers who are looking for what you sell. _______________________________________________
Power mailing list
[email protected]
http://www.bughost.org/mailman/listinfo/power
