Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
The following reply was made to PR i386/135447; it has been noted by GNATS. From: Dmitry Kubov d...@garant.ru To: Alexander Motin m...@freebsd.org Cc: Andriy Gapon a...@freebsd.org, j...@freebsd.org, bug-followup bug-follo...@freebsd.org Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported Date: Fri, 24 Sep 2010 11:18:01 +0400 Is it possible to stick running threads to same CPU core for longer time to avoid C-states latencies penalty? ___ 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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
Synopsis: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported State-Changed-From-To: feedback-closed State-Changed-By: avg State-Changed-When: Fri Sep 24 07:35:27 UTC 2010 State-Changed-Why: The issue as described in this PR is not present in stable/8. ACPI in stable/7 is not going to be updated. In stable/8 C3 is reported but is never used in default configuration, because processor never sleeps long enough to C3 state with that long enter/exit delay. The reporter is tuning his system for optimal performance. http://www.freebsd.org/cgi/query-pr.cgi?pr=135447 ___ 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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
The following reply was made to PR i386/135447; it has been noted by GNATS. From: Alexander Motin m...@freebsd.org To: Dmitry Kubov d...@garant.ru Cc: Andriy Gapon a...@freebsd.org, j...@freebsd.org, bug-followup bug-follo...@freebsd.org Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported Date: Thu, 23 Sep 2010 15:34:23 +0300 Dmitry Kubov wrote: It would be interesting to repeat same test if you updated to 8-STABLE or at least apply patch from SVN rev 209897 on 2010-07-11 11:58:46Z. New system: CPU: Intel(R) Xeon(R) CPU X5680 @ 3.33GHz (.47-MHz K8-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs FreeBSD/SMP: 2 package(s) x 6 core(s) HT disabled in BIOS. This CPU has only 266MHz TurboBoost speedup. And some part of it (probably half) could be enabled all the time. This benefit still could be overweighted by C-states latencies penalty. It could be interesting to test some other workloads, like compilation with different number of threads. Note /3334 difference: TurboBoost disabled: dev.cpu.0.freq: dev.cpu.0.freq_levels: /13 3200/117000 3067/105000 2933/94000 2800/85000 2667/76000 2533/68000 2400/61000 2267/54000 2133/48000 2000/43000 1867/39000 17 33/35000 1600/32000 1400/28000 1200/24000 1000/2 800/16000 600/12000 400/8000 200/4000 dev.est.0.freq_settings: /13 3200/117000 3067/105000 2933/94000 2800/850 00 2667/76000 2533/68000 2400/61000 2267/54000 2133/48000 2000/43000 1867/39000 1733/35000 1600/32000 TurboBoost enabled: dev.cpu.0.freq: 3334 dev.cpu.0.freq_levels: 3334/143000 3200/117000 3067/105000 2933/94000 2800/85000 2667/76000 2533/68000 2400/61000 2267/54000 2133/48000 2000/43000 1867/39000 17 33/35000 1600/32000 1400/28000 1200/24000 1000/2 800/16000 600/12000 400/8000 200/4000 dev.est.0.freq_settings: 3334/143000 /13 3200/117000 3067/105000 2933/94 000 2800/85000 2667/76000 2533/68000 2400/61000 2267/54000 2133/48000 2000/43000 1867/39000 1733/35000 1600/32000 Intel writes that BIOS may report additional P-state with 1MHz difference, to allow OS to control TurboBoost. It's just cpufreq subsystem behavior/limitation to drop very close frequencies. Actually I am not sure how this additional P-state could be used, except for testing. In short: no 60% disk io performance drop in 8.1-STABLE. Other tests give same results like 8.1-RELEASE, 5% average cpu performance drop. Disk performance fix is reasonable. Some recent improvements in 9-CURRENT should improve it even more. What's about ubench - try some different load. -- Alexander Motin ___ 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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
The following reply was made to PR i386/135447; it has been noted by GNATS. From: Dmitry Kubov d...@garant.ru To: Alexander Motin m...@freebsd.org Cc: Andriy Gapon a...@freebsd.org, j...@freebsd.org, bug-followup bug-follo...@freebsd.org Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported Date: Thu, 23 Sep 2010 16:48:18 +0400 This CPU has only 266MHz TurboBoost speedup. And some part of it (probably half) could be enabled all the time. This benefit still could be overweighted by C-states latencies penalty. It could be interesting to test some other workloads, like compilation with different number of threads. Actually tested 8.1-RELEASE with both TurboBoost options in BIOS: TurboBoost OFF Ubench Single CPU: 451935 (0.40s) Ubench Single CPU: 450927 (0.40s) Ubench Single CPU: 450486 (0.40s) TurboBoost ON Ubench Single CPU: 450890 (0.40s) Ubench Single CPU: 450890 (0.40s) Ubench Single CPU: 449926 (0.40s) C-states latencies penalty is reasonable idea. But looks like P0-state not activated at all. What about too high %% for C3 state during heavy load: dev.cpu.0.cx_usage: 0.17% 0.06% 99.75% last 7560us Disk performance fix is reasonable. Some recent improvements in 9-CURRENT should improve it even more. What's about ubench - try some different load. Can you suggest other CPU only benchmark? make -j 16 buildworld can't load all cores, can't see less than 11% idle ___ 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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
The following reply was made to PR i386/135447; it has been noted by GNATS. From: Alexander Motin m...@freebsd.org To: Dmitry Kubov d...@garant.ru Cc: Andriy Gapon a...@freebsd.org, j...@freebsd.org, bug-followup bug-follo...@freebsd.org Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported Date: Thu, 23 Sep 2010 16:01:09 +0300 Dmitry Kubov wrote: This CPU has only 266MHz TurboBoost speedup. And some part of it (probably half) could be enabled all the time. This benefit still could be overweighted by C-states latencies penalty. It could be interesting to test some other workloads, like compilation with different number of threads. Actually tested 8.1-RELEASE with both TurboBoost options in BIOS: TurboBoost OFF Ubench Single CPU: 451935 (0.40s) Ubench Single CPU: 450927 (0.40s) Ubench Single CPU: 450486 (0.40s) TurboBoost ON Ubench Single CPU: 450890 (0.40s) Ubench Single CPU: 450890 (0.40s) Ubench Single CPU: 449926 (0.40s) C-states latencies penalty is reasonable idea. But looks like P0-state not activated at all. Try to kill powerd and manually set highest CPU frequency. 0.40s test time looks a bit suspicious, as powerd may just not react in time to set P0 state. What about too high %% for C3 state during heavy load: dev.cpu.0.cx_usage: 0.17% 0.06% 99.75% last 7560us It's not really strange. These numbers count number of enters into each state. So when CPU is completely bust - they won't be updated. Main case when C1 state should be actively used/counted is loads with high interrupt rate or heavy context switching, such as disk I/O or network load. Disk performance fix is reasonable. Some recent improvements in 9-CURRENT should improve it even more. What's about ubench - try some different load. Can you suggest other CPU only benchmark? make -j 16 buildworld can't load all cores, can't see less than 11% idle I think it's not the main goal to completely load all CPUs. But this test is realistic and has really usable result. -- Alexander Motin ___ 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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
The following reply was made to PR i386/135447; it has been noted by GNATS. From: Dmitry Kubov d...@garant.ru To: Alexander Motin m...@freebsd.org Cc: Andriy Gapon a...@freebsd.org, j...@freebsd.org, bug-followup bug-follo...@freebsd.org Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported Date: Thu, 23 Sep 2010 17:06:22 +0400 Try to kill powerd and manually set highest CPU frequency. 0.40s test time looks a bit suspicious, as powerd may just not react in time to set P0 state. powerd does not enabled. Where/how set highest CPU frequency? ___ 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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
The following reply was made to PR i386/135447; it has been noted by GNATS. From: Dmitry Kubov d...@garant.ru To: Alexander Motin m...@freebsd.org Cc: Andriy Gapon a...@freebsd.org, j...@freebsd.org, bug-followup bug-follo...@freebsd.org Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported Date: Thu, 23 Sep 2010 17:10:05 +0400 Try to kill powerd and manually set highest CPU frequency. 0.40s test time looks a bit suspicious, as powerd may just not react in time to set P0 state. powerd does not enabled. Where/how set highest CPU frequency? sysctl dev.cpu |grep freq # sysctl dev.cpu |grep freq dev.cpu.0.freq: 3334 dev.cpu.0.freq_levels: 3334/143000 3200/117000 3067/105000 2933/94000 2800/85000 2667/76000 2533/68000 2400/61000 2267/54000 2133/48000 2000/43000 1867/39000 1733/35000 1600/32000 1400/28000 1200/24000 1000/2 800/16000 600/12000 400/8000 200/4000 So its already max freq. ___ 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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
The following reply was made to PR i386/135447; it has been noted by GNATS. From: Dmitry Kubov d...@garant.ru To: Alexander Motin m...@freebsd.org Cc: Andriy Gapon a...@freebsd.org, j...@freebsd.org, bug-follo...@freebsd.org Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported Date: Tue, 21 Sep 2010 15:12:52 +0400 Ok, I am able to activate C3 state after loader.conf tweaks. According to http://www.intel.com/technology/turboboost/ Intel Turbo Boost Technology is activated when the Operating System (OS) requests the highest processor performance state (P0). I have no clue about P0 state activation on FreeBSD. ___ 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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
As for fix its web-PR failure to treat any attach as fix. # acpidump -dt SS1026T-URF.asl acpidump: RSDT entry 5 (sig OEMB) is corrupt # file is hosted at http://ss1026t-urf.pastebin.com/gfxb8t9U dmesg with ACPI debugging output will take some time, system is in production environment. ___ 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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
The following reply was made to PR i386/135447; it has been noted by GNATS. From: Andriy Gapon a...@freebsd.org To: Dmitry Kubov d...@garant.ru Cc: j...@freebsd.org, bru...@freebsd.org, bug-follo...@freebsd.org Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported Date: Mon, 20 Sep 2010 17:48:07 +0300 on 20/09/2010 17:41 Dmitry Kubov said the following: on 20/09/2010 17:06 Dmitry Kubov said the following: Maybe I need some kind of powerd running? No any info about TurboBoost tune on FreeBSD. So you do have the levels reported in cx_supported? This is not what you attached to the PR. And this is not what I tried to debug. I am not sure what changed in your environment, but you should have said that you have the those levels reported and not wasted my time on this. Please ask the above on questi...@. Change is 7.2 upgraded to 8.1 Great! That was a wise decision on your part. But you should have told us/me that (e.g. followed up to your own PR). OK, now you can enable use of lower Cx states via hw.acpi.cpu.cx_lowest sysctl and the PR can be closed. -- Andriy Gapon ___ 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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
The following reply was made to PR i386/135447; it has been noted by GNATS. From: Dmitry Kubov d...@garant.ru To: Andriy Gapon a...@freebsd.org Cc: j...@freebsd.org, bru...@freebsd.org, bug-follo...@freebsd.org Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported Date: Mon, 20 Sep 2010 18:41:08 +0400 on 20/09/2010 17:06 Dmitry Kubov said the following: Maybe I need some kind of powerd running? No any info about TurboBoost tune on FreeBSD. So you do have the levels reported in cx_supported? This is not what you attached to the PR. And this is not what I tried to debug. I am not sure what changed in your environment, but you should have said that you have the those levels reported and not wasted my time on this. Please ask the above on questi...@. Change is 7.2 upgraded to 8.1 ___ 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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
The following reply was made to PR i386/135447; it has been noted by GNATS.
From: Andriy Gapon a...@freebsd.org
To: Dmitry Kubov d...@garant.ru, Alexander Motin m...@freebsd.org
Cc: j...@freebsd.org, bug-follo...@freebsd.org
Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new
features not supported
Date: Mon, 20 Sep 2010 18:11:20 +0300
on 20/09/2010 17:54 Dmitry Kubov said the following:
dev.cpu.7.cx_supported: C1/3 C2/205 C3/245
Note these^^^^^^
dev.cpu.7.cx_lowest: C3
dev.cpu.7.cx_usage: 100.00% 0.00% 0.00% last 500us
And this --^
C2/C3 not used at all
And now there is this code in acpi_cpu.c:
/* Find the lowest state that has small enough latency. */
cx_next_idx = 0;
for (i = sc-cpu_cx_lowest; i = 0; i--) {
if (sc-cpu_cx_states[i].trans_lat * 3 = sc-cpu_prev_sleep) {
cx_next_idx = i;
break;
}
}
205 * 3 and 245 * 3 are both greater than 500, so this is the reason why they
are
never entered.
Perhaps Alexander can give some advice here.
--
Andriy Gapon
___
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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
The following reply was made to PR i386/135447; it has been noted by GNATS. From: Dmitry Kubov d...@garant.ru To: Andriy Gapon a...@freebsd.org Cc: Alexander Motin m...@freebsd.org, j...@freebsd.org, bug-follo...@freebsd.org Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported Date: Mon, 20 Sep 2010 19:29:12 +0400 This is a multi-part message in MIME format. --000706080807090502020908 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit 205 * 3 and 245 * 3 are both greater than 500, so this is the reason why they are never entered. Perhaps Alexander can give some advice here. Looks like I can simply update src to 8-stable? Revision *1.79.2.10*: download http://www.freebsd.org/cgi/cvsweb.cgi/%7Echeckout%7E/src/sys/dev/acpica/acpi_cpu.c?rev=1.79.2.10;content-type=text%2Fplain - view: text http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c?rev=1.79.2.10;content-type=text%2Fplain, markup http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c?rev=1.79.2.10;content-type=text%2Fx-cvsweb-markup, annotated http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c?annotate=1.79.2.10 - select for diffs http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c?r1=1.79.2.10#rev1.79.2.10 /Mon Sep 20 05:39:50 2010 UTC/ (9 hours, 47 minutes ago) by /avg/ Branches: RELENG_8 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c?only_with_tag=RELENG_8 Diff to: previous 1.79.2.9: preferred http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c.diff?r1=1.79.2.9;r2=1.79.2.10, colored http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c.diff?r1=1.79.2.9;r2=1.79.2.10;f=h; branchpoint 1.79: preferred http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c.diff?r1=1.79;r2=1.79.2.10, colored http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c.diff?r1=1.79;r2=1.79.2.10;f=h Changes since revision 1.79.2.9: +1 -9 lines SVN rev 212887 on 2010-09-20 05:39:50Z by avg MFC r212549: acpi_cpu: do not apply P_LVLx_LAT rules to latencies returned by _CST --000706080807090502020908 Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: 8bit !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head meta content=text/html; charset=KOI8-R http-equiv=Content-Type title/title /head body bgcolor=#ff text=#00 span id=IDstIDbr br /span blockquote cite=mid:4c977998.1000...@freebsd.org type=cite pre wrap=205 * 3 and 245 * 3 are both greater than 500, so this is the reason why they are never entered. Perhaps Alexander can give some advice here. /pre /blockquote br br Looks like I can simply update src to 8-stable?br br Revision b1.79.2.10/b: a href=http://www.freebsd.org/cgi/cvsweb.cgi/%7Echeckout%7E/src/sys/dev/acpica/acpi_cpu.c?rev=1.79.2.10;content-type=text%2Fplain; class=download-linkdownload/a - view: a href=http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c?rev=1.79.2.10;content-type=text%2Fplain; class=display-linktext/a, a href=http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c?rev=1.79.2.10;content-type=text%2Fx-cvsweb-markup; class=display-linkmarkup/a, a href=http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c?annotate=1.79.2.10;annotated/a - a href=http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c?r1=1.79.2.10#rev1.79.2.10;selectfordiffs/abr iMon Sep 20 05:39:50 2010 UTC/i (9 hours, 47 minutes ago) by iavg/ibr Branches: a href=http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c?only_with_tag=RELENG_8;RELENG_8/abr Diff to: previous 1.79.2.9: a href=http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c.diff?r1=1.79.2.9;r2=1.79.2.10;preferred/a, a href=http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c.diff?r1=1.79.2.9;r2=1.79.2.10;f=h;colored/a; branchpoint 1.79: a href=http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c.diff?r1=1.79;r2=1.79.2.10;preferred/a, a href=http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_cpu.c.diff?r1=1.79;r2=1.79.2.10;f=h;colored/abr Changes since revision 1.79.2.9: +1 -9 linesbr pre class=logSVN rev 212887 on 2010-09-20 05:39:50Z by avg MFC r212549: acpi_cpu: do not apply P_LVLx_LAT rules to latencies returned by _CST /pre br /body /html --000706080807090502020908-- ___ 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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
Synopsis: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported State-Changed-From-To: closed-open State-Changed-By: brucec State-Changed-When: Sun Sep 12 10:35:23 UTC 2010 State-Changed-Why: This does appear to be a bug, but only in the ACPI code: Hyperthreading isn't guaranteed to give a performance increase for every workload, and TurboBoost is only seen once lower Cx states are enabled. Responsible-Changed-From-To: brucec-freebsd-acpi Responsible-Changed-By: brucec Responsible-Changed-When: Sun Sep 12 10:35:23 UTC 2010 Responsible-Changed-Why: Over to the acpi list. This appears to be a problem with ACPI on the machine, because C2 and C3 states should probably be available. http://www.freebsd.org/cgi/query-pr.cgi?pr=135447 ___ 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: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
The following reply was made to PR i386/135447; it has been noted by GNATS. From: Andriy Gapon a...@icyb.net.ua To: bug-follo...@freebsd.org, d...@garant.ru Cc: Bruce Cran bru...@freebsd.org Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported Date: Sun, 12 Sep 2010 18:52:14 +0300 First of all, the PR was created improperly - sysctl -a output is in Fix section for some reason. Please don't do that in the future. Second, it's impossible to tell if C2 and C3 states should probably be available unless we see acpidump -dt output and dmesg with ACPI debugging enabled (ACPI_PROCESSOR x ACPI_DB_INFO): http://www.freebsd.org/doc/handbook/acpi-debug.html P.S. That is, generally we expect to see C2 and C3 levels, but not universally. BIOS or BIOS configuration, motherboard peculiarities and OS supported features are among the thing that affect C2+ availability. -- Andriy Gapon ___ 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
