Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
The documentation is uhm, what's on intel's (growing) blog post and responses: https://software.intel.com/en-us/articles/intel-performance-counter-monitor-a-better-way-to-measure-cpu-utilization Yes, we can / should add clearer documentation. I had to also go hunting in the source to figure some of it out. FREQ/AFREQ is just the current clock cycle counters / clock reference counter (TSC). Ie, a freq or afreq of 1.0 means the clock cycle counters == TSC counter. FREQ takes the sleep state into account (ie, only counts _running_ cycles.) AFREQ doesn't. So FREQ gives you a good indication of the running duty cycle versus the ideal maximum, and AFREQ tells you what frequency the core is running at versus the reference frequency. An AFREQ of 1.0 means that the chip is underclocking that core. An AFREQ of 1.0 means turboboost is on and it's overclocking that core. -a On 11 May 2014 17:40, Kevin Oberman rkober...@gmail.com wrote: On Fri, May 9, 2014 at 1:36 PM, Adrian Chadd adr...@freebsd.org wrote: cool! next; # pkg install intel-pcm # kldload cpuctl # pcm.x 1 See what it reports. OK. Any documentation on what this is supposed to tell me? Some of it makes perfect sense and some baffles me. I see C-states of C1 and C6 when on AC and C1, C3, and C7 when on battery (and, of course, C0). FREQ vs. AFREQ look interesting, but I'm not sure I really understand the implications. The last few lines, from PHYSICAL CORE IPC, are particularly mysterious to me. I can understand the words, but I think that they carry more significance than is obvious, at least to me. I'm not a hardware guy. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Fri, May 9, 2014 at 1:36 PM, Adrian Chadd adr...@freebsd.org wrote: cool! next; # pkg install intel-pcm # kldload cpuctl # pcm.x 1 See what it reports. OK. Any documentation on what this is supposed to tell me? Some of it makes perfect sense and some baffles me. I see C-states of C1 and C6 when on AC and C1, C3, and C7 when on battery (and, of course, C0). FREQ vs. AFREQ look interesting, but I'm not sure I really understand the implications. The last few lines, from PHYSICAL CORE IPC, are particularly mysterious to me. I can understand the words, but I think that they carry more significance than is obvious, at least to me. I'm not a hardware guy. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
In message 20140505163316.r11...@sola.nimnet.asn.au, Ian Smith writes: On Mon, 5 May 2014 06:25:21 +, Poul-Henning Kamp wrote: In message 20140505153421.w11...@sola.nimnet.asn.au, Ian Smith writes: Do we have a canonical page with all the various workarounds one should attempt in order to get suspend/resume to work ? Bits scattered all over the place. For the above there's: So based on various scattered hints, I tried booting the VT kernel, r265336, on my Thinkpad T430s and that seems to fix both Suspend/Resume and also console switching. Much appreciated! I'll keep an eye on any peripheral bogons as I used it now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
Hi! On 9 May 2014 02:55, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 20140505163316.r11...@sola.nimnet.asn.au, Ian Smith writes: On Mon, 5 May 2014 06:25:21 +, Poul-Henning Kamp wrote: In message 20140505153421.w11...@sola.nimnet.asn.au, Ian Smith writes: Do we have a canonical page with all the various workarounds one should attempt in order to get suspend/resume to work ? Bits scattered all over the place. For the above there's: So based on various scattered hints, I tried booting the VT kernel, r265336, on my Thinkpad T430s and that seems to fix both Suspend/Resume and also console switching. Much appreciated! I'll keep an eye on any peripheral bogons as I used it now. Woo! Would you mind populating http://wiki.freebsd.org/Laptops with your details? Thanks! -a ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Fri, May 9, 2014 at 3:25 AM, Adrian Chadd adr...@freebsd.org wrote: Hi! On 9 May 2014 02:55, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 20140505163316.r11...@sola.nimnet.asn.au, Ian Smith writes: On Mon, 5 May 2014 06:25:21 +, Poul-Henning Kamp wrote: In message 20140505153421.w11...@sola.nimnet.asn.au, Ian Smith writes: Do we have a canonical page with all the various workarounds one should attempt in order to get suspend/resume to work ? Bits scattered all over the place. For the above there's: So based on various scattered hints, I tried booting the VT kernel, r265336, on my Thinkpad T430s and that seems to fix both Suspend/Resume and also console switching. Much appreciated! I'll keep an eye on any peripheral bogons as I used it now. Woo! Would you mind populating http://wiki.freebsd.org/Laptops with your details? Thanks! -a Excellent! This alone will save batteries and also lower the carbon footprint of FreeBSD servers! Just to clarify the various settings of *_cx_lowest in rc.conf, HIGH is obvious. At one time, LOW was also obvious, but then some vendors started shipping BIOS that skipped some C-states in different power conditions. E.g. C1, C2 and C3 when on Battery, but only C1 and C3 when on AC. This scenario was common on Sandybridge systems (like my T320). Skipping a state broke LOW as it only saw C1 when on AC. Thus, Cmax appeared. Cmax is simply C8. It is just easier ot remember then C8. The code was re-written to ignore missing C-states and try all possible C-states until C8 was reached. Why LOW was not just changed to deal with this I don't understand, but Cmax (or C8) is recommended to gain the maximum power savings from C-states. On AC power: dev.cpu.0.cx_supported: C1/1/1 C2/3/104 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 8.86% 91.13% last 2685us On battery: dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 3.09% 0.74% 96.15% last 728us Note the supported list on AC? C2/3/104 The first part, C2, is what the OS labels that second state. The next part, 3, is the ACPI number of this state. On AC, this system has no C-state 2, so FreeBSD call the ACPI state 3 C2. Oh, the last number is the number of clock cycles required to get into/out of that state. so in my case, when on battery, my CPU goes ot C2 after being halted for 80 clock cycles and C3 after 109. I hope this makes sense to everyone. I'm not really sure that it does to me! -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
cool! next; # pkg install intel-pcm # kldload cpuctl # pcm.x 1 See what it reports. -a On 9 May 2014 13:12, Kevin Oberman rkober...@gmail.com wrote: On Fri, May 9, 2014 at 3:25 AM, Adrian Chadd adr...@freebsd.org wrote: Hi! On 9 May 2014 02:55, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 20140505163316.r11...@sola.nimnet.asn.au, Ian Smith writes: On Mon, 5 May 2014 06:25:21 +, Poul-Henning Kamp wrote: In message 20140505153421.w11...@sola.nimnet.asn.au, Ian Smith writes: Do we have a canonical page with all the various workarounds one should attempt in order to get suspend/resume to work ? Bits scattered all over the place. For the above there's: So based on various scattered hints, I tried booting the VT kernel, r265336, on my Thinkpad T430s and that seems to fix both Suspend/Resume and also console switching. Much appreciated! I'll keep an eye on any peripheral bogons as I used it now. Woo! Would you mind populating http://wiki.freebsd.org/Laptops with your details? Thanks! -a Excellent! This alone will save batteries and also lower the carbon footprint of FreeBSD servers! Just to clarify the various settings of *_cx_lowest in rc.conf, HIGH is obvious. At one time, LOW was also obvious, but then some vendors started shipping BIOS that skipped some C-states in different power conditions. E.g. C1, C2 and C3 when on Battery, but only C1 and C3 when on AC. This scenario was common on Sandybridge systems (like my T320). Skipping a state broke LOW as it only saw C1 when on AC. Thus, Cmax appeared. Cmax is simply C8. It is just easier ot remember then C8. The code was re-written to ignore missing C-states and try all possible C-states until C8 was reached. Why LOW was not just changed to deal with this I don't understand, but Cmax (or C8) is recommended to gain the maximum power savings from C-states. On AC power: dev.cpu.0.cx_supported: C1/1/1 C2/3/104 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 8.86% 91.13% last 2685us On battery: dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 3.09% 0.74% 96.15% last 728us Note the supported list on AC? C2/3/104 The first part, C2, is what the OS labels that second state. The next part, 3, is the ACPI number of this state. On AC, this system has no C-state 2, so FreeBSD call the ACPI state 3 C2. Oh, the last number is the number of clock cycles required to get into/out of that state. so in my case, when on battery, my CPU goes ot C2 after being halted for 80 clock cycles and C3 after 109. I hope this makes sense to everyone. I'm not really sure that it does to me! -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
In message CAJ-VmomxxYFLCJ6ULjwRhe-Fg03U9RD8tQWt=xknvgrf395...@mail.gmail.com, Adrian Chadd write s: cool! next; # pkg install intel-pcm # kldload cpuctl # pcm.x 1 See what it reports. Lots of numbers. Am I looking for anything in particular ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Tuesday, May 06, 2014 6:15:46 pm Ian Lepore wrote: On Tue, 2014-05-06 at 16:37 -0400, John Baldwin wrote: On Tuesday, May 06, 2014 2:08:35 pm Adrian Chadd wrote: On 5 May 2014 13:57, John Baldwin j...@freebsd.org wrote: The user in question found this on 9-stable with the existing defaults as the HPET was just plain broken on their system and that was unrelated to Cx states. (Rather, Cx states were only involved because worries about them are why the system chose to use HPET. Had Cx states been enabled by default, they would have had to disable those as well in addition to forcing LAPIC instead of HPET.) Hm. Sounds uncomfortable. How does Windows run on systems like this? Do the windows drivers just disable HPET and use LAPIC or worse for timing, and just ignore anything lower than C1? I have no idea. Maybe they use the RTC. :-/ Maybe the HPET on these systems works if you use it sparingly. I believe OS X might have only used the HPET to provide the missing LAPIC wakeups when entering Cx for example. (Our current eventtimer system wants to always use whichever timer it picks, not switch off between them.) The eventtimer code is happy to switch between timers on the fly, but iirc the only interface to that feature is sysctl. I found it fairly easy to add an in-kernel API for changing the frequency of the current timer on the fly. I think it would be just as easy to add a kernel call to change timers as well. Ah. Well, if it's only a small slice of time where machines need this, I'd be fine with those machines just having to disable C1E and forcing use of LAPIC rather than adding a lot of goop to do LAPIC + HPET and then hoping the HPET works well enough. -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On 5 May 2014 13:57, John Baldwin j...@freebsd.org wrote: The user in question found this on 9-stable with the existing defaults as the HPET was just plain broken on their system and that was unrelated to Cx states. (Rather, Cx states were only involved because worries about them are why the system chose to use HPET. Had Cx states been enabled by default, they would have had to disable those as well in addition to forcing LAPIC instead of HPET.) Hm. Sounds uncomfortable. How does Windows run on systems like this? Do the windows drivers just disable HPET and use LAPIC or worse for timing, and just ignore anything lower than C1? I'm going to flip the switch to enable Cmax on defaults/rc.conf on -HEAD today. -a ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Tuesday, May 06, 2014 2:08:35 pm Adrian Chadd wrote: On 5 May 2014 13:57, John Baldwin j...@freebsd.org wrote: The user in question found this on 9-stable with the existing defaults as the HPET was just plain broken on their system and that was unrelated to Cx states. (Rather, Cx states were only involved because worries about them are why the system chose to use HPET. Had Cx states been enabled by default, they would have had to disable those as well in addition to forcing LAPIC instead of HPET.) Hm. Sounds uncomfortable. How does Windows run on systems like this? Do the windows drivers just disable HPET and use LAPIC or worse for timing, and just ignore anything lower than C1? I have no idea. Maybe they use the RTC. :-/ Maybe the HPET on these systems works if you use it sparingly. I believe OS X might have only used the HPET to provide the missing LAPIC wakeups when entering Cx for example. (Our current eventtimer system wants to always use whichever timer it picks, not switch off between them.) -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Tue, 2014-05-06 at 16:37 -0400, John Baldwin wrote: On Tuesday, May 06, 2014 2:08:35 pm Adrian Chadd wrote: On 5 May 2014 13:57, John Baldwin j...@freebsd.org wrote: The user in question found this on 9-stable with the existing defaults as the HPET was just plain broken on their system and that was unrelated to Cx states. (Rather, Cx states were only involved because worries about them are why the system chose to use HPET. Had Cx states been enabled by default, they would have had to disable those as well in addition to forcing LAPIC instead of HPET.) Hm. Sounds uncomfortable. How does Windows run on systems like this? Do the windows drivers just disable HPET and use LAPIC or worse for timing, and just ignore anything lower than C1? I have no idea. Maybe they use the RTC. :-/ Maybe the HPET on these systems works if you use it sparingly. I believe OS X might have only used the HPET to provide the missing LAPIC wakeups when entering Cx for example. (Our current eventtimer system wants to always use whichever timer it picks, not switch off between them.) The eventtimer code is happy to switch between timers on the fly, but iirc the only interface to that feature is sysctl. I found it fairly easy to add an in-kernel API for changing the frequency of the current timer on the fly. I think it would be just as easy to add a kernel call to change timers as well. -- Ian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Sun, 4 May 2014 13:51:20 -0700, Adrian Chadd wrote: On 4 May 2014 13:00, Poul-Henning Kamp p...@phk.freebsd.dk wrote: I havn't seen suspend/resume work for ages on my T4xx laptops and as far as I recall it never worked on this T430s at all. I've tested it (-HEAD) on: * T43 * T60 * T60p * T400 * T500 * T420 * X220 I'm actively using the T60, T400 and X220 right now. So, is the USB not working after $n resumes on T4xx and T2xx (at least) now fixed in HEAD? If so, it would be REALLY good to MFC whatever fixed it to 10 and hopefully to 9 before 9.3. I need to do more tests on stable/9; it didn't work with the offered workarounds on 9.2-RELEASE (leaving VESA out of kernel leaves me with no screen on resume in console mode, setting sysctl dev.[ue]hci.*.wake=1 fails to even start to resume) though if that works on 10 I'd give it a go, despite Darren Pilgrim's dvd1_to_memstick script failing to have pkg use any of the local DVD packages, which is why I went back to 9.2 I know you only like working on HEAD, but unless there's API/ABI reasons preventing MFC, it would be great to have 9.3 work in this respect .. my X200 is not useful for purpose if it won't suspend/resume 100% reliably, with USB, and I don't want to run 11 on it, it's needed for developing non-FreeBSD stuff (in freepascal, if that's not a dirty word here :) and for that it needs to be rock solid while travelling from place to place. I'd like to see it working on more laptops and I've worked with various people in the past to try and fix whichever resume issues I find. Indeed; last I heard was last July with unsolved USB issues on your T400, and the mysterious but related 'CPU0: local APIC error 0x40' I'm happy leaving this as-is but at some point something has to be bitten and the bugs in the drivers / ACPI stuff need to be fixed. :) It's a bit disconcerting if fixes only ever make it into HEAD, for me. cheers, Ian (someone please sing out if I shouldn't be crossposting to -arch) ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
In message 20140505153421.w11...@sola.nimnet.asn.au, Ian Smith writes: I need to do more tests on stable/9; it didn't work with the offered workarounds on 9.2-RELEASE (leaving VESA out of kernel leaves me with no screen on resume in console mode, setting sysctl dev.[ue]hci.*.wake=1 Do we have a canonical page with all the various workarounds one should attempt in order to get suspend/resume to work ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Mon, 5 May 2014 06:25:21 +, Poul-Henning Kamp wrote: In message 20140505153421.w11...@sola.nimnet.asn.au, Ian Smith writes: I need to do more tests on stable/9; it didn't work with the offered workarounds on 9.2-RELEASE (leaving VESA out of kernel leaves me with no screen on resume in console mode, setting sysctl dev.[ue]hci.*.wake=1 Do we have a canonical page with all the various workarounds one should attempt in order to get suspend/resume to work ? Bits scattered all over the place. For the above there's: http://unethicalblogger.com/2013/12/03/scratchiest-neckbeard-freebsd-x200.html which refers to te tail of this thread in -usb (and -stable) http://lists.freebsd.org/pipermail/freebsd-usb/2013-July/thread.html#12242 which began with Adrian's post in http://lists.freebsd.org/pipermail/freebsd-usb/2013-June/thread.html Then there's the wiki page: https://wiki.freebsd.org/SuspendResume which leads to some more bits, lots more scattered through -acpi and -laptop over the time. There used to be lots of useful per-laptop snippets in the FLCL (freebsd laptop compatibility list) which sadly disappeared last year, but I just googled up an archive of it at http://archive.today/CVo46 latest from mid-2013. Ah sorry, spoke too soon, individual pages redirect to eg: http://laptop.bsdgroup.de/freebsd/index.html?action=list_laptop_mfmfid=1 which is still down :( Ian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
Warren Block wbl...@wonkity.com wrote: On Sun, 4 May 2014, Adrian Chadd wrote: The easy-to-run test is sysctl dev.cpu.0.cx_lowest=Cmax and then use stuff. It's that use stuff step that would preferably be automated. Is the failure mode a lockup, or could a program detect problems? The idea is to get lots of feedback, fast. One possible failure mode is that timers tick unreliably which can be detected automatically (in some cases), for example by using the DTrace script timestamp-test.d: http://www.fabiankeil.de/gehacktes/dtrace-timestamp-tests/ It should also be possible to let the kernel do this itself and log an error message and maybe optionally disable Cx states that cause problems: sysctl dev.cpu.0.cx_lowest=Cmax-as-long-as-it-appears-to-be-working Fabian signature.asc Description: PGP signature
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Mon, May 05, 2014 at 04:17:08PM +1000, Ian Smith wrote: On Sun, 4 May 2014 13:51:20 -0700, Adrian Chadd wrote: On 4 May 2014 13:00, Poul-Henning Kamp p...@phk.freebsd.dk wrote: I havn't seen suspend/resume work for ages on my T4xx laptops and as far as I recall it never worked on this T430s at all. I've tested it (-HEAD) on: * T43 * T60 * T60p * T400 * T500 * T420 * X220 I'm actively using the T60, T400 and X220 right now. I can also confirm that suspend/resume works out of the box on my X200 and on several T61 I used with 10.0-RELEASE, even without newcons the T61 woke up. I know you only like working on HEAD, but unless there's API/ABI reasons preventing MFC, it would be great to have 9.3 work in this respect .. my X200 is not useful for purpose if it won't suspend/resume 100% reliably, with USB, and I don't want to run 11 on it, it's needed for developing non-FreeBSD stuff (in freepascal, if that's not a dirty word here :) and for that it needs to be rock solid while travelling from place to place. Tyler Croy got it working on his X200 which did not work for me: http://unethicalblogger.com/2013/12/03/scratchiest-neckbeard-freebsd-x200.html I worked around around this with an el cheapo USB 3.0 PCI-Express card which fits nicely into the card slot and works after every resume. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Sun, 2014-05-04 at 13:51 -0700, Adrian Chadd wrote: I've tested it (-HEAD) on: * T43 * T60 * T60p * T400 * T500 * T420 * X220 I'm actively using the T60, T400 and X220 right now. T520, just works. Has for a while. I suspect disabling firewire and the eSATA port helps quite a bit. sean -arch for this. signature.asc Description: This is a digitally signed message part
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Sunday, May 04, 2014 4:27:38 am Adrian Chadd wrote: Hi, I'd like to propose flipping a few things: * Flipping the default lid state to S3. I think ACPI suspend/resume seems to work well enough these days and I've not met anyone lately who expects the default from their laptop to be stay awake with the lid shut. * Save chip bugs that we should add workarounds for, we should be OK to enter lower sleep states when idling. Flipping this may expose some further crazy driver, platform or timer bugs, but they again likely should be fixed. what do people think? I think the lid switch thing is premature. Even on my X220 I use a devd hook to enable it only when i915drm is loaded as resume doesn't work until that is done. I think the Cmax thing OTOH is probably more appropriate. We have several things place that should mostly DTRT for picking the correct timers to use. The one case I know of recently were some somewhat older systems where the HPET wasn't reliable, but the system chose to use HPET instead of LAPIC becuase the LAPIC was known to stop during C1E, etc. In this case the user just stuck with plain old C1 and forced the LAPIC timer which worked fine. However, it is hard to identify those cases. On modern systems I would expect the LAPIC to work just fine, so this problem will become less and less important as time goes on. -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On 5 May 2014 08:09, John Baldwin j...@freebsd.org wrote: On Sunday, May 04, 2014 4:27:38 am Adrian Chadd wrote: Hi, I'd like to propose flipping a few things: * Flipping the default lid state to S3. I think ACPI suspend/resume seems to work well enough these days and I've not met anyone lately who expects the default from their laptop to be stay awake with the lid shut. * Save chip bugs that we should add workarounds for, we should be OK to enter lower sleep states when idling. Flipping this may expose some further crazy driver, platform or timer bugs, but they again likely should be fixed. what do people think? I think the lid switch thing is premature. Even on my X220 I use a devd hook to enable it only when i915drm is loaded as resume doesn't work until that is done. I think the Cmax thing OTOH is probably more appropriate. We have several things place that should mostly DTRT for picking the correct timers to use. The one case I know of recently were some somewhat older systems where the HPET wasn't reliable, but the system chose to use HPET instead of LAPIC becuase the LAPIC was known to stop during C1E, etc. In this case the user just stuck with plain old C1 and forced the LAPIC timer which worked fine. However, it is hard to identify those cases. On modern systems I would expect the LAPIC to work just fine, so this problem will become less and less important as time goes on. right. I'd rather we start finding more of these sooner rather than later. :-) -a ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Monday, May 05, 2014 12:55:29 pm Adrian Chadd wrote: On 5 May 2014 08:09, John Baldwin j...@freebsd.org wrote: On Sunday, May 04, 2014 4:27:38 am Adrian Chadd wrote: Hi, I'd like to propose flipping a few things: * Flipping the default lid state to S3. I think ACPI suspend/resume seems to work well enough these days and I've not met anyone lately who expects the default from their laptop to be stay awake with the lid shut. * Save chip bugs that we should add workarounds for, we should be OK to enter lower sleep states when idling. Flipping this may expose some further crazy driver, platform or timer bugs, but they again likely should be fixed. what do people think? I think the lid switch thing is premature. Even on my X220 I use a devd hook to enable it only when i915drm is loaded as resume doesn't work until that is done. I think the Cmax thing OTOH is probably more appropriate. We have several things place that should mostly DTRT for picking the correct timers to use. The one case I know of recently were some somewhat older systems where the HPET wasn't reliable, but the system chose to use HPET instead of LAPIC becuase the LAPIC was known to stop during C1E, etc. In this case the user just stuck with plain old C1 and forced the LAPIC timer which worked fine. However, it is hard to identify those cases. On modern systems I would expect the LAPIC to work just fine, so this problem will become less and less important as time goes on. right. I'd rather we start finding more of these sooner rather than later. :-) The user in question found this on 9-stable with the existing defaults as the HPET was just plain broken on their system and that was unrelated to Cx states. (Rather, Cx states were only involved because worries about them are why the system chose to use HPET. Had Cx states been enabled by default, they would have had to disable those as well in addition to forcing LAPIC instead of HPET.) -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Sun, 4 May 2014 01:27:38 -0700, Adrian Chadd wrote: Hi, I'd like to propose flipping a few things: * Flipping the default lid state to S3. I think ACPI suspend/resume seems to work well enough these days and I've not met anyone lately who expects the default from their laptop to be stay awake with the lid shut. Meet me; sitting here right now with the X200 lid closed, backlight off, idling but 'working' via ssh. Laptops running as (mostly) headless servers would normally run with lid down - been doing this for years, keeps the cockroaches out, mostly :) Anyway, this would be a very poor default on any machine that didn't resume completely well every time. 'Seems to work well enough' on a still fairly limited range of laptops, I gather. I've yet to get this X200 (on stable/9) to suspend without losing USB - after the _second_ suspend, unlike yours - and besides it's not a big deal to set it to S3 when desired. Maybe an rc.conf knob like 'suspend_on_lid=YES' ono rather than requiring sysctl.conf setting? * Save chip bugs that we should add workarounds for, we should be OK to enter lower sleep states when idling. Flipping this may expose some further crazy driver, platform or timer bugs, but they again likely should be fixed. This seems likely less controversial, and should suit most, probably. An Nate Lawson said often many years ago, we really need some sort of profile mechanism to describe as a package different ACPI and power settings for different brands / models / usage cases, plugins if you like; then 'resumes_reliably' could condition stuff. But I digress .. 2c, and not assuming myself to be any sort of 'average user', Ian what do people think? -a Index: etc/defaults/rc.conf === --- etc/defaults/rc.conf (revision 265255) +++ etc/defaults/rc.conf (working copy) @@ -642,9 +642,9 @@ devfs_set_rulesets= # A list of /mount/dev=ruleset_name settings to # apply (must be mounted already, i.e. fstab(5)) devfs_load_rulesets=YES # Enable to always load the default rulesets -performance_cx_lowest=HIGH # Online CPU idle state +performance_cx_lowest=Cmax # Online CPU idle state performance_cpu_freq=NONE # Online CPU frequency -economy_cx_lowest=HIGH # Offline CPU idle state +economy_cx_lowest=Cmax # Offline CPU idle state economy_cpu_freq=NONE # Offline CPU frequency virecover_enable=YES # Perform housekeeping for the vi(1) editor ugidfw_enable=NO # Load mac_bsdextended(4) rules on boot Index: sys/dev/acpica/acpi.c === --- sys/dev/acpica/acpi.c (revision 265255) +++ sys/dev/acpica/acpi.c (working copy) @@ -620,11 +620,12 @@ /* * Dispatch the default sleep state to devices. The lid switch is set - * to UNKNOWN by default to avoid surprising users. + * to S3 to mirror what everything else iBook and later does. */ sc-acpi_power_button_sx = acpi_sleep_states[ACPI_STATE_S5] ? ACPI_STATE_S5 : ACPI_STATE_UNKNOWN; -sc-acpi_lid_switch_sx = ACPI_STATE_UNKNOWN; +sc-acpi_lid_switch_sx = acpi_sleep_states[ACPI_STATE_S3] ? +ACPI_STATE_S3 : ACPI_STATE_UNKNOWN; sc-acpi_standby_sx = acpi_sleep_states[ACPI_STATE_S1] ? ACPI_STATE_S1 : ACPI_STATE_UNKNOWN; sc-acpi_suspend_sx = acpi_sleep_states[ACPI_STATE_S3] ? ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On May 4, 2014, at 1:27, Adrian Chadd adr...@freebsd.org wrote: * Flipping the default lid state to S3. I think ACPI suspend/resume seems to work well enough these days and I've not met anyone lately who expects the default from their laptop to be stay awake with the lid shut. The sysctl is really just a hack. We should have a much better mechanism for integrating our ACPI with the X11 desktop environments. GNOME/KDE/Mate don't understand our sysctl and get confused easily. You can turn it on by default, but I'm sure ACPI suspend/resume is not working well enough like you say. How many laptops have you tested? For completeness, how many desktops? There are bunch of ports kernel modules that will crash your system if you suspend. VirtualBox is one of them. * Save chip bugs that we should add workarounds for, we should be OK to enter lower sleep states when idling. Flipping this may expose some further crazy driver, platform or timer bugs, but they again likely should be fixed. They are still not fixed. Some of these problems are not in FreeBSD though and I don't expect us to be able to work around them. We should try to identify systems where C3 has surprising effects and blacklist them. -- Rui Paulo ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
In message 20140505011654.o11...@sola.nimnet.asn.au, Ian Smith writes: On Sun, 4 May 2014 01:27:38 -0700, Adrian Chadd wrote: 'Seems to work well enough' on a still fairly limited range of laptops, I gather. I'd say. I havn't seen suspend/resume work for ages on my T4xx laptops and as far as I recall it never worked on this T430s at all. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
[snip] The easy-to-run test is sysctl dev.cpu.0.cx_lowest=Cmax and then use stuff. The problem is that we're not getting anywhere near enough exposure to this kind of stuff because we don't have it on by default and we don't have an active QA group with ridiculous amounts of hardware. So, I'd like to flip it on and then start blacklisting devices that actively don't work in halt states above C1. We're never going to cross this bridge fully if we leave things at C1 out of fear. I'm only suggesting we do this on -HEAD. If it's too scary then we can always flip the default back to C1 for 11.0-RELEASE. -a ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On 4 May 2014 17:53, Warren Block wbl...@wonkity.com wrote: On Sun, 4 May 2014, Adrian Chadd wrote: [snip] The easy-to-run test is sysctl dev.cpu.0.cx_lowest=Cmax and then use stuff. It's that use stuff step that would preferably be automated. Is the failure mode a lockup, or could a program detect problems? The idea is to get lots of feedback, fast. The lack of a general test suite is a bigger problem. :-) -a ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Sun, 4 May 2014 17:25:50 -0700, Adrian Chadd wrote:
[snip]
The easy-to-run test is sysctl dev.cpu.0.cx_lowest=Cmax and then use stuff.
This doesn't work, on stable/9 at least, in that it only sets cpu.0 ..
you need to set sysctl hw.acpi.cpu.cx_lowest - which rather surprised
me, although that's what /etc/rc.d/power_profile has always set. I
guess it's only cpu.0.freq that still sets all CPUs in sync.
Further, rather than
-economy_cx_lowest=HIGH # Offline CPU idle state
+economy_cx_lowest=Cmax # Offline CPU idle state
you could use LOW which already sets it to Cmax, though on 8.2:
lowest_value=`(sysctl -n dev.cpu.0.cx_supported | \
awk '{ print C split($0, a) }' -) 2 /dev/null`
I'm not sure what the point of setting cx_lowest to C8 is on a machine
where lowest cx_supported is C3, but it seems to do no harm on mine.
Where does C8 come from anyway? Is that the lowest on any known
hardware, or the lowest the ACPI spec supports?
root@x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C3
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C3
dev.cpu.0.cx_usage: 0.00% 0.79% 99.20% last 35us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C3
dev.cpu.1.cx_usage: 0.08% 1.59% 98.32% last 62us
root@x200:~ # sysctl dev.cpu.0.cx_lowest=Cmax
dev.cpu.0.cx_lowest: C3 - C8
root@x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C3
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_usage: 0.00% 5.66% 94.33% last 73us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C3
dev.cpu.1.cx_usage: 0.07% 1.91% 98.01% last 2us
root@x200:~ # sysctl dev.cpu.1.cx_lowest=C2
dev.cpu.1.cx_lowest: C3 - C2
root@x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C3
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_usage: 0.00% 0.19% 99.80% last 474us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C2
dev.cpu.1.cx_usage: 3.47% 96.52% 0.00% last 1us
root@x200:~ # sysctl hw.acpi.cpu.cx_lowest=Cmax
hw.acpi.cpu.cx_lowest: C3 - C8
root@x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C8
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_usage: 0.00% 3.05% 96.94% last 351us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C8
dev.cpu.1.cx_usage: 0.00% 7.05% 92.94% last 2us
I've long run with C3 in AC power mode without issue, but don't know if
that's true for all machines; all yours and mine are Thinkpads!
The problem is that we're not getting anywhere near enough exposure to
this kind of stuff because we don't have it on by default and we don't
have an active QA group with ridiculous amounts of hardware.
So, I'd like to flip it on and then start blacklisting devices that
actively don't work in halt states above C1. We're never going to
cross this bridge fully if we leave things at C1 out of fear.
I'm only suggesting we do this on -HEAD. If it's too scary then we can
always flip the default back to C1 for 11.0-RELEASE.
Yeah, I think this likely uncontroversial - unlike lid state S3 - and I
don't recall hearing about machines that fail below C1 if lower states
are shown as available. As you say, this might shake these out.
But where would you put such a blacklist? Someting like USB quirks?
cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On 4 May 2014 22:18, Ian Smith smi...@nimnet.asn.au wrote:
On Sun, 4 May 2014 17:25:50 -0700, Adrian Chadd wrote:
[snip]
The easy-to-run test is sysctl dev.cpu.0.cx_lowest=Cmax and then use
stuff.
This doesn't work, on stable/9 at least, in that it only sets cpu.0 ..
you need to set sysctl hw.acpi.cpu.cx_lowest - which rather surprised
me, although that's what /etc/rc.d/power_profile has always set. I
guess it's only cpu.0.freq that still sets all CPUs in sync.
Yeah. Sorry, my mistake. One should just do the rc.conf change and reboot.
Further, rather than
-economy_cx_lowest=HIGH # Offline CPU idle state
+economy_cx_lowest=Cmax # Offline CPU idle state
you could use LOW which already sets it to Cmax, though on 8.2:
lowest_value=`(sysctl -n dev.cpu.0.cx_supported | \
awk '{ print C split($0, a) }' -) 2 /dev/null`
I'm not sure what the point of setting cx_lowest to C8 is on a machine
where lowest cx_supported is C3, but it seems to do no harm on mine.
Well, it's just convenient to set it to that. It's the same as Cmax.
Where does C8 come from anyway? Is that the lowest on any known
hardware, or the lowest the ACPI spec supports?
Not sure. It's what's chosen when you use Cmax. :-)
root@x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C3
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C3
dev.cpu.0.cx_usage: 0.00% 0.79% 99.20% last 35us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C3
dev.cpu.1.cx_usage: 0.08% 1.59% 98.32% last 62us
root@x200:~ # sysctl dev.cpu.0.cx_lowest=Cmax
dev.cpu.0.cx_lowest: C3 - C8
root@x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C3
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_usage: 0.00% 5.66% 94.33% last 73us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C3
dev.cpu.1.cx_usage: 0.07% 1.91% 98.01% last 2us
root@x200:~ # sysctl dev.cpu.1.cx_lowest=C2
dev.cpu.1.cx_lowest: C3 - C2
root@x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C3
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_usage: 0.00% 0.19% 99.80% last 474us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C2
dev.cpu.1.cx_usage: 3.47% 96.52% 0.00% last 1us
root@x200:~ # sysctl hw.acpi.cpu.cx_lowest=Cmax
hw.acpi.cpu.cx_lowest: C3 - C8
root@x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C8
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_usage: 0.00% 3.05% 96.94% last 351us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C8
dev.cpu.1.cx_usage: 0.00% 7.05% 92.94% last 2us
I've long run with C3 in AC power mode without issue, but don't know if
that's true for all machines; all yours and mine are Thinkpads!
I've only had problems on an older Atom. That I'll bring with me to
bsdcan to finally show mav. Linux has had the same problem with this
particular Atom and timekeeping. ;(
The problem is that we're not getting anywhere near enough exposure to
this kind of stuff because we don't have it on by default and we don't
have an active QA group with ridiculous amounts of hardware.
So, I'd like to flip it on and then start blacklisting devices that
actively don't work in halt states above C1. We're never going to
cross this bridge fully if we leave things at C1 out of fear.
I'm only suggesting we do this on -HEAD. If it's too scary then we can
always flip the default back to C1 for 11.0-RELEASE.
Yeah, I think this likely uncontroversial - unlike lid state S3 - and I
don't recall hearing about machines that fail below C1 if lower states
are shown as available. As you say, this might shake these out.
But where would you put such a blacklist? Someting like USB quirks?
I'm not sure yet. Maybe make it userland and as part of the rc / power
scripts. That way Cmax gets turned into C1.
-a
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
In message CAJ-Vmo=actmb-tavz86gbwenit5oe1n8ju7+pw55xazcwg3...@mail.gmail.com , Adrian Chadd writes: I havn't seen suspend/resume work for ages on my T4xx laptops and as far as I recall it never worked on this T430s at all. I've tested it (-HEAD) on: * T43 * T60 * T60p * T400 * T500 * T420 * X220 I'm building head as we speak, I'll test once it's done. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
