From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 10:16:13 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 504FD106566C for ; Mon, 1 Nov 2010 10:16:13 +0000 (UTC) (envelope-from jt@xoasis.de) Received: from pluto.xoasis.de (pluto.xoasis.de [85.159.14.10]) by mx1.freebsd.org (Postfix) with ESMTP id D94C68FC0A for ; Mon, 1 Nov 2010 10:16:12 +0000 (UTC) Received: from pad (rh2.xoasis.de [194.77.193.180]) (authenticated bits=0) by pluto.xoasis.de (8.13.8/8.13.6) with ESMTP id oA19qBOX022087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 1 Nov 2010 10:52:14 +0100 (CET) (envelope-from jt@xoasis.de) To: freebsd-acpi@freebsd.org Content-Disposition: inline From: Joerg Traeger Date: Mon, 1 Nov 2010 11:52:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011011052.11084.jt@xoasis.de> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (pluto.xoasis.de [85.159.14.10]); Mon, 01 Nov 2010 10:52:14 +0100 (CET) X-XOASIS-EmailScanner-Information: X-XOASIS-EmailScanner: Found to be clean X-XOASIS-EmailScanner-From: jt@xoasis.de Subject: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jt@xoasis.de List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 10:16:13 -0000 Hi, I have got several mainboards with CPUs which appear not to be supportet by est. An error exists: (examle of somewhat older Intel DG45FC with DualCore E5200 and latest BIOS) est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f device_attach: est0 attach returned 6 <---------- p4tcc0: on cpu0 [...] est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f device_attach: est1 attach returned 6 p4tcc1: on cpu1 Searching the net I found several hints this CPU (Intel DualCore E5200) _is_ supported by EST and the voltage is being reduced in idle states like intended. So it looks like there are more things which might break success using est for me. Can you explain what may be a reason for this problem? In the past it was about hardcoding cpu data about voltages into the source but as I know this is not the case anymore but ACPI is involved. Is the BIOS likely to be the reason or is it an ignored CPU stepping or...? Same happens with the new CPU Intel Atom N550 on a Jetway board called NC9c-550-LF. est does not attach and some watts are wasted. Thank you! From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 10:53:11 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9773F1065672 for ; Mon, 1 Nov 2010 10:53:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DF0048FC12 for ; Mon, 1 Nov 2010 10:53:10 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA18672; Mon, 01 Nov 2010 12:53:04 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PCs0e-0002sQ-H0; Mon, 01 Nov 2010 12:53:04 +0200 Message-ID: <4CCE9C0F.6060907@icyb.net.ua> Date: Mon, 01 Nov 2010 12:53:03 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: jt@xoasis.de References: <201011011052.11084.jt@xoasis.de> In-Reply-To: <201011011052.11084.jt@xoasis.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 10:53:11 -0000 on 01/11/2010 11:52 Joerg Traeger said the following: > Hi, > > I have got several mainboards with CPUs which appear not to be > supportet by est. An error exists: > > (examle of somewhat older Intel DG45FC with DualCore E5200 and latest BIOS) > > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f > device_attach: est0 attach returned 6 <---------- Do you have ACPI enabled? > p4tcc0: on cpu0 > [...] > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > > Searching the net I found several hints this CPU (Intel DualCore E5200) _is_ > supported by EST and the voltage is being reduced in idle states like > intended. > So it looks like there are more things which might break success using est for > me. Can you explain what may be a reason for this problem? In the past it was > about hardcoding cpu data about voltages into the source but as I know this > is not the case anymore but ACPI is involved. > Is the BIOS likely to be the reason or is it an ignored CPU stepping or...? > > Same happens with the new CPU Intel Atom N550 on a Jetway board called > NC9c-550-LF. est does not attach and some watts are wasted. > > Thank you! -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 11:06:50 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA38F10656A7 for ; Mon, 1 Nov 2010 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BCE628FC17 for ; Mon, 1 Nov 2010 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA1B6o6I019075 for ; Mon, 1 Nov 2010 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA1B6ovu019073 for freebsd-acpi@FreeBSD.org; Mon, 1 Nov 2010 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Nov 2010 11:06:50 GMT Message-Id: <201011011106.oA1B6ovu019073@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o amd64/144551 acpi [acpi] ACPI issues on SuperMicro X7SPA-H o i386/144045 acpi [acpi] [panic] kernel trap with acpi enabled o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142263 acpi [acpi] ACPI regression on Asus K8N7-E deluxe motherboa o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o amd64/140751 acpi [acpi] BIOS resource allocation and FreeBSD ACPI in TO o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o bin/137053 acpi [hang] FreeBSD 8.0 BETA2Compaq Mini 700 locks on boot o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/135070 acpi [acpi] [patch] BIOS resource allocation and FreeBSD AC o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin o amd64/121439 acpi [boot] Installation of FreeBSD 7.0 fails: ACPI problem o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 56 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 12:25:44 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14C52106564A for ; Mon, 1 Nov 2010 12:25:44 +0000 (UTC) (envelope-from jt@xoasis.de) Received: from pluto.xoasis.de (pluto.xoasis.de [85.159.14.10]) by mx1.freebsd.org (Postfix) with ESMTP id 99AC88FC1A for ; Mon, 1 Nov 2010 12:25:43 +0000 (UTC) Received: from pad (rh1.xoasis.de [194.77.193.179] (may be forged)) (authenticated bits=0) by pluto.xoasis.de (8.13.8/8.13.6) with ESMTP id oA1CPbSG023216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Nov 2010 13:25:39 +0100 (CET) (envelope-from jt@xoasis.de) From: Joerg Traeger To: Andriy Gapon Date: Mon, 1 Nov 2010 14:25:36 +0200 User-Agent: KMail/1.9.10 References: <201011011052.11084.jt@xoasis.de> <4CCE9C0F.6060907@icyb.net.ua> In-Reply-To: <4CCE9C0F.6060907@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201011011325.36879.jt@xoasis.de> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (pluto.xoasis.de [85.159.14.10]); Mon, 01 Nov 2010 13:25:40 +0100 (CET) X-XOASIS-EmailScanner-Information: X-XOASIS-EmailScanner: Found to be clean X-XOASIS-EmailScanner-From: jt@xoasis.de Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jt@xoasis.de List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 12:25:44 -0000 On Monday 01 November 2010, Andriy Gapon wrote: > on 01/11/2010 11:52 Joerg Traeger said the following: > > Hi, > > > > I have got several mainboards with CPUs which appear not to be > > supportet by est. An error exists: > > > > (examle of somewhat older Intel DG45FC with DualCore E5200 and latest > > BIOS) > > > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f > > device_attach: est0 attach returned 6 <---------- > > Do you have ACPI enabled? Yes, sure it is enabled. debug.acpi.suspend_bounce: 0 debug.acpi.reset_clock: 1 debug.acpi.do_powerstate: 1 debug.acpi.interpreter_slack: 1 debug.acpi.enable_debug_objects: 0 debug.acpi.acpi_ca_version: 20100331 debug.acpi.ec.timeout: 750 debug.acpi.ec.polled: 0 debug.acpi.ec.burst: 0 debug.acpi.batt.batt_sleep_ms: 0 debug.acpi.resume_beep: 0 hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: NONE hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 machdep.acpi_timer_freq: 3579545 machdep.acpi_root: 984000 machdep.idle: acpi machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, dev.acpi.0.%desc: INTEL DG45FC dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.PCI0.MCH_ dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C01 _UID=10 dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_sysresource.1.%desc: System Resource dev.acpi_sysresource.1.%driver: acpi_sysresource dev.acpi_sysresource.1.%location: handle=\_SB_.PCI0.SBRG.SIO1 dev.acpi_sysresource.1.%pnpinfo: _HID=PNP0C02 _UID=46 dev.acpi_sysresource.1.%parent: acpi0 dev.acpi_sysresource.2.%desc: System Resource dev.acpi_sysresource.2.%driver: acpi_sysresource dev.acpi_sysresource.2.%location: handle=\_SB_.PCI0.SBRG.RMSC dev.acpi_sysresource.2.%pnpinfo: _HID=PNP0C02 _UID=16 dev.acpi_sysresource.2.%parent: acpi0 dev.acpi_sysresource.3.%desc: System Resource dev.acpi_sysresource.3.%driver: acpi_sysresource dev.acpi_sysresource.3.%location: handle=\_SB_.PCI0.ICH9 dev.acpi_sysresource.3.%pnpinfo: _HID=PNP0C01 _UID=455 dev.acpi_sysresource.3.%parent: acpi0 dev.acpi_sysresource.4.%desc: System Resource dev.acpi_sysresource.4.%driver: acpi_sysresource dev.acpi_sysresource.4.%location: handle=\_SB_.RMEM dev.acpi_sysresource.4.%pnpinfo: _HID=PNP0C01 _UID=1 dev.acpi_sysresource.4.%parent: acpi0 dev.acpi_sysresource.5.%desc: System Resource dev.acpi_sysresource.5.%driver: acpi_sysresource dev.acpi_sysresource.5.%location: handle=\OMSC dev.acpi_sysresource.5.%pnpinfo: _HID=PNP0C02 _UID=3601 dev.acpi_sysresource.5.%parent: acpi0 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.cpu.0.%parent: acpi0 dev.cpu.1.%parent: acpi0 dev.pci_link.0.%parent: acpi0 dev.pci_link.1.%parent: acpi0 dev.pci_link.2.%parent: acpi0 dev.pci_link.3.%parent: acpi0 dev.pci_link.4.%parent: acpi0 dev.pci_link.5.%parent: acpi0 dev.pci_link.6.%parent: acpi0 dev.pci_link.7.%parent: acpi0 dev.pcib.0.%parent: acpi0 dev.acpi_button.0.%desc: Power Button dev.acpi_button.0.%driver: acpi_button dev.acpi_button.0.%location: handle=\_SB_.PWRB dev.acpi_button.0.%pnpinfo: _HID=PNP0C0C _UID=170 dev.acpi_button.0.%parent: acpi0 dev.acpi_button.0.wake: 1 dev.uart.0.%parent: acpi0 dev.atdma.0.%parent: acpi0 dev.attimer.0.%parent: acpi0 dev.atrtc.0.%parent: acpi0 dev.fpupnp.0.%parent: acpi0 > > > p4tcc0: on cpu0 > > [...] > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f > > device_attach: est1 attach returned 6 > > p4tcc1: on cpu1 > > > > Searching the net I found several hints this CPU (Intel DualCore E5200) > > _is_ supported by EST and the voltage is being reduced in idle states > > like intended. > > So it looks like there are more things which might break success using > > est for me. Can you explain what may be a reason for this problem? In the > > past it was about hardcoding cpu data about voltages into the source but > > as I know this is not the case anymore but ACPI is involved. > > Is the BIOS likely to be the reason or is it an ignored CPU stepping > > or...? > > > > Same happens with the new CPU Intel Atom N550 on a Jetway board called > > NC9c-550-LF. est does not attach and some watts are wasted. > > > > Thank you! -- If you say that you can't, then I shall reply, Parsley, sage, rosemary and thyme From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 12:27:27 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 649D1106566B for ; Mon, 1 Nov 2010 12:27:27 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AEEAB8FC0A for ; Mon, 1 Nov 2010 12:27:26 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA20817; Mon, 01 Nov 2010 14:27:22 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CCEB229.9030907@icyb.net.ua> Date: Mon, 01 Nov 2010 14:27:21 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: jt@xoasis.de References: <201011011052.11084.jt@xoasis.de> <4CCE9C0F.6060907@icyb.net.ua> <201011011325.36879.jt@xoasis.de> In-Reply-To: <201011011325.36879.jt@xoasis.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 12:27:27 -0000 on 01/11/2010 14:25 Joerg Traeger said the following: > On Monday 01 November 2010, Andriy Gapon wrote: >> on 01/11/2010 11:52 Joerg Traeger said the following: >>> Hi, >>> >>> I have got several mainboards with CPUs which appear not to be >>> supportet by est. An error exists: >>> >>> (examle of somewhat older Intel DG45FC with DualCore E5200 and latest >>> BIOS) >>> >>> est0: on cpu0 >>> est: CPU supports Enhanced Speedstep, but is not recognized. >>> est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f >>> device_attach: est0 attach returned 6 <---------- >> >> Do you have ACPI enabled? > > Yes, sure it is enabled. Can you upload your acpidump -dt output somewhere and provide a link? Thanks. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 12:41:53 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0F681065675 for ; Mon, 1 Nov 2010 12:41:53 +0000 (UTC) (envelope-from jt@xoasis.de) Received: from pluto.xoasis.de (pluto.xoasis.de [85.159.14.10]) by mx1.freebsd.org (Postfix) with ESMTP id 87B788FC14 for ; Mon, 1 Nov 2010 12:41:53 +0000 (UTC) Received: from pad (rg.xoasis.de [194.77.193.178]) (authenticated bits=0) by pluto.xoasis.de (8.13.8/8.13.6) with ESMTP id oA1CflGD023343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Nov 2010 13:41:49 +0100 (CET) (envelope-from jt@xoasis.de) From: Joerg Traeger To: Andriy Gapon Date: Mon, 1 Nov 2010 14:41:46 +0200 User-Agent: KMail/1.9.10 References: <201011011052.11084.jt@xoasis.de> <201011011325.36879.jt@xoasis.de> <4CCEB229.9030907@icyb.net.ua> In-Reply-To: <4CCEB229.9030907@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201011011341.46906.jt@xoasis.de> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (pluto.xoasis.de [85.159.14.10]); Mon, 01 Nov 2010 13:41:49 +0100 (CET) X-XOASIS-EmailScanner-Information: X-XOASIS-EmailScanner: Found to be clean X-XOASIS-EmailScanner-From: jt@xoasis.de Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jt@xoasis.de List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 12:41:54 -0000 On Monday 01 November 2010, Andriy Gapon wrote: > on 01/11/2010 14:25 Joerg Traeger said the following: > > On Monday 01 November 2010, Andriy Gapon wrote: > >> on 01/11/2010 11:52 Joerg Traeger said the following: > >>> Hi, > >>> > >>> I have got several mainboards with CPUs which appear not to be > >>> supportet by est. An error exists: > >>> > >>> (examle of somewhat older Intel DG45FC with DualCore E5200 and latest > >>> BIOS) > >>> > >>> est0: on cpu0 > >>> est: CPU supports Enhanced Speedstep, but is not recognized. > >>> est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f > >>> device_attach: est0 attach returned 6 <---------- > >> > >> Do you have ACPI enabled? > > > > Yes, sure it is enabled. > > Can you upload your acpidump -dt output somewhere and provide a link? You can read the output here: http://xoasis.de/DG45FC_E5200_acpidump.txt I thank you! -- If you say that you can't, then I shall reply, Parsley, sage, rosemary and thyme From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 13:13:08 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD548106566B for ; Mon, 1 Nov 2010 13:13:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 242298FC0C for ; Mon, 1 Nov 2010 13:13:07 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA21701; Mon, 01 Nov 2010 15:13:04 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CCEBCE0.2040308@icyb.net.ua> Date: Mon, 01 Nov 2010 15:13:04 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: jt@xoasis.de References: <201011011052.11084.jt@xoasis.de> <201011011325.36879.jt@xoasis.de> <4CCEB229.9030907@icyb.net.ua> <201011011341.46906.jt@xoasis.de> In-Reply-To: <201011011341.46906.jt@xoasis.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 13:13:08 -0000 on 01/11/2010 14:41 Joerg Traeger said the following: > On Monday 01 November 2010, Andriy Gapon wrote: >> on 01/11/2010 14:25 Joerg Traeger said the following: >>> On Monday 01 November 2010, Andriy Gapon wrote: >>>> on 01/11/2010 11:52 Joerg Traeger said the following: >>>>> Hi, >>>>> >>>>> I have got several mainboards with CPUs which appear not to be >>>>> supportet by est. An error exists: >>>>> >>>>> (examle of somewhat older Intel DG45FC with DualCore E5200 and latest >>>>> BIOS) >>>>> >>>>> est0: on cpu0 >>>>> est: CPU supports Enhanced Speedstep, but is not recognized. >>>>> est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f >>>>> device_attach: est0 attach returned 6 <---------- >>>> >>>> Do you have ACPI enabled? >>> >>> Yes, sure it is enabled. >> >> Can you upload your acpidump -dt output somewhere and provide a link? > > You can read the output here: http://xoasis.de/DG45FC_E5200_acpidump.txt Your BIOS doesn't provide _PSS method for processor objects, so est won't work in general ACPI mode. You can try putting the following into your loader.conf to try using MSRs directly, but I don't know if it would help you (or make things worse): hw.est.msr_info="1" -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 13:36:48 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3D351065693 for ; Mon, 1 Nov 2010 13:36:48 +0000 (UTC) (envelope-from jt@xoasis.de) Received: from pluto.xoasis.de (pluto.xoasis.de [85.159.14.10]) by mx1.freebsd.org (Postfix) with ESMTP id 607D58FC15 for ; Mon, 1 Nov 2010 13:36:47 +0000 (UTC) Received: from pad (rh1.xoasis.de [194.77.193.179] (may be forged)) (authenticated bits=0) by pluto.xoasis.de (8.13.8/8.13.6) with ESMTP id oA1DafU2024391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Nov 2010 14:36:43 +0100 (CET) (envelope-from jt@xoasis.de) From: Joerg Traeger To: Andriy Gapon Date: Mon, 1 Nov 2010 15:36:40 +0200 User-Agent: KMail/1.9.10 References: <201011011052.11084.jt@xoasis.de> <201011011341.46906.jt@xoasis.de> <4CCEBCE0.2040308@icyb.net.ua> In-Reply-To: <4CCEBCE0.2040308@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201011011436.41296.jt@xoasis.de> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (pluto.xoasis.de [85.159.14.10]); Mon, 01 Nov 2010 14:36:44 +0100 (CET) X-XOASIS-EmailScanner-Information: X-XOASIS-EmailScanner: Found to be clean X-XOASIS-EmailScanner-From: jt@xoasis.de Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jt@xoasis.de List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 13:36:49 -0000 On Monday 01 November 2010, Andriy Gapon wrote: > on 01/11/2010 14:41 Joerg Traeger said the following: > > On Monday 01 November 2010, Andriy Gapon wrote: > >> on 01/11/2010 14:25 Joerg Traeger said the following: > >>> On Monday 01 November 2010, Andriy Gapon wrote: > >>>> on 01/11/2010 11:52 Joerg Traeger said the following: > >>>>> Hi, > >>>>> > >>>>> I have got several mainboards with CPUs which appear not to be > >>>>> supportet by est. An error exists: > >>>>> > >>>>> (examle of somewhat older Intel DG45FC with DualCore E5200 and latest > >>>>> BIOS) > >>>>> > >>>>> est0: on cpu0 > >>>>> est: CPU supports Enhanced Speedstep, but is not recognized. > >>>>> est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f > >>>>> device_attach: est0 attach returned 6 <---------- > >>>> > >>>> Do you have ACPI enabled? > >>> > >>> Yes, sure it is enabled. > >> > >> Can you upload your acpidump -dt output somewhere and provide a link? > > > > You can read the output here: http://xoasis.de/DG45FC_E5200_acpidump.txt > > Your BIOS doesn't provide _PSS method for processor objects, so est won't > work in general ACPI mode. > You can try putting the following into your loader.conf to try using MSRs > directly, but I don't know if it would help you (or make things worse): > hw.est.msr_info="1" Est still cannot attach. Nov 1 14:28:10 kiste kernel: est0: on cpu0 Nov 1 14:28:10 kiste kernel: est0: Guessed bus clock (high) of 32 MHz Nov 1 14:28:10 kiste kernel: est0: Guessed bus clock (low) of 416 MHz Nov 1 14:28:10 kiste kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Nov 1 14:28:10 kiste kernel: est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f Nov 1 14:28:10 kiste kernel: device_attach: est0 attach returned 6 Nov 1 14:28:10 kiste kernel: est1: on cpu1 Nov 1 14:28:10 kiste kernel: est1: Guessed bus clock (high) of 32 MHz Nov 1 14:28:10 kiste kernel: est1: Guessed bus clock (low) of 416 MHz Nov 1 14:28:10 kiste kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Nov 1 14:28:10 kiste kernel: est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f Nov 1 14:28:10 kiste kernel: device_attach: est1 attach returned 6 Is there anything else to try or is Intel (the board vendor) just to blame to omit something important? Windows is able to bypass this problem so Intel will never fix this? -- If you say that you can't, then I shall reply, Parsley, sage, rosemary and thyme From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 13:52:12 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3362E106566B for ; Mon, 1 Nov 2010 13:52:12 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE668FC18 for ; Mon, 1 Nov 2010 13:52:11 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA22543; Mon, 01 Nov 2010 15:52:07 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CCEC606.7050207@icyb.net.ua> Date: Mon, 01 Nov 2010 15:52:06 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: jt@xoasis.de References: <201011011052.11084.jt@xoasis.de> <201011011341.46906.jt@xoasis.de> <4CCEBCE0.2040308@icyb.net.ua> <201011011436.41296.jt@xoasis.de> In-Reply-To: <201011011436.41296.jt@xoasis.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 13:52:12 -0000 on 01/11/2010 15:36 Joerg Traeger said the following: > Est still cannot attach. > > Nov 1 14:28:10 kiste kernel: est0: on > cpu0 > Nov 1 14:28:10 kiste kernel: est0: Guessed bus clock (high) of 32 MHz > Nov 1 14:28:10 kiste kernel: est0: Guessed bus clock (low) of 416 MHz > Nov 1 14:28:10 kiste kernel: est: CPU supports Enhanced Speedstep, but is not > recognized. > Nov 1 14:28:10 kiste kernel: est: cpu_vendor GenuineIntel, msr > 61a4c1f06004c1f > Nov 1 14:28:10 kiste kernel: device_attach: est0 attach returned 6 > Nov 1 14:28:10 kiste kernel: est1: on > cpu1 > Nov 1 14:28:10 kiste kernel: est1: Guessed bus clock (high) of 32 MHz > Nov 1 14:28:10 kiste kernel: est1: Guessed bus clock (low) of 416 MHz > Nov 1 14:28:10 kiste kernel: est: CPU supports Enhanced Speedstep, but is not > recognized. > Nov 1 14:28:10 kiste kernel: est: cpu_vendor GenuineIntel, msr > 61a4c1f06004c1f > Nov 1 14:28:10 kiste kernel: device_attach: est1 attach returned 6 > > Is there anything else to try or is Intel (the board vendor) just to blame to > omit something important? > Windows is able to bypass this problem so Intel will never fix this? I am out of ideas. Perhaps other OSes have hardcoded tables for your CPU. You can try searching for that. You can also try some other OS and see what speeds and voltages are reported E(I)ST there. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 16:40:55 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9CB4106564A for ; Mon, 1 Nov 2010 16:40:55 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 403108FC08 for ; Mon, 1 Nov 2010 16:40:54 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA25367; Mon, 01 Nov 2010 18:40:50 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CCEED91.6030205@icyb.net.ua> Date: Mon, 01 Nov 2010 18:40:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: jt@xoasis.de References: <201011011052.11084.jt@xoasis.de> <201011011325.36879.jt@xoasis.de> <4CCEB229.9030907@icyb.net.ua> <201011011341.46906.jt@xoasis.de> <4CCEBCE0.2040308@icyb.net.ua> In-Reply-To: <4CCEBCE0.2040308@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 16:40:56 -0000 on 01/11/2010 15:13 Andriy Gapon said the following: > on 01/11/2010 14:41 Joerg Traeger said the following: >> On Monday 01 November 2010, Andriy Gapon wrote: >>> on 01/11/2010 14:25 Joerg Traeger said the following: >>>> On Monday 01 November 2010, Andriy Gapon wrote: >>>>> on 01/11/2010 11:52 Joerg Traeger said the following: >>>>>> Hi, >>>>>> >>>>>> I have got several mainboards with CPUs which appear not to be >>>>>> supportet by est. An error exists: >>>>>> >>>>>> (examle of somewhat older Intel DG45FC with DualCore E5200 and latest >>>>>> BIOS) >>>>>> >>>>>> est0: on cpu0 >>>>>> est: CPU supports Enhanced Speedstep, but is not recognized. >>>>>> est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f >>>>>> device_attach: est0 attach returned 6 <---------- >>>>> >>>>> Do you have ACPI enabled? >>>> >>>> Yes, sure it is enabled. >>> >>> Can you upload your acpidump -dt output somewhere and provide a link? >> >> You can read the output here: http://xoasis.de/DG45FC_E5200_acpidump.txt > > Your BIOS doesn't provide _PSS method for processor objects, so est won't work in > general ACPI mode. Hmm, it seems that I missed code in your DSDT for dynamically loading SSDT. Could you please provide a link to your boot dmesg? -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 16:54:57 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AA51106566B for ; Mon, 1 Nov 2010 16:54:57 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5E0638FC13 for ; Mon, 1 Nov 2010 16:54:55 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA25534; Mon, 01 Nov 2010 18:54:49 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CCEF0D9.10703@icyb.net.ua> Date: Mon, 01 Nov 2010 18:54:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: jt@xoasis.de References: <201011011052.11084.jt@xoasis.de> <201011011325.36879.jt@xoasis.de> <4CCEB229.9030907@icyb.net.ua> <201011011341.46906.jt@xoasis.de> <4CCEBCE0.2040308@icyb.net.ua> <4CCEED91.6030205@icyb.net.ua> In-Reply-To: <4CCEED91.6030205@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 16:54:57 -0000 on 01/11/2010 18:40 Andriy Gapon said the following: > on 01/11/2010 15:13 Andriy Gapon said the following: >> on 01/11/2010 14:41 Joerg Traeger said the following: >>> You can read the output here: http://xoasis.de/DG45FC_E5200_acpidump.txt >> >> Your BIOS doesn't provide _PSS method for processor objects, so est won't work in >> general ACPI mode. > > Hmm, it seems that I missed code in your DSDT for dynamically loading SSDT. It seems that your BIOS makes it a condition that OS supports the following feature: ACPI_CAP_C1_IO_HALT. FreeBSD doesn't really support it, but you can try adding it to 'features' variable in acpi_cpu_attach() in function in sys/dev/acpica/acpi_cpu.c; look for the following line: sc->cpu_features = ACPI_CAP_SMP_SAME | ACPI_CAP_SMP_SAME_C3; I don't think that should break anything for you, but may improve a thing or two. I'd interested in seeing acpidump -d -t produced after the patching. Thank you. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 17:23:02 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C5F31065679 for ; Mon, 1 Nov 2010 17:23:02 +0000 (UTC) (envelope-from jt@xoasis.de) Received: from pluto.xoasis.de (pluto.xoasis.de [85.159.14.10]) by mx1.freebsd.org (Postfix) with ESMTP id 559FD8FC20 for ; Mon, 1 Nov 2010 17:23:00 +0000 (UTC) Received: from pad (rg.xoasis.de [194.77.193.178]) (authenticated bits=0) by pluto.xoasis.de (8.13.8/8.13.6) with ESMTP id oA1HMsIG026171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Nov 2010 18:22:57 +0100 (CET) (envelope-from jt@xoasis.de) From: Joerg Traeger To: Andriy Gapon Date: Mon, 1 Nov 2010 19:22:53 +0200 User-Agent: KMail/1.9.10 References: <201011011052.11084.jt@xoasis.de> <4CCEBCE0.2040308@icyb.net.ua> <4CCEED91.6030205@icyb.net.ua> In-Reply-To: <4CCEED91.6030205@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201011011822.54279.jt@xoasis.de> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (pluto.xoasis.de [85.159.14.10]); Mon, 01 Nov 2010 18:22:57 +0100 (CET) X-XOASIS-EmailScanner-Information: X-XOASIS-EmailScanner: Found to be clean X-XOASIS-EmailScanner-From: jt@xoasis.de Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jt@xoasis.de List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 17:23:02 -0000 On Monday 01 November 2010, Andriy Gapon wrote: > on 01/11/2010 15:13 Andriy Gapon said the following: > > on 01/11/2010 14:41 Joerg Traeger said the following: > >> On Monday 01 November 2010, Andriy Gapon wrote: > >>> on 01/11/2010 14:25 Joerg Traeger said the following: > >>>> On Monday 01 November 2010, Andriy Gapon wrote: > >>>>> on 01/11/2010 11:52 Joerg Traeger said the following: > >>>>>> Hi, > >>>>>> > >>>>>> I have got several mainboards with CPUs which appear not to be > >>>>>> supportet by est. An error exists: > >>>>>> > >>>>>> (examle of somewhat older Intel DG45FC with DualCore E5200 and > >>>>>> latest BIOS) > >>>>>> > >>>>>> est0: on cpu0 > >>>>>> est: CPU supports Enhanced Speedstep, but is not recognized. > >>>>>> est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f > >>>>>> device_attach: est0 attach returned 6 <---------- > >>>>> > >>>>> Do you have ACPI enabled? > >>>> > >>>> Yes, sure it is enabled. > >>> > >>> Can you upload your acpidump -dt output somewhere and provide a link? > >> > >> You can read the output here: > >> http://xoasis.de/DG45FC_E5200_acpidump.txt > > > > Your BIOS doesn't provide _PSS method for processor objects, so est won't > > work in general ACPI mode. > > Hmm, it seems that I missed code in your DSDT for dynamically loading SSDT. > Could you please provide a link to your boot dmesg? Sure. You find dmesg here: http://xoasis.de/DG45FC_dmesg.txt -- If you say that you can't, then I shall reply, Parsley, sage, rosemary and thyme From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 18:37:02 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1764106566C for ; Mon, 1 Nov 2010 18:37:02 +0000 (UTC) (envelope-from jt@xoasis.de) Received: from pluto.xoasis.de (pluto.xoasis.de [85.159.14.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1D2258FC19 for ; Mon, 1 Nov 2010 18:37:01 +0000 (UTC) Received: from pad (rh1.xoasis.de [194.77.193.179] (may be forged)) (authenticated bits=0) by pluto.xoasis.de (8.13.8/8.13.6) with ESMTP id oA1Iau5I026849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Nov 2010 19:36:58 +0100 (CET) (envelope-from jt@xoasis.de) From: Joerg Traeger To: Andriy Gapon Date: Mon, 1 Nov 2010 20:36:55 +0200 User-Agent: KMail/1.9.10 References: <201011011052.11084.jt@xoasis.de> <4CCEED91.6030205@icyb.net.ua> <4CCEF0D9.10703@icyb.net.ua> In-Reply-To: <4CCEF0D9.10703@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201011011936.55934.jt@xoasis.de> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (pluto.xoasis.de [85.159.14.10]); Mon, 01 Nov 2010 19:36:58 +0100 (CET) X-XOASIS-EmailScanner-Information: X-XOASIS-EmailScanner: Found to be clean X-XOASIS-EmailScanner-From: jt@xoasis.de Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jt@xoasis.de List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 18:37:02 -0000 On Monday 01 November 2010, Andriy Gapon wrote: > on 01/11/2010 18:40 Andriy Gapon said the following: > > on 01/11/2010 15:13 Andriy Gapon said the following: > >> on 01/11/2010 14:41 Joerg Traeger said the following: > >>> You can read the output here: > >>> http://xoasis.de/DG45FC_E5200_acpidump.txt > >> > >> Your BIOS doesn't provide _PSS method for processor objects, so est > >> won't work in general ACPI mode. > > > > Hmm, it seems that I missed code in your DSDT for dynamically loading > > SSDT. > > It seems that your BIOS makes it a condition that OS supports the following > feature: ACPI_CAP_C1_IO_HALT. > > FreeBSD doesn't really support it, but you can try adding it to 'features' > variable in acpi_cpu_attach() in function in sys/dev/acpica/acpi_cpu.c; > look for the following line: > sc->cpu_features = ACPI_CAP_SMP_SAME | ACPI_CAP_SMP_SAME_C3; > > I don't think that should break anything for you, but may improve a thing > or two. I'd interested in seeing acpidump -d -t produced after the > patching. > > Thank you. Hey, est seems to be happy now! coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 Even C2 and C3 are anounced. dev.cpu.0.cx_supported: C1/20 C2/40 C3/60 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.09% 2.48% 97.41% last 207us But the system behaves strange. The fan comes up 10 times a minute and for example "sh /etc/rc autoboot" runs 5 minutes now. Load is too high without any processes running. And rebooting takes a long time syncing buffers. Are these side effects known? acpidump output did not change. -- If you say that you can't, then I shall reply, Parsley, sage, rosemary and thyme From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 18:42:55 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94439106566B for ; Mon, 1 Nov 2010 18:42:55 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DCA038FC13 for ; Mon, 1 Nov 2010 18:42:54 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA27366; Mon, 01 Nov 2010 20:42:51 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CCF0A2A.9060506@icyb.net.ua> Date: Mon, 01 Nov 2010 20:42:50 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: jt@xoasis.de References: <201011011052.11084.jt@xoasis.de> <4CCEED91.6030205@icyb.net.ua> <4CCEF0D9.10703@icyb.net.ua> <201011011936.55934.jt@xoasis.de> In-Reply-To: <201011011936.55934.jt@xoasis.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 18:42:55 -0000 on 01/11/2010 20:36 Joerg Traeger said the following: > On Monday 01 November 2010, Andriy Gapon wrote: >> It seems that your BIOS makes it a condition that OS supports the following >> feature: ACPI_CAP_C1_IO_HALT. >> >> FreeBSD doesn't really support it, but you can try adding it to 'features' >> variable in acpi_cpu_attach() in function in sys/dev/acpica/acpi_cpu.c; >> look for the following line: >> sc->cpu_features = ACPI_CAP_SMP_SAME | ACPI_CAP_SMP_SAME_C3; >> >> I don't think that should break anything for you, but may improve a thing >> or two. I'd interested in seeing acpidump -d -t produced after the >> patching. > > Hey, est seems to be happy now! > > coretemp0: on cpu0 > est0: on cpu0 > p4tcc0: on cpu0 > coretemp1: on cpu1 > est1: on cpu1 > p4tcc1: on cpu1 > > Even C2 and C3 are anounced. > > dev.cpu.0.cx_supported: C1/20 C2/40 C3/60 > dev.cpu.0.cx_lowest: C3 > dev.cpu.0.cx_usage: 0.09% 2.48% 97.41% last 207us > > But the system behaves strange. The fan comes up 10 times a minute and for > example "sh /etc/rc autoboot" runs 5 minutes now. Load is too high without > any processes running. And rebooting takes a long time syncing buffers. Are > these side effects known? Try to not use C3. > acpidump output did not change. Are you 100% sure? If yes, then could you please do the following? $ dd if=/dev/mem of=/tmp/ssdt.dump bs=1 skip=0xCBE61C18 count=0x02CC $ acpidump -d -f /tmp/ssdt.dump > /tmp/ssdt.asl Send me /tmp/ssdt.asl :) -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 18:52:23 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEC71106564A for ; Mon, 1 Nov 2010 18:52:22 +0000 (UTC) (envelope-from jt@xoasis.de) Received: from pluto.xoasis.de (pluto.xoasis.de [85.159.14.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB038FC17 for ; Mon, 1 Nov 2010 18:52:21 +0000 (UTC) Received: from pad (rh1.xoasis.de [194.77.193.179] (may be forged)) (authenticated bits=0) by pluto.xoasis.de (8.13.8/8.13.6) with ESMTP id oA1IqEgF026936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Nov 2010 19:52:16 +0100 (CET) (envelope-from jt@xoasis.de) From: Joerg Traeger To: Andriy Gapon Date: Mon, 1 Nov 2010 20:52:13 +0200 User-Agent: KMail/1.9.10 References: <201011011052.11084.jt@xoasis.de> <201011011936.55934.jt@xoasis.de> <4CCF0A2A.9060506@icyb.net.ua> In-Reply-To: <4CCF0A2A.9060506@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201011011952.14024.jt@xoasis.de> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (pluto.xoasis.de [85.159.14.10]); Mon, 01 Nov 2010 19:52:16 +0100 (CET) X-XOASIS-EmailScanner-Information: X-XOASIS-EmailScanner: Found to be clean X-XOASIS-EmailScanner-From: jt@xoasis.de Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jt@xoasis.de List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 18:52:23 -0000 On Monday 01 November 2010, Andriy Gapon wrote: > on 01/11/2010 20:36 Joerg Traeger said the following: > > On Monday 01 November 2010, Andriy Gapon wrote: > >> It seems that your BIOS makes it a condition that OS supports the > >> following feature: ACPI_CAP_C1_IO_HALT. > >> > >> FreeBSD doesn't really support it, but you can try adding it to > >> 'features' variable in acpi_cpu_attach() in function in > >> sys/dev/acpica/acpi_cpu.c; look for the following line: > >> sc->cpu_features = ACPI_CAP_SMP_SAME | ACPI_CAP_SMP_SAME_C3; > >> > >> I don't think that should break anything for you, but may improve a > >> thing or two. I'd interested in seeing acpidump -d -t produced after the > >> patching. > > > > Hey, est seems to be happy now! > > > > coretemp0: on cpu0 > > est0: on cpu0 > > p4tcc0: on cpu0 > > coretemp1: on cpu1 > > est1: on cpu1 > > p4tcc1: on cpu1 > > > > Even C2 and C3 are anounced. > > > > dev.cpu.0.cx_supported: C1/20 C2/40 C3/60 > > dev.cpu.0.cx_lowest: C3 > > dev.cpu.0.cx_usage: 0.09% 2.48% 97.41% last 207us > > > > But the system behaves strange. The fan comes up 10 times a minute and > > for example "sh /etc/rc autoboot" runs 5 minutes now. Load is too high > > without any processes running. And rebooting takes a long time syncing > > buffers. Are these side effects known? > > Try to not use C3. > > > acpidump output did not change. > > Are you 100% sure? Yes. # diff acpidump.txt acpidump_acpi_patched.txt 109c109 < * Disassembly of /tmp/acpidump.pdLAtj, Mon Nov 1 13:38:24 2010 --- > * Disassembly of /tmp/acpidump.DvGKfH, Mon Nov 1 19:12:53 2010 > If yes, then could you please do the following? > > $ dd if=/dev/mem of=/tmp/ssdt.dump bs=1 skip=0xCBE61C18 count=0x02CC This works. > $ acpidump -d -f /tmp/ssdt.dump > /tmp/ssdt.asl But: # acpidump -d -f /tmp/ssdt.dump > /tmp/ssdt.asl Segmentation fault: 11 > Send me /tmp/ssdt.asl :) The binary file look like this: less /tmp/ssdt.dump "/tmp/ssdt.dump" may be a binary file. See it anyway? SSDT^B^@^@^A)AMI^@^@^@IST^@^@^@^@^@^A^@^@^@MSFT^A^@^@^C^PD^E\._PR_CPU1PCT^R,^B^Q^T ^Q<82>^L^@^?@^@^@<99>^A^@^@^@^@^@^@y^@^Q^T ^Q<82>^L^@^?^P^@^@<98>^A^@^@^@^@^@^@y^@^T^K_PSS^@APSS^T _PPC^@ ^@^PD^E\._PR_CPU2PCT^R,^B^Q^T ^Q<82>^L^@^?@^@^@<99>^A^@^@^@^@^@^@y^@^Q^T ^Q<82>^L^@^?^P^@^@<98>^A^@^@^@^@^@^@y^@^T^K_PSS^@APSS^T _PPC^@ ^@^PD^E\._PR_CPU3PCT^R,^B^Q^T ^Q<82>^L^@^?@^@^@<99>^A^@^@^@^@^@^@y^@^Q^T ^Q<82>^L^@^?^P^@^@<98>^A^@^@^@^@^@^@y^@^T^K_PSS^@APSS^T _PPC^@ ^@^PD^E\._PR_CPU4PCT^R,^B^Q^T ^Q<82>^L^@^?@^@^@<99>^A^@^@^@^@^@^@y^@^Q^T ^Q<82>^L^@^?^P^@^@<98>^A^@^@^@^@^@^@y^@^T^K_PSS^@APSS^T _PPC^@ ^@^PD^E\._PR_CPU5PCT^R,^B^Q^T ^Q<82>^L^@^?@^@^@<99>^A^@^@^@^@^@^@y^@^Q^T ^Q<82>^L^@^?^P^@^@<98>^A^@^@^@^@^@^@y^@^T^K_PSS^@APSS^T _PPC^@ ^@^PD^E\._PR_CPU6PCT^R,^B^Q^T ^Q<82>^L^@^?@^@^@<99>^A^@^@^@^@^@^@y^@^Q^T ^Q<82>^L^@^?^P^@^@<98>^A^@^@^@^@^@^@y^@^T^K_PSS^@APSS^T _PPC^@ ^@^PD^E\._PR_CPU7PCT^R,^B^Q^T ^Q<82>^L^@^?@^@^@<99>^A^@^@^@^@^@^@y^@^Q^T ^Q<82>^L^@^?^P^@^@<98>^A^@^@^@^@^@^@y^@^T^K_PSS^@APSS^T _PPC^@ ^@^PD^E\._PR_CPU8PCT^R,^B^Q^T ^Q<82>^L^@^?@^@^@<99>^A^@^@^@^@^@^@y^@^Q^T ^Q<82>^L^@^?^P^@^@<98>^A^@^@^@^@^@^@y^@^T^K_PSS^@APSS^T _PPC^@ ^@ /tmp/ssdt.dump (END) -- If you say that you can't, then I shall reply, Parsley, sage, rosemary and thyme From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 19:02:05 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C12B1065679 for ; Mon, 1 Nov 2010 19:02:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8188FC08 for ; Mon, 1 Nov 2010 19:02:03 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA27601; Mon, 01 Nov 2010 21:02:00 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CCF0EA8.6000807@icyb.net.ua> Date: Mon, 01 Nov 2010 21:02:00 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: jt@xoasis.de References: <201011011052.11084.jt@xoasis.de> <201011011936.55934.jt@xoasis.de> <4CCF0A2A.9060506@icyb.net.ua> <201011011952.14024.jt@xoasis.de> In-Reply-To: <201011011952.14024.jt@xoasis.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 19:02:05 -0000 on 01/11/2010 20:52 Joerg Traeger said the following: > On Monday 01 November 2010, Andriy Gapon wrote: >> on 01/11/2010 20:36 Joerg Traeger said the following: >>> On Monday 01 November 2010, Andriy Gapon wrote: >>>> It seems that your BIOS makes it a condition that OS supports the >>>> following feature: ACPI_CAP_C1_IO_HALT. >>>> >>>> FreeBSD doesn't really support it, but you can try adding it to >>>> 'features' variable in acpi_cpu_attach() in function in >>>> sys/dev/acpica/acpi_cpu.c; look for the following line: >>>> sc->cpu_features = ACPI_CAP_SMP_SAME | ACPI_CAP_SMP_SAME_C3; >>>> >>>> I don't think that should break anything for you, but may improve a >>>> thing or two. I'd interested in seeing acpidump -d -t produced after the >>>> patching. >>> >>> Hey, est seems to be happy now! >>> >>> coretemp0: on cpu0 >>> est0: on cpu0 >>> p4tcc0: on cpu0 >>> coretemp1: on cpu1 >>> est1: on cpu1 >>> p4tcc1: on cpu1 >>> >>> Even C2 and C3 are anounced. >>> >>> dev.cpu.0.cx_supported: C1/20 C2/40 C3/60 >>> dev.cpu.0.cx_lowest: C3 >>> dev.cpu.0.cx_usage: 0.09% 2.48% 97.41% last 207us >>> >>> But the system behaves strange. The fan comes up 10 times a minute and >>> for example "sh /etc/rc autoboot" runs 5 minutes now. Load is too high >>> without any processes running. And rebooting takes a long time syncing >>> buffers. Are these side effects known? >> >> Try to not use C3. >> Have you already tried this? What are the results? >>> acpidump output did not change. >> >> Are you 100% sure? > > Yes. > # diff acpidump.txt acpidump_acpi_patched.txt > 109c109 > < * Disassembly of /tmp/acpidump.pdLAtj, Mon Nov 1 13:38:24 2010 > --- >> * Disassembly of /tmp/acpidump.DvGKfH, Mon Nov 1 19:12:53 2010 > > >> If yes, then could you please do the following? >> >> $ dd if=/dev/mem of=/tmp/ssdt.dump bs=1 skip=0xCBE61C18 count=0x02CC > > This works. > >> $ acpidump -d -f /tmp/ssdt.dump > /tmp/ssdt.asl > > But: > # acpidump -d -f /tmp/ssdt.dump > /tmp/ssdt.asl > Segmentation fault: 11 > >> Send me /tmp/ssdt.asl :) Can you please upload the binary file then? -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 19:07:40 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF48A106567A for ; Mon, 1 Nov 2010 19:07:40 +0000 (UTC) (envelope-from jt@xoasis.de) Received: from pluto.xoasis.de (pluto.xoasis.de [85.159.14.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3C8248FC13 for ; Mon, 1 Nov 2010 19:07:39 +0000 (UTC) Received: from pad (rh1.xoasis.de [194.77.193.179] (may be forged)) (authenticated bits=0) by pluto.xoasis.de (8.13.8/8.13.6) with ESMTP id oA1J7ZYT027088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Nov 2010 20:07:37 +0100 (CET) (envelope-from jt@xoasis.de) From: Joerg Traeger To: Andriy Gapon Date: Mon, 1 Nov 2010 21:07:34 +0200 User-Agent: KMail/1.9.10 References: <201011011052.11084.jt@xoasis.de> <201011011952.14024.jt@xoasis.de> <4CCF0EA8.6000807@icyb.net.ua> In-Reply-To: <4CCF0EA8.6000807@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201011012007.35126.jt@xoasis.de> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (pluto.xoasis.de [85.159.14.10]); Mon, 01 Nov 2010 20:07:37 +0100 (CET) X-XOASIS-EmailScanner-Information: X-XOASIS-EmailScanner: Found to be clean X-XOASIS-EmailScanner-From: jt@xoasis.de Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jt@xoasis.de List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 19:07:40 -0000 On Monday 01 November 2010, Andriy Gapon wrote: > on 01/11/2010 20:52 Joerg Traeger said the following: > > On Monday 01 November 2010, Andriy Gapon wrote: > >> on 01/11/2010 20:36 Joerg Traeger said the following: > >>> On Monday 01 November 2010, Andriy Gapon wrote: > >>>> It seems that your BIOS makes it a condition that OS supports the > >>>> following feature: ACPI_CAP_C1_IO_HALT. > >>>> > >>>> FreeBSD doesn't really support it, but you can try adding it to > >>>> 'features' variable in acpi_cpu_attach() in function in > >>>> sys/dev/acpica/acpi_cpu.c; look for the following line: > >>>> sc->cpu_features = ACPI_CAP_SMP_SAME | ACPI_CAP_SMP_SAME_C3; > >>>> > >>>> I don't think that should break anything for you, but may improve a > >>>> thing or two. I'd interested in seeing acpidump -d -t produced after > >>>> the patching. > >>> > >>> Hey, est seems to be happy now! > >>> > >>> coretemp0: on cpu0 > >>> est0: on cpu0 > >>> p4tcc0: on cpu0 > >>> coretemp1: on cpu1 > >>> est1: on cpu1 > >>> p4tcc1: on cpu1 > >>> > >>> Even C2 and C3 are anounced. > >>> > >>> dev.cpu.0.cx_supported: C1/20 C2/40 C3/60 > >>> dev.cpu.0.cx_lowest: C3 > >>> dev.cpu.0.cx_usage: 0.09% 2.48% 97.41% last 207us > >>> > >>> But the system behaves strange. The fan comes up 10 times a minute and > >>> for example "sh /etc/rc autoboot" runs 5 minutes now. Load is too high > >>> without any processes running. And rebooting takes a long time syncing > >>> buffers. Are these side effects known? > >> > >> Try to not use C3. > > Have you already tried this? > What are the results? So far everything is fine. The system responds faster now than using C3. > >> If yes, then could you please do the following? > >> > >> $ dd if=/dev/mem of=/tmp/ssdt.dump bs=1 skip=0xCBE61C18 count=0x02CC > > > > This works. > > > >> $ acpidump -d -f /tmp/ssdt.dump > /tmp/ssdt.asl > > > > But: > > # acpidump -d -f /tmp/ssdt.dump > /tmp/ssdt.asl > > Segmentation fault: 11 > > > >> Send me /tmp/ssdt.asl :) > > Can you please upload the binary file then? It is uploaded: http://xoasis.de/ssdt-DG45FC-E5200.dump -- If you say that you can't, then I shall reply, Parsley, sage, rosemary and thyme From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 19:21:56 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD19D1065672 for ; Mon, 1 Nov 2010 19:21:56 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 150AC8FC08 for ; Mon, 1 Nov 2010 19:21:55 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA27905; Mon, 01 Nov 2010 21:21:51 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CCF134F.8070905@icyb.net.ua> Date: Mon, 01 Nov 2010 21:21:51 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: jt@xoasis.de References: <201011011052.11084.jt@xoasis.de> <201011011952.14024.jt@xoasis.de> <4CCF0EA8.6000807@icyb.net.ua> <201011012007.35126.jt@xoasis.de> In-Reply-To: <201011012007.35126.jt@xoasis.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 19:21:56 -0000 on 01/11/2010 21:07 Joerg Traeger said the following: > On Monday 01 November 2010, Andriy Gapon wrote: >> on 01/11/2010 20:52 Joerg Traeger said the following: >>> On Monday 01 November 2010, Andriy Gapon wrote: >>>> Try to not use C3. >> >> Have you already tried this? >> What are the results? > > So far everything is fine. The system responds faster now than using C3. OK. >>>> If yes, then could you please do the following? >>>> >>>> $ dd if=/dev/mem of=/tmp/ssdt.dump bs=1 skip=0xCBE61C18 count=0x02CC >>> >>> This works. >>> >>>> $ acpidump -d -f /tmp/ssdt.dump > /tmp/ssdt.asl >>> >>> But: >>> # acpidump -d -f /tmp/ssdt.dump > /tmp/ssdt.asl >>> Segmentation fault: 11 >>> >>>> Send me /tmp/ssdt.asl :) >> >> Can you please upload the binary file then? > > It is uploaded: http://xoasis.de/ssdt-DG45FC-E5200.dump Thanks again. The last step in my instructions should have been: $ iasl -d ssdt-DG45FC-E5200.dump -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 01:39:21 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 730041065697 for ; Tue, 2 Nov 2010 01:39:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id E08978FC13 for ; Tue, 2 Nov 2010 01:39:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id oA21dITr096251; Tue, 2 Nov 2010 12:39:18 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 2 Nov 2010 12:39:17 +1100 (EST) From: Ian Smith To: Joerg Traeger In-Reply-To: <201011011822.54279.jt@xoasis.de> Message-ID: <20101102123207.L33417@sola.nimnet.asn.au> References: <201011011052.11084.jt@xoasis.de> <4CCEBCE0.2040308@icyb.net.ua> <4CCEED91.6030205@icyb.net.ua> <201011011822.54279.jt@xoasis.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, Andriy Gapon Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 01:39:21 -0000 On Mon, 1 Nov 2010, Joerg Traeger wrote: > On Monday 01 November 2010, Andriy Gapon wrote: > > on 01/11/2010 15:13 Andriy Gapon said the following: > > > on 01/11/2010 14:41 Joerg Traeger said the following: > > >> On Monday 01 November 2010, Andriy Gapon wrote: > > >>> on 01/11/2010 14:25 Joerg Traeger said the following: > > >>>> On Monday 01 November 2010, Andriy Gapon wrote: > > >>>>> on 01/11/2010 11:52 Joerg Traeger said the following: > > >>>>>> Hi, > > >>>>>> > > >>>>>> I have got several mainboards with CPUs which appear not to be > > >>>>>> supportet by est. An error exists: > > >>>>>> > > >>>>>> (examle of somewhat older Intel DG45FC with DualCore E5200 and > > >>>>>> latest BIOS) > > >>>>>> > > >>>>>> est0: on cpu0 > > >>>>>> est: CPU supports Enhanced Speedstep, but is not recognized. > > >>>>>> est: cpu_vendor GenuineIntel, msr 61a4c1f06004c1f > > >>>>>> device_attach: est0 attach returned 6 <---------- > > >>>>> > > >>>>> Do you have ACPI enabled? > > >>>> > > >>>> Yes, sure it is enabled. > > >>> > > >>> Can you upload your acpidump -dt output somewhere and provide a link? > > >> > > >> You can read the output here: > > >> http://xoasis.de/DG45FC_E5200_acpidump.txt > > > > > > Your BIOS doesn't provide _PSS method for processor objects, so est won't > > > work in general ACPI mode. > > > > Hmm, it seems that I missed code in your DSDT for dynamically loading SSDT. > > Could you please provide a link to your boot dmesg? > > Sure. You find dmesg here: http://xoasis.de/DG45FC_dmesg.txt Don't know whether it's relevant, but I noticed: ACPI: Overriding _OS definition with "Windows 2001.1" but your acpidump shows FreeBSD as a supported OS in method OSFL: If (_OSI ("FreeBSD")) { Store (0x06, OSVR) } cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 06:56:26 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0772C106564A for ; Tue, 2 Nov 2010 06:56:26 +0000 (UTC) (envelope-from jt@xoasis.de) Received: from pluto.xoasis.de (pluto.xoasis.de [85.159.14.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9270E8FC0A for ; Tue, 2 Nov 2010 06:56:25 +0000 (UTC) Received: from pad (rh1.xoasis.de [194.77.193.179] (may be forged)) (authenticated bits=0) by pluto.xoasis.de (8.13.8/8.13.6) with ESMTP id oA26uJhP032967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Nov 2010 07:56:21 +0100 (CET) (envelope-from jt@xoasis.de) From: Joerg Traeger To: Ian Smith Date: Tue, 2 Nov 2010 08:56:18 +0200 User-Agent: KMail/1.9.10 References: <201011011052.11084.jt@xoasis.de> <201011011822.54279.jt@xoasis.de> <20101102123207.L33417@sola.nimnet.asn.au> In-Reply-To: <20101102123207.L33417@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201011020756.18878.jt@xoasis.de> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (pluto.xoasis.de [85.159.14.10]); Tue, 02 Nov 2010 07:56:21 +0100 (CET) X-XOASIS-EmailScanner-Information: X-XOASIS-EmailScanner: Found to be clean X-XOASIS-EmailScanner-From: jt@xoasis.de Cc: freebsd-acpi@freebsd.org, Andriy Gapon Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jt@xoasis.de List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 06:56:26 -0000 On Tuesday 02 November 2010, Ian Smith wrote: > > > >> You can read the output here: > > > >> http://xoasis.de/DG45FC_E5200_acpidump.txt > > > > > > > > Your BIOS doesn't provide _PSS method for processor objects, so est > > > > won't work in general ACPI mode. > > > > > > Hmm, it seems that I missed code in your DSDT for dynamically loading > > > SSDT. Could you please provide a link to your boot dmesg? > > > > Sure. You find dmesg here: http://xoasis.de/DG45FC_dmesg.txt > > Don't know whether it's relevant, but I noticed: > > ACPI: Overriding _OS definition with "Windows 2001.1" > > but your acpidump shows FreeBSD as a supported OS in method OSFL: > > If (_OSI ("FreeBSD")) > { > Store (0x06, OSVR) > } > I tried a lot of things like overriding this definition and removing the warning in the acpi table. -- If you say that you can't, then I shall reply, Parsley, sage, rosemary and thyme From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 15:10:20 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98DD4106567A; Tue, 2 Nov 2010 15:10:20 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx1.freebsd.org (Postfix) with ESMTP id 3B9488FC0C; Tue, 2 Nov 2010 15:10:20 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 02 Nov 2010 08:10:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.58,283,1286175600"; d="scan'208";a="853386373" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by fmsmga001.fm.intel.com with ESMTP; 02 Nov 2010 08:10:17 -0700 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx603.amr.corp.intel.com ([10.22.226.49]) with mapi; Tue, 2 Nov 2010 08:10:17 -0700 From: "Moore, Robert" To: Bernhard Froehlich , "freebsd-acpi@FreeBSD.org" , Jung-uk Kim Date: Tue, 2 Nov 2010 08:10:16 -0700 Thread-Topic: VirtualBox: Compile problems with ACPICA 20101013 Thread-Index: ActurjSmS8pZl6qbSd6lxPme3tFT8wL8ZrIw Message-ID: <4911F71203A09E4D9981D27F9D830858BC3F48FC@orsmsx503.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "vbox@FreeBSD.org" Subject: RE: VirtualBox: Compile problems with ACPICA 20101013 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 15:10:20 -0000 We may have gone a bit overboard on this one in iASL. Correct, if it is a s= tring, _CID is not restricted to alphanumeric. However, it appears the stri= ng must be non-null. Bob >-----Original Message----- >From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >acpi@freebsd.org] On Behalf Of Bernhard Froehlich >Sent: Monday, October 18, 2010 2:45 AM >To: freebsd-acpi@FreeBSD.org >Cc: vbox@FreeBSD.org >Subject: VirtualBox: Compile problems with ACPICA 20101013 > >Hi guys! > >VirtualBox has a compile problem with latest acpica. I've talked to the >VirtualBox developers and they think it's an acpica problem which should >be fixed upstream. Can we somehow file a bugreport or create a patch to >fix that in acpica? > >Compile error: >kBuild: iasl DevicesR3 - >/usr/ports/emulators/virtualbox-ose/work/VirtualBox- >3.2.10_OSE/src/VBox/Devices/PC/vbox.dsl >/usr/ports/emulators/virtualbox-ose/work/VirtualBox- >3.2.10_OSE/src/VBox/Devices/PC/vbox.dsl > 736: Name (_CID, "smc-napa") >Error 4001 - > String must be entirely alphanumeric ^ >(smc-napa) > >ASL Input: >/usr/ports/emulators/virtualbox-ose/work/VirtualBox- >3.2.10_OSE/src/VBox/Devices/PC/vbox.dsl >- 1305 lines, 46193 bytes, 288 keywords >Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 404 >Optimizations > > >I have found the commit that introduces this additional checks: >http://git.moblin.org/cgit.cgi/acpica/commit/?id=3Db66fd716e0b9b5389e544c5= 8df >189c817f316c3b > >and here is the dsl file from virtualbox: >http://www.virtualbox.org/browser/trunk/src/VBox/Devices/PC/vbox.dsl#L781 > > >Thanks! > >-- >Bernhard Froehlich >http://www.bluelife.at/ >_______________________________________________ >freebsd-acpi@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 15:29:59 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3A5D106564A; Tue, 2 Nov 2010 15:29:59 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A6B608FC16; Tue, 2 Nov 2010 15:29:58 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA14943; Tue, 02 Nov 2010 17:29:49 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD02E6D.1070106@freebsd.org> Date: Tue, 02 Nov 2010 17:29:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Hans Petter Selasky References: <201010121209.06397.hselasky@c2i.net> <1288278300.2459.19.camel@localhost> <1288279472.2459.22.camel@localhost> <201010281810.23668.hselasky@c2i.net> <1288312476.13315.15.camel@minggr.sh.intel.com> <4CCA594C.7050806@icyb.net.ua> <4CCA5A3B.9000101@icyb.net.ua> <4CCA60C9.7040600@icyb.net.ua> In-Reply-To: <4CCA60C9.7040600@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Lin Ming , "Moore, Robert" Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 15:29:59 -0000 on 29/10/2010 08:51 Andriy Gapon said the following: > I guess that a general problem here is that it is incorrect to merely use > memcpy/bcopy to create a copy of a resource if the resource has > ACPI_RESOURCE_SOURCE field in it. Hans, could you please test the following patch? diff --git a/sys/dev/acpica/acpi_pci_link.c b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 --- a/sys/dev/acpica/acpi_pci_link.c +++ b/sys/dev/acpica/acpi_pci_link.c @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs link->l_irq; else resptr->Data.ExtendedIrq.Interrupts[0] = 0; + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, + sizeof(ACPI_RESOURCE_SOURCE)); link++; i++; break; -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 15:52:12 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 0240D1065672; Tue, 2 Nov 2010 15:52:12 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org, jt@xoasis.de Date: Tue, 2 Nov 2010 11:51:34 -0400 User-Agent: KMail/1.6.2 References: <201011011052.11084.jt@xoasis.de> <4CCEED91.6030205@icyb.net.ua> <201011011822.54279.jt@xoasis.de> In-Reply-To: <201011011822.54279.jt@xoasis.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011021152.04223.jkim@FreeBSD.org> Cc: Andriy Gapon Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 15:52:12 -0000 On Monday 01 November 2010 01:22 pm, Joerg Traeger wrote: > On Monday 01 November 2010, Andriy Gapon wrote: > > on 01/11/2010 15:13 Andriy Gapon said the following: > > > on 01/11/2010 14:41 Joerg Traeger said the following: > > >> On Monday 01 November 2010, Andriy Gapon wrote: > > >>> on 01/11/2010 14:25 Joerg Traeger said the following: > > >>>> On Monday 01 November 2010, Andriy Gapon wrote: > > >>>>> on 01/11/2010 11:52 Joerg Traeger said the following: > > >>>>>> Hi, > > >>>>>> > > >>>>>> I have got several mainboards with CPUs which appear not > > >>>>>> to be supportet by est. An error exists: > > >>>>>> > > >>>>>> (examle of somewhat older Intel DG45FC with DualCore E5200 > > >>>>>> and latest BIOS) > > >>>>>> > > >>>>>> est0: on cpu0 > > >>>>>> est: CPU supports Enhanced Speedstep, but is not > > >>>>>> recognized. est: cpu_vendor GenuineIntel, msr > > >>>>>> 61a4c1f06004c1f device_attach: est0 attach returned 6 > > >>>>>> <---------- > > >>>>> > > >>>>> Do you have ACPI enabled? > > >>>> > > >>>> Yes, sure it is enabled. > > >>> > > >>> Can you upload your acpidump -dt output somewhere and provide > > >>> a link? > > >> > > >> You can read the output here: > > >> http://xoasis.de/DG45FC_E5200_acpidump.txt > > > > > > Your BIOS doesn't provide _PSS method for processor objects, so > > > est won't work in general ACPI mode. > > > > Hmm, it seems that I missed code in your DSDT for dynamically > > loading SSDT. Could you please provide a link to your boot dmesg? > > Sure. You find dmesg here: http://xoasis.de/DG45FC_dmesg.txt > ACPI Warning: 32/64X FACS address mismatch in FADT - 0xCBE61F40/0x 0CBE67E40, using 32 (20100331/tbfadt-586) Grrr... I bet this board has a Windows XP sticker on it? ;-) > ACPI: Overriding _OS definition with "Windows 2001.1" \_OS does not do anything for modern BIOSes such as yours, i.e., it is only useful for up to MS Win2K-ish BIOS, only because MS mandated it from XP AFAIK. By default, \_OSI is used and it will match "Windows 2001.1" just fine. Although the DSDT has listed many other non-Windows OSes in the table, they are just place holders AFAICT. Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 19:29:13 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 8AF4A1065670; Tue, 2 Nov 2010 19:29:13 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Tue, 2 Nov 2010 15:29:01 -0400 User-Agent: KMail/1.6.2 References: <201010121209.06397.hselasky@c2i.net> <4CCA60C9.7040600@icyb.net.ua> <4CD02E6D.1070106@freebsd.org> In-Reply-To: <4CD02E6D.1070106@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_BaG0MdvZBXSNuzs" Message-Id: <201011021529.05977.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org, "Moore, Robert" , Lin Ming Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 19:29:13 -0000 --Boundary-00=_BaG0MdvZBXSNuzs Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > on 29/10/2010 08:51 Andriy Gapon said the following: > > I guess that a general problem here is that it is incorrect to > > merely use memcpy/bcopy to create a copy of a resource if the > > resource has ACPI_RESOURCE_SOURCE field in it. > > Hans, > > could you please test the following patch? > > diff --git a/sys/dev/acpica/acpi_pci_link.c > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 > --- a/sys/dev/acpica/acpi_pci_link.c > +++ b/sys/dev/acpica/acpi_pci_link.c > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > link->l_irq; > else > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, > + sizeof(ACPI_RESOURCE_SOURCE)); > link++; > i++; > break; Hmm... Very interesting. Can you please try this, too? Thanks, Jung-uk Kim --Boundary-00=_BaG0MdvZBXSNuzs Content-Type: text/plain; charset="iso-8859-1"; name="acpi_pci_link.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="acpi_pci_link.diff" --- sys/dev/acpica/acpi_pci_link.c 2010-03-05 15:07:53.000000000 -0500 +++ sys/dev/acpica/acpi_pci_link.c 2010-11-02 14:57:50.000000000 -0400 @@ -268,6 +268,7 @@ static ACPI_STATUS link_add_prs(ACPI_RESOURCE *res, void *context) { + ACPI_RESOURCE_EXTENDED_IRQ *ext; struct link_res_request *req; struct link *link; UINT8 *irqs = NULL; @@ -323,6 +324,13 @@ */ bcopy(res, &link->l_prs_template, sizeof(ACPI_RESOURCE)); if (is_ext_irq) { + ext = &link->l_prs_template.Data.ExtendedIrq; + ext->ResourceSource.StringPtr = malloc( + ext->ResourceSource.StringLength + 1, + M_PCI_LINK, M_WAITOK); + strncpy(ext->ResourceSource.StringPtr, + res->Data.ExtendedIrq.ResourceSource.StringPtr, + ext->ResourceSource.StringLength + 1); link->l_num_irqs = res->Data.ExtendedIrq.InterruptCount; ext_irqs = res->Data.ExtendedIrq.Interrupts; @@ -422,9 +430,10 @@ static int acpi_pci_link_attach(device_t dev) { - struct acpi_pci_link_softc *sc; struct link_count_request creq; struct link_res_request rreq; + ACPI_RESOURCE_EXTENDED_IRQ *ext; + struct acpi_pci_link_softc *sc; ACPI_STATUS status; int i; @@ -540,9 +549,15 @@ return (0); fail: ACPI_SERIAL_END(pci_link); - for (i = 0; i < sc->pl_num_links; i++) + for (i = 0; i < sc->pl_num_links; i++) { + if (sc->pl_links[i].l_prs_template.Type == + ACPI_RESOURCE_TYPE_EXTENDED_IRQ) { + ext = &sc->pl_links[i].l_prs_template.Data.ExtendedIrq; + free(ext->ResourceSource.StringPtr, M_PCI_LINK); + } if (sc->pl_links[i].l_irqs != NULL) free(sc->pl_links[i].l_irqs, M_PCI_LINK); + } free(sc->pl_links, M_PCI_LINK); return (ENXIO); } --Boundary-00=_BaG0MdvZBXSNuzs-- From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 19:43:25 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA1DF106566C; Tue, 2 Nov 2010 19:43:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B9F658FC15; Tue, 2 Nov 2010 19:43:25 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5B2DC46B95; Tue, 2 Nov 2010 15:43:25 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B5AA88A009; Tue, 2 Nov 2010 15:43:19 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Date: Tue, 2 Nov 2010 15:41:48 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010121209.06397.hselasky@c2i.net> <4CD02E6D.1070106@freebsd.org> <201011021529.05977.jkim@FreeBSD.org> In-Reply-To: <201011021529.05977.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011021541.48741.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 02 Nov 2010 15:43:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: "Moore, Robert" , freebsd-acpi@freebsd.org, Lin Ming , Andriy Gapon Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 19:43:26 -0000 On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > I guess that a general problem here is that it is incorrect to > > > merely use memcpy/bcopy to create a copy of a resource if the > > > resource has ACPI_RESOURCE_SOURCE field in it. > > > > Hans, > > > > could you please test the following patch? > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 > > --- a/sys/dev/acpica/acpi_pci_link.c > > +++ b/sys/dev/acpica/acpi_pci_link.c > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > link->l_irq; > > else > > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > > + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, > > + sizeof(ACPI_RESOURCE_SOURCE)); > > link++; > > i++; > > break; > > Hmm... Very interesting. Can you please try this, too? Linux doesn't set the resource source bits up at all when doing _SRS, so I'd rather just do that. I think what I'd prefer is that we not use the prs_template, perhaps just save the type of the resource and build a new resource object from scratch where the resource is zero'd, the appropriate bits are set and then that resource is appended to the buffer being built. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 20:14:15 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 99718106566B; Tue, 2 Nov 2010 20:14:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: John Baldwin Date: Tue, 2 Nov 2010 16:14:05 -0400 User-Agent: KMail/1.6.2 References: <201010121209.06397.hselasky@c2i.net> <201011021529.05977.jkim@FreeBSD.org> <201011021541.48741.jhb@freebsd.org> In-Reply-To: <201011021541.48741.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011021614.07631.jkim@FreeBSD.org> Cc: "Moore, Robert" , freebsd-acpi@freebsd.org, Lin Ming , Andriy Gapon Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 20:14:15 -0000 On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > I guess that a general problem here is that it is incorrect > > > > to merely use memcpy/bcopy to create a copy of a resource if > > > > the resource has ACPI_RESOURCE_SOURCE field in it. > > > > > > Hans, > > > > > > could you please test the following patch? > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 > > > --- a/sys/dev/acpica/acpi_pci_link.c > > > +++ b/sys/dev/acpica/acpi_pci_link.c > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > link->l_irq; > > > else > > > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > > > + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, > > > + sizeof(ACPI_RESOURCE_SOURCE)); > > > link++; > > > i++; > > > break; > > > > Hmm... Very interesting. Can you please try this, too? > > Linux doesn't set the resource source bits up at all when doing > _SRS, so I'd rather just do that. I think what I'd prefer is that > we not use the prs_template, perhaps just save the type of the > resource and build a new resource object from scratch where the > resource is zero'd, the appropriate bits are set and then that > resource is appended to the buffer being built. "Linux doesn't do it" is wrong if I am reading the spec. correctly, i.e., _CRS, _PRS and _SRS must have the same format and size. Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 20:25:37 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B54361065673; Tue, 2 Nov 2010 20:25:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 80B308FC0C; Tue, 2 Nov 2010 20:25:37 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1D90E46B91; Tue, 2 Nov 2010 16:25:37 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 065C28A009; Tue, 2 Nov 2010 16:25:36 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Date: Tue, 2 Nov 2010 16:24:38 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010121209.06397.hselasky@c2i.net> <201011021541.48741.jhb@freebsd.org> <201011021614.07631.jkim@FreeBSD.org> In-Reply-To: <201011021614.07631.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011021624.38882.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 02 Nov 2010 16:25:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: "Moore, Robert" , freebsd-acpi@freebsd.org, Lin Ming , Andriy Gapon Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 20:25:37 -0000 On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: > > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > > I guess that a general problem here is that it is incorrect > > > > > to merely use memcpy/bcopy to create a copy of a resource if > > > > > the resource has ACPI_RESOURCE_SOURCE field in it. > > > > > > > > Hans, > > > > > > > > could you please test the following patch? > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 > > > > --- a/sys/dev/acpica/acpi_pci_link.c > > > > +++ b/sys/dev/acpica/acpi_pci_link.c > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > link->l_irq; > > > > else > > > > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > > > > + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, > > > > + sizeof(ACPI_RESOURCE_SOURCE)); > > > > link++; > > > > i++; > > > > break; > > > > > > Hmm... Very interesting. Can you please try this, too? > > > > Linux doesn't set the resource source bits up at all when doing > > _SRS, so I'd rather just do that. I think what I'd prefer is that > > we not use the prs_template, perhaps just save the type of the > > resource and build a new resource object from scratch where the > > resource is zero'd, the appropriate bits are set and then that > > resource is appended to the buffer being built. > > "Linux doesn't do it" is wrong if I am reading the spec. correctly, > i.e., _CRS, _PRS and _SRS must have the same format and size. Umm, but we aren't setting up the raw bits for _SRS. We are creating a list of ACPI_RESOURCE objects that ACPICA then encodes into a buffer to send to _SRS. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 20:50:30 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id B3668106564A; Tue, 2 Nov 2010 20:50:30 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: John Baldwin Date: Tue, 2 Nov 2010 16:50:18 -0400 User-Agent: KMail/1.6.2 References: <201010121209.06397.hselasky@c2i.net> <201011021614.07631.jkim@FreeBSD.org> <201011021624.38882.jhb@freebsd.org> In-Reply-To: <201011021624.38882.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011021650.22657.jkim@FreeBSD.org> Cc: "Moore, Robert" , freebsd-acpi@freebsd.org, Lin Ming , Andriy Gapon Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 20:50:30 -0000 On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: > > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: > > > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > > > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > > > I guess that a general problem here is that it is > > > > > > incorrect to merely use memcpy/bcopy to create a copy of > > > > > > a resource if the resource has ACPI_RESOURCE_SOURCE field > > > > > > in it. > > > > > > > > > > Hans, > > > > > > > > > > could you please test the following patch? > > > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 > > > > > 100644 --- a/sys/dev/acpica/acpi_pci_link.c > > > > > +++ b/sys/dev/acpica/acpi_pci_link.c > > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > > link->l_irq; > > > > > else > > > > > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > > > > > + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, > > > > > + sizeof(ACPI_RESOURCE_SOURCE)); > > > > > link++; > > > > > i++; > > > > > break; > > > > > > > > Hmm... Very interesting. Can you please try this, too? > > > > > > Linux doesn't set the resource source bits up at all when doing > > > _SRS, so I'd rather just do that. I think what I'd prefer is > > > that we not use the prs_template, perhaps just save the type of > > > the resource and build a new resource object from scratch where > > > the resource is zero'd, the appropriate bits are set and then > > > that resource is appended to the buffer being built. > > > > "Linux doesn't do it" is wrong if I am reading the spec. > > correctly, i.e., _CRS, _PRS and _SRS must have the same format > > and size. > > Umm, but we aren't setting up the raw bits for _SRS. We are > creating a list of ACPI_RESOURCE objects that ACPICA then encodes > into a buffer to send to _SRS. Yes, I understand. However, ACPICA is expecting the same size of buffer *including* the optional parts if I am reading the code right. Besides, I don't think there is any harm in doing the right thing. ;-) Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 20:56:02 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A7661065679; Tue, 2 Nov 2010 20:56:02 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id 2B63A8FC08; Tue, 2 Nov 2010 20:56:01 +0000 (UTC) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 02 Nov 2010 13:56:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.58,284,1286175600"; d="scan'208";a="569734402" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by orsmga002.jf.intel.com with ESMTP; 02 Nov 2010 13:56:00 -0700 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx603.amr.corp.intel.com ([10.22.226.49]) with mapi; Tue, 2 Nov 2010 13:56:00 -0700 From: "Moore, Robert" To: Jung-uk Kim , John Baldwin Date: Tue, 2 Nov 2010 13:55:58 -0700 Thread-Topic: MacBookPro 5,1 Thread-Index: Act6z5scnZGYKkUrQZiDqKP5mzYLYgAAJMxg Message-ID: <4911F71203A09E4D9981D27F9D830858BC3F4EB2@orsmsx503.amr.corp.intel.com> References: <201010121209.06397.hselasky@c2i.net> <201011021614.07631.jkim@FreeBSD.org> <201011021624.38882.jhb@freebsd.org> <201011021650.22657.jkim@FreeBSD.org> In-Reply-To: <201011021650.22657.jkim@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" , "Lin, Ming M" , Andriy Gapon Subject: RE: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 20:56:02 -0000 Yes, it is important to keep all of these structures the same. The last time I personally ran into this was when we attempted to optimize = an interrupt descriptor before sending it out via _SRS. Since the size of t= he whole template was now different than the size of the _CRS, the BIOS fai= led on it. >-----Original Message----- >From: Jung-uk Kim [mailto:jkim@FreeBSD.org] >Sent: Tuesday, November 02, 2010 1:50 PM >To: John Baldwin >Cc: Andriy Gapon; Hans Petter Selasky; Lin, Ming M; Moore, Robert; freebsd= - >acpi@freebsd.org >Subject: Re: MacBookPro 5,1 > >On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: >> On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: >> > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: >> > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: >> > > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: >> > > > > on 29/10/2010 08:51 Andriy Gapon said the following: >> > > > > > I guess that a general problem here is that it is >> > > > > > incorrect to merely use memcpy/bcopy to create a copy of >> > > > > > a resource if the resource has ACPI_RESOURCE_SOURCE field >> > > > > > in it. >> > > > > >> > > > > Hans, >> > > > > >> > > > > could you please test the following patch? >> > > > > >> > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c >> > > > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 >> > > > > 100644 --- a/sys/dev/acpica/acpi_pci_link.c >> > > > > +++ b/sys/dev/acpica/acpi_pci_link.c >> > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs >> > > > > link->l_irq; >> > > > > else >> > > > > resptr->Data.ExtendedIrq.Interrupts[0] =3D 0; >> > > > > + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, >> > > > > + sizeof(ACPI_RESOURCE_SOURCE)); >> > > > > link++; >> > > > > i++; >> > > > > break; >> > > > >> > > > Hmm... Very interesting. Can you please try this, too? >> > > >> > > Linux doesn't set the resource source bits up at all when doing >> > > _SRS, so I'd rather just do that. I think what I'd prefer is >> > > that we not use the prs_template, perhaps just save the type of >> > > the resource and build a new resource object from scratch where >> > > the resource is zero'd, the appropriate bits are set and then >> > > that resource is appended to the buffer being built. >> > >> > "Linux doesn't do it" is wrong if I am reading the spec. >> > correctly, i.e., _CRS, _PRS and _SRS must have the same format >> > and size. >> >> Umm, but we aren't setting up the raw bits for _SRS. We are >> creating a list of ACPI_RESOURCE objects that ACPICA then encodes >> into a buffer to send to _SRS. > >Yes, I understand. However, ACPICA is expecting the same size of >buffer *including* the optional parts if I am reading the code right. >Besides, I don't think there is any harm in doing the right >thing. ;-) > >Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 21:29:07 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D6571065670; Tue, 2 Nov 2010 21:29:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3725E8FC12; Tue, 2 Nov 2010 21:29:07 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9FD4046B8E; Tue, 2 Nov 2010 17:29:06 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B10258A009; Tue, 2 Nov 2010 17:29:05 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Date: Tue, 2 Nov 2010 17:26:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010121209.06397.hselasky@c2i.net> <201011021624.38882.jhb@freebsd.org> <201011021650.22657.jkim@FreeBSD.org> In-Reply-To: <201011021650.22657.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011021726.37423.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 02 Nov 2010 17:29:05 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: "Moore, Robert" , freebsd-acpi@freebsd.org, Lin Ming , Andriy Gapon Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 21:29:07 -0000 On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: > On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: > > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: > > > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: > > > > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > > > > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > > > > I guess that a general problem here is that it is > > > > > > > incorrect to merely use memcpy/bcopy to create a copy of > > > > > > > a resource if the resource has ACPI_RESOURCE_SOURCE field > > > > > > > in it. > > > > > > > > > > > > Hans, > > > > > > > > > > > > could you please test the following patch? > > > > > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 > > > > > > 100644 --- a/sys/dev/acpica/acpi_pci_link.c > > > > > > +++ b/sys/dev/acpica/acpi_pci_link.c > > > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > > > link->l_irq; > > > > > > else > > > > > > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > > > > > > + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, > > > > > > + sizeof(ACPI_RESOURCE_SOURCE)); > > > > > > link++; > > > > > > i++; > > > > > > break; > > > > > > > > > > Hmm... Very interesting. Can you please try this, too? > > > > > > > > Linux doesn't set the resource source bits up at all when doing > > > > _SRS, so I'd rather just do that. I think what I'd prefer is > > > > that we not use the prs_template, perhaps just save the type of > > > > the resource and build a new resource object from scratch where > > > > the resource is zero'd, the appropriate bits are set and then > > > > that resource is appended to the buffer being built. > > > > > > "Linux doesn't do it" is wrong if I am reading the spec. > > > correctly, i.e., _CRS, _PRS and _SRS must have the same format > > > and size. > > > > Umm, but we aren't setting up the raw bits for _SRS. We are > > creating a list of ACPI_RESOURCE objects that ACPICA then encodes > > into a buffer to send to _SRS. > > Yes, I understand. However, ACPICA is expecting the same size of > buffer *including* the optional parts if I am reading the code right. > Besides, I don't think there is any harm in doing the right > thing. ;-) To be clear, I am suggesting to take an ACPI_RESOURCE object, bzero it, then set the type and the IRQ and that's it. Leave the ResourceSource bits as zero. The size will still be set based on the actual type (or if needed we can use the cached size from the template copy we save from _PRS). The point would be to start from a zero structure instead of from a copy of what we got from _PRS. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 21:50:38 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 509F1106566B; Tue, 2 Nov 2010 21:50:38 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2F8238FC15; Tue, 2 Nov 2010 21:50:36 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA21150; Tue, 02 Nov 2010 23:50:34 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PDOkU-00070d-9Y; Tue, 02 Nov 2010 23:50:34 +0200 Message-ID: <4CD087A9.4000809@freebsd.org> Date: Tue, 02 Nov 2010 23:50:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jung-uk Kim References: <201010121209.06397.hselasky@c2i.net> <201011021614.07631.jkim@FreeBSD.org> <201011021624.38882.jhb@freebsd.org> <201011021650.22657.jkim@FreeBSD.org> In-Reply-To: <201011021650.22657.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Moore, Robert" , freebsd-acpi@freebsd.org, Lin Ming Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 21:50:38 -0000 on 02/11/2010 22:50 Jung-uk Kim said the following: > Yes, I understand. However, ACPICA is expecting the same size of > buffer *including* the optional parts if I am reading the code right. Hmm, where is ACPICA doing that? I didn't see any connection between what *ACPICA* can return to OS in _CRS/_PRS and what OS can pass in _SRS. > Besides, I don't think there is any harm in doing the right > thing. ;-) I don't think that this is any "righter" than zero-ing out resource source description string. BIOS/firmware can't possibly use that for anything meaningful, IMO. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 22:32:32 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id EFC501065695; Tue, 2 Nov 2010 22:32:30 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: John Baldwin Date: Tue, 2 Nov 2010 18:32:12 -0400 User-Agent: KMail/1.6.2 References: <201010121209.06397.hselasky@c2i.net> <201011021650.22657.jkim@FreeBSD.org> <201011021726.37423.jhb@freebsd.org> In-Reply-To: <201011021726.37423.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011021832.22710.jkim@FreeBSD.org> Cc: "Moore, Robert" , freebsd-acpi@freebsd.org, Lin Ming , Andriy Gapon Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 22:32:32 -0000 On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote: > On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: > > On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: > > > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: > > > > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > > > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: > > > > > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > > > > > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > > > > > I guess that a general problem here is that it is > > > > > > > > incorrect to merely use memcpy/bcopy to create a copy > > > > > > > > of a resource if the resource has > > > > > > > > ACPI_RESOURCE_SOURCE field in it. > > > > > > > > > > > > > > Hans, > > > > > > > > > > > > > > could you please test the following patch? > > > > > > > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > > > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 > > > > > > > 100644 --- a/sys/dev/acpica/acpi_pci_link.c > > > > > > > +++ b/sys/dev/acpica/acpi_pci_link.c > > > > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > > > > link->l_irq; > > > > > > > else > > > > > > > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > > > > > > > + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, > > > > > > > + sizeof(ACPI_RESOURCE_SOURCE)); > > > > > > > link++; > > > > > > > i++; > > > > > > > break; > > > > > > > > > > > > Hmm... Very interesting. Can you please try this, too? > > > > > > > > > > Linux doesn't set the resource source bits up at all when > > > > > doing _SRS, so I'd rather just do that. I think what I'd > > > > > prefer is that we not use the prs_template, perhaps just > > > > > save the type of the resource and build a new resource > > > > > object from scratch where the resource is zero'd, the > > > > > appropriate bits are set and then that resource is appended > > > > > to the buffer being built. > > > > > > > > "Linux doesn't do it" is wrong if I am reading the spec. > > > > correctly, i.e., _CRS, _PRS and _SRS must have the same > > > > format and size. > > > > > > Umm, but we aren't setting up the raw bits for _SRS. We are > > > creating a list of ACPI_RESOURCE objects that ACPICA then > > > encodes into a buffer to send to _SRS. > > > > Yes, I understand. However, ACPICA is expecting the same size of > > buffer *including* the optional parts if I am reading the code > > right. Besides, I don't think there is any harm in doing the > > right thing. ;-) > > To be clear, I am suggesting to take an ACPI_RESOURCE object, bzero > it, then set the type and the IRQ and that's it. Leave the > ResourceSource bits as zero. The size will still be set based on > the actual type (or if needed we can use the cached size from the > template copy we save from _PRS). The point would be to start from > a zero structure instead of from a copy of what we got from _PRS. It may work if we don't use l_prs_template. Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 2 23:24:08 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 4BB26106564A; Tue, 2 Nov 2010 23:24:08 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Tue, 2 Nov 2010 19:23:35 -0400 User-Agent: KMail/1.6.2 References: <201010121209.06397.hselasky@c2i.net> <201011021650.22657.jkim@FreeBSD.org> <4CD087A9.4000809@freebsd.org> In-Reply-To: <4CD087A9.4000809@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011021924.00552.jkim@FreeBSD.org> Cc: "Moore, Robert" , freebsd-acpi@freebsd.org, Lin Ming Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 23:24:08 -0000 On Tuesday 02 November 2010 05:50 pm, Andriy Gapon wrote: > on 02/11/2010 22:50 Jung-uk Kim said the following: > > Yes, I understand. However, ACPICA is expecting the same size of > > buffer *including* the optional parts if I am reading the code > > right. > > Hmm, where is ACPICA doing that? If you scrub ResourceSource, then: AcpiSetCurrentResources() -> AcpiRsSetSrsMethodData() -> AcpiRsCreateAmlResources() -> AcpiRsGetAmlLength() -> AcpiRsStructOptionLength() will return 0 and size of new buffer may be smaller than what we got from _CRS. I may have read it wrong, though. :-/ > I didn't see any connection between what *ACPICA* can return to OS > in _CRS/_PRS and what OS can pass in _SRS. > > > Besides, I don't think there is any harm in doing the right > > thing. ;-) > > I don't think that this is any "righter" than zero-ing out resource > source description string. BIOS/firmware can't possibly use that > for anything meaningful, IMO. I didn't say it is ever useful. My point was it may not work for some BIOS but I am not sure, that's all. Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 3 07:43:05 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BEBD106564A; Wed, 3 Nov 2010 07:43:05 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 613F28FC12; Wed, 3 Nov 2010 07:43:03 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=yevn+QCjI6xy199BDvBOOiO14qYvyLq62he9tTtU3M8= c=1 sm=1 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=RBRriF4cpPnANc770RMA:9 a=cz7Tf2TqI69XLjceedBROGzNMBcA:4 a=PUjeQqilurYA:10 a=Ai_k5aZwGu2DL3zR:21 a=fdMMrA_9WYEwGpS1:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 43883870; Wed, 03 Nov 2010 08:43:02 +0100 From: Hans Petter Selasky To: "Jung-uk Kim" Date: Wed, 3 Nov 2010 08:44:13 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201010121209.06397.hselasky@c2i.net> <4CD02E6D.1070106@freebsd.org> <201011021529.05977.jkim@FreeBSD.org> In-Reply-To: <201011021529.05977.jkim@FreeBSD.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011030844.13412.hselasky@c2i.net> Cc: freebsd-acpi@freebsd.org, Lin Ming , Andriy Gapon , "Moore, Robert" Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 07:43:05 -0000 On Tuesday 02 November 2010 20:29:01 Jung-uk Kim wrote: > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > I guess that a general problem here is that it is incorrect to > > > merely use memcpy/bcopy to create a copy of a resource if the > > > resource has ACPI_RESOURCE_SOURCE field in it. > > > > Hans, > > > > could you please test the following patch? > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 > > --- a/sys/dev/acpica/acpi_pci_link.c > > +++ b/sys/dev/acpica/acpi_pci_link.c > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > link->l_irq; > > > > else > > > > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > > > > + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, > > + sizeof(ACPI_RESOURCE_SOURCE)); > > > > link++; > > i++; > > break; > > Hmm... Very interesting. Can you please try this, too? > > Thanks, > > Jung-uk Kim Hi, I will try to get your patches tested in less than 10 hours from now. --HPS From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 3 12:39:24 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 338AF106564A; Wed, 3 Nov 2010 12:39:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E0C268FC16; Wed, 3 Nov 2010 12:39:23 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 74B9B46B2D; Wed, 3 Nov 2010 08:39:23 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 796AE8A01D; Wed, 3 Nov 2010 08:39:22 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Date: Wed, 3 Nov 2010 08:28:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010121209.06397.hselasky@c2i.net> <201011021726.37423.jhb@freebsd.org> <201011021832.22710.jkim@FreeBSD.org> In-Reply-To: <201011021832.22710.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011030828.03108.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 03 Nov 2010 08:39:22 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: "Moore, Robert" , freebsd-acpi@freebsd.org, Lin Ming , Andriy Gapon Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 12:39:24 -0000 On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote: > On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote: > > On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: > > > On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: > > > > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: > > > > > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > > > > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: > > > > > > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > > > > > > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > > > > > > I guess that a general problem here is that it is > > > > > > > > > incorrect to merely use memcpy/bcopy to create a copy > > > > > > > > > of a resource if the resource has > > > > > > > > > ACPI_RESOURCE_SOURCE field in it. > > > > > > > > > > > > > > > > Hans, > > > > > > > > > > > > > > > > could you please test the following patch? > > > > > > > > > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 > > > > > > > > 100644 --- a/sys/dev/acpica/acpi_pci_link.c > > > > > > > > +++ b/sys/dev/acpica/acpi_pci_link.c > > > > > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > > > > > link->l_irq; > > > > > > > > else > > > > > > > > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > > > > > > > > + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, > > > > > > > > + sizeof(ACPI_RESOURCE_SOURCE)); > > > > > > > > link++; > > > > > > > > i++; > > > > > > > > break; > > > > > > > > > > > > > > Hmm... Very interesting. Can you please try this, too? > > > > > > > > > > > > Linux doesn't set the resource source bits up at all when > > > > > > doing _SRS, so I'd rather just do that. I think what I'd > > > > > > prefer is that we not use the prs_template, perhaps just > > > > > > save the type of the resource and build a new resource > > > > > > object from scratch where the resource is zero'd, the > > > > > > appropriate bits are set and then that resource is appended > > > > > > to the buffer being built. > > > > > > > > > > "Linux doesn't do it" is wrong if I am reading the spec. > > > > > correctly, i.e., _CRS, _PRS and _SRS must have the same > > > > > format and size. > > > > > > > > Umm, but we aren't setting up the raw bits for _SRS. We are > > > > creating a list of ACPI_RESOURCE objects that ACPICA then > > > > encodes into a buffer to send to _SRS. > > > > > > Yes, I understand. However, ACPICA is expecting the same size of > > > buffer *including* the optional parts if I am reading the code > > > right. Besides, I don't think there is any harm in doing the > > > right thing. ;-) > > > > To be clear, I am suggesting to take an ACPI_RESOURCE object, bzero > > it, then set the type and the IRQ and that's it. Leave the > > ResourceSource bits as zero. The size will still be set based on > > the actual type (or if needed we can use the cached size from the > > template copy we save from _PRS). The point would be to start from > > a zero structure instead of from a copy of what we got from _PRS. > > It may work if we don't use l_prs_template. Well, we still need much of the info from the _PRS resource (the type, etc.), but I think we should not blindly use the template directly when building the buffer for _SRS. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 3 16:25:56 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 97689106566B; Wed, 3 Nov 2010 16:25:55 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: John Baldwin Date: Wed, 3 Nov 2010 12:25:37 -0400 User-Agent: KMail/1.6.2 References: <201010121209.06397.hselasky@c2i.net> <201011021832.22710.jkim@FreeBSD.org> <201011030828.03108.jhb@freebsd.org> In-Reply-To: <201011030828.03108.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011031225.46128.jkim@FreeBSD.org> Cc: "Moore, Robert" , freebsd-acpi@freebsd.org, Lin Ming , Andriy Gapon Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 16:25:56 -0000 On Wednesday 03 November 2010 08:28 am, John Baldwin wrote: > On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote: > > On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote: > > > On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: > > > > On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: > > > > > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: > > > > > > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > > > > > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: > > > > > > > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > > > > > > > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > > > > > > > I guess that a general problem here is that it is > > > > > > > > > > incorrect to merely use memcpy/bcopy to create a > > > > > > > > > > copy of a resource if the resource has > > > > > > > > > > ACPI_RESOURCE_SOURCE field in it. > > > > > > > > > > > > > > > > > > Hans, > > > > > > > > > > > > > > > > > > could you please test the following patch? > > > > > > > > > > > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c index > > > > > > > > > dcf101d..e842635 100644 --- > > > > > > > > > a/sys/dev/acpica/acpi_pci_link.c +++ > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > > > > > > link->l_irq; > > > > > > > > > else > > > > > > > > > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > > > > > > > > > + memset(&resptr->Data.ExtendedIrq.ResourceSource > > > > > > > > >, 0, + sizeof(ACPI_RESOURCE_SOURCE)); > > > > > > > > > link++; > > > > > > > > > i++; > > > > > > > > > break; > > > > > > > > > > > > > > > > Hmm... Very interesting. Can you please try this, > > > > > > > > too? > > > > > > > > > > > > > > Linux doesn't set the resource source bits up at all > > > > > > > when doing _SRS, so I'd rather just do that. I think > > > > > > > what I'd prefer is that we not use the prs_template, > > > > > > > perhaps just save the type of the resource and build a > > > > > > > new resource object from scratch where the resource is > > > > > > > zero'd, the appropriate bits are set and then that > > > > > > > resource is appended to the buffer being built. > > > > > > > > > > > > "Linux doesn't do it" is wrong if I am reading the spec. > > > > > > correctly, i.e., _CRS, _PRS and _SRS must have the same > > > > > > format and size. > > > > > > > > > > Umm, but we aren't setting up the raw bits for _SRS. We > > > > > are creating a list of ACPI_RESOURCE objects that ACPICA > > > > > then encodes into a buffer to send to _SRS. > > > > > > > > Yes, I understand. However, ACPICA is expecting the same > > > > size of buffer *including* the optional parts if I am reading > > > > the code right. Besides, I don't think there is any harm in > > > > doing the right thing. ;-) > > > > > > To be clear, I am suggesting to take an ACPI_RESOURCE object, > > > bzero it, then set the type and the IRQ and that's it. Leave > > > the ResourceSource bits as zero. The size will still be set > > > based on the actual type (or if needed we can use the cached > > > size from the template copy we save from _PRS). The point > > > would be to start from a zero structure instead of from a copy > > > of what we got from _PRS. > > > > It may work if we don't use l_prs_template. > > Well, we still need much of the info from the _PRS resource (the > type, etc.), but I think we should not blindly use the template > directly when building the buffer for _SRS. Actually, I think we should get the information directly from _CRS as ACPI spec. is suggesting. Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 3 16:48:10 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 228EF1065673; Wed, 3 Nov 2010 16:48:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E43018FC0A; Wed, 3 Nov 2010 16:48:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7A18D46B06; Wed, 3 Nov 2010 12:48:09 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3EFF18A027; Wed, 3 Nov 2010 12:48:08 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Date: Wed, 3 Nov 2010 12:47:55 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010121209.06397.hselasky@c2i.net> <201011030828.03108.jhb@freebsd.org> <201011031225.46128.jkim@FreeBSD.org> In-Reply-To: <201011031225.46128.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011031247.56071.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 03 Nov 2010 12:48:08 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: "Moore, Robert" , freebsd-acpi@freebsd.org, Lin Ming , Andriy Gapon Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 16:48:10 -0000 On Wednesday, November 03, 2010 12:25:37 pm Jung-uk Kim wrote: > On Wednesday 03 November 2010 08:28 am, John Baldwin wrote: > > On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote: > > > On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote: > > > > On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: > > > > > On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: > > > > > > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: > > > > > > > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > > > > > > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim > wrote: > > > > > > > > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon > wrote: > > > > > > > > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > > > > > > > > I guess that a general problem here is that it is > > > > > > > > > > > incorrect to merely use memcpy/bcopy to create a > > > > > > > > > > > copy of a resource if the resource has > > > > > > > > > > > ACPI_RESOURCE_SOURCE field in it. > > > > > > > > > > > > > > > > > > > > Hans, > > > > > > > > > > > > > > > > > > > > could you please test the following patch? > > > > > > > > > > > > > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c index > > > > > > > > > > dcf101d..e842635 100644 --- > > > > > > > > > > a/sys/dev/acpica/acpi_pci_link.c +++ > > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > > > > > > > link->l_irq; > > > > > > > > > > else > > > > > > > > > > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > > > > > > > > > > + memset(&resptr->Data.ExtendedIrq.ResourceSource > > > > > > > > > >, 0, + sizeof(ACPI_RESOURCE_SOURCE)); > > > > > > > > > > link++; > > > > > > > > > > i++; > > > > > > > > > > break; > > > > > > > > > > > > > > > > > > Hmm... Very interesting. Can you please try this, > > > > > > > > > too? > > > > > > > > > > > > > > > > Linux doesn't set the resource source bits up at all > > > > > > > > when doing _SRS, so I'd rather just do that. I think > > > > > > > > what I'd prefer is that we not use the prs_template, > > > > > > > > perhaps just save the type of the resource and build a > > > > > > > > new resource object from scratch where the resource is > > > > > > > > zero'd, the appropriate bits are set and then that > > > > > > > > resource is appended to the buffer being built. > > > > > > > > > > > > > > "Linux doesn't do it" is wrong if I am reading the spec. > > > > > > > correctly, i.e., _CRS, _PRS and _SRS must have the same > > > > > > > format and size. > > > > > > > > > > > > Umm, but we aren't setting up the raw bits for _SRS. We > > > > > > are creating a list of ACPI_RESOURCE objects that ACPICA > > > > > > then encodes into a buffer to send to _SRS. > > > > > > > > > > Yes, I understand. However, ACPICA is expecting the same > > > > > size of buffer *including* the optional parts if I am reading > > > > > the code right. Besides, I don't think there is any harm in > > > > > doing the right thing. ;-) > > > > > > > > To be clear, I am suggesting to take an ACPI_RESOURCE object, > > > > bzero it, then set the type and the IRQ and that's it. Leave > > > > the ResourceSource bits as zero. The size will still be set > > > > based on the actual type (or if needed we can use the cached > > > > size from the template copy we save from _PRS). The point > > > > would be to start from a zero structure instead of from a copy > > > > of what we got from _PRS. > > > > > > It may work if we don't use l_prs_template. > > > > Well, we still need much of the info from the _PRS resource (the > > type, etc.), but I think we should not blindly use the template > > directly when building the buffer for _SRS. > > Actually, I think we should get the information directly from _CRS as > ACPI spec. is suggesting. I would be fine with that, but that does not work if _CRS doesn't work (the acpi_pci_link_srs_from_links() case). Are we allowed to modify the buffer ACPICA gives us from _CRS and then pass that back to _SRS? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 3 17:51:27 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id C6DE0106567A; Wed, 3 Nov 2010 17:51:26 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: John Baldwin Date: Wed, 3 Nov 2010 13:51:06 -0400 User-Agent: KMail/1.6.2 References: <201010121209.06397.hselasky@c2i.net> <201011031225.46128.jkim@FreeBSD.org> <201011031247.56071.jhb@freebsd.org> In-Reply-To: <201011031247.56071.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011031351.18832.jkim@FreeBSD.org> Cc: "Moore, Robert" , freebsd-acpi@freebsd.org, Lin Ming , Andriy Gapon Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 17:51:27 -0000 On Wednesday 03 November 2010 12:47 pm, John Baldwin wrote: > On Wednesday, November 03, 2010 12:25:37 pm Jung-uk Kim wrote: > > On Wednesday 03 November 2010 08:28 am, John Baldwin wrote: > > > On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote: > > > > On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote: > > > > > On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: > > > > > > On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: > > > > > > > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: > > > > > > > > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > > > > > > > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk > > > > > > > > > Kim > > > > wrote: > > > > > > > > > > On Tuesday 02 November 2010 11:29 am, Andriy > > > > > > > > > > Gapon > > > > wrote: > > > > > > > > > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > > > > > > > > > I guess that a general problem here is that > > > > > > > > > > > > it is incorrect to merely use memcpy/bcopy to > > > > > > > > > > > > create a copy of a resource if the resource > > > > > > > > > > > > has ACPI_RESOURCE_SOURCE field in it. > > > > > > > > > > > > > > > > > > > > > > Hans, > > > > > > > > > > > > > > > > > > > > > > could you please test the following patch? > > > > > > > > > > > > > > > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c index > > > > > > > > > > > dcf101d..e842635 100644 --- > > > > > > > > > > > a/sys/dev/acpica/acpi_pci_link.c +++ > > > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > > > > > > > > link->l_irq; > > > > > > > > > > > else > > > > > > > > > > > resptr->Data.ExtendedIrq.Interrupts[0] = > > > > > > > > > > > 0; > > > > > > > > > > > + memset(&resptr->Data.ExtendedIrq.ResourceSo > > > > > > > > > > >urce , 0, + sizeof(ACPI_RESOURCE_SOURCE)); > > > > > > > > > > > link++; > > > > > > > > > > > i++; > > > > > > > > > > > break; > > > > > > > > > > > > > > > > > > > > Hmm... Very interesting. Can you please try > > > > > > > > > > this, too? > > > > > > > > > > > > > > > > > > Linux doesn't set the resource source bits up at > > > > > > > > > all when doing _SRS, so I'd rather just do that. I > > > > > > > > > think what I'd prefer is that we not use the > > > > > > > > > prs_template, perhaps just save the type of the > > > > > > > > > resource and build a new resource object from > > > > > > > > > scratch where the resource is zero'd, the > > > > > > > > > appropriate bits are set and then that resource is > > > > > > > > > appended to the buffer being built. > > > > > > > > > > > > > > > > "Linux doesn't do it" is wrong if I am reading the > > > > > > > > spec. correctly, i.e., _CRS, _PRS and _SRS must have > > > > > > > > the same format and size. > > > > > > > > > > > > > > Umm, but we aren't setting up the raw bits for _SRS. > > > > > > > We are creating a list of ACPI_RESOURCE objects that > > > > > > > ACPICA then encodes into a buffer to send to _SRS. > > > > > > > > > > > > Yes, I understand. However, ACPICA is expecting the same > > > > > > size of buffer *including* the optional parts if I am > > > > > > reading the code right. Besides, I don't think there is > > > > > > any harm in doing the right thing. ;-) > > > > > > > > > > To be clear, I am suggesting to take an ACPI_RESOURCE > > > > > object, bzero it, then set the type and the IRQ and that's > > > > > it. Leave the ResourceSource bits as zero. The size will > > > > > still be set based on the actual type (or if needed we can > > > > > use the cached size from the template copy we save from > > > > > _PRS). The point would be to start from a zero structure > > > > > instead of from a copy of what we got from _PRS. > > > > > > > > It may work if we don't use l_prs_template. > > > > > > Well, we still need much of the info from the _PRS resource > > > (the type, etc.), but I think we should not blindly use the > > > template directly when building the buffer for _SRS. > > > > Actually, I think we should get the information directly from > > _CRS as ACPI spec. is suggesting. > > I would be fine with that, but that does not work if _CRS doesn't > work (the acpi_pci_link_srs_from_links() case). For that case, we must use the template, of course. In fact, my patch is more useful for this particular case. :-) > Are we allowed to modify the buffer ACPICA gives us from _CRS and > then pass that back to _SRS? I believe so. If we go with that route, we don't have to worry about ResourceSource.StringPtr or acpi_AppendBufferResource() copying stale pointers. Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 3 20:25:47 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id E541510657A8; Wed, 3 Nov 2010 20:25:46 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: John Baldwin Date: Wed, 3 Nov 2010 16:25:28 -0400 User-Agent: KMail/1.6.2 References: <201010121209.06397.hselasky@c2i.net> <201011031247.56071.jhb@freebsd.org> <201011031351.18832.jkim@FreeBSD.org> In-Reply-To: <201011031351.18832.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_CVc0MZ2e68ehPVT" Message-Id: <201011031625.38864.jkim@FreeBSD.org> Cc: "Moore, Robert" , freebsd-acpi@freebsd.org, Lin Ming , Andriy Gapon Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 20:25:47 -0000 --Boundary-00=_CVc0MZ2e68ehPVT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 03 November 2010 01:51 pm, Jung-uk Kim wrote: > On Wednesday 03 November 2010 12:47 pm, John Baldwin wrote: > > On Wednesday, November 03, 2010 12:25:37 pm Jung-uk Kim wrote: > > > On Wednesday 03 November 2010 08:28 am, John Baldwin wrote: > > > > On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote: > > > > > On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote: > > > > > > On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: > > > > > > > On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: > > > > > > > > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim > > wrote: > > > > > > > > > On Tuesday 02 November 2010 03:41 pm, John Baldwin > > wrote: > > > > > > > > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk > > > > > > > > > > Kim > > > > > > wrote: > > > > > > > > > > > On Tuesday 02 November 2010 11:29 am, Andriy > > > > > > > > > > > Gapon > > > > > > wrote: > > > > > > > > > > > > on 29/10/2010 08:51 Andriy Gapon said the > > following: > > > > > > > > > > > > > I guess that a general problem here is that > > > > > > > > > > > > > it is incorrect to merely use memcpy/bcopy > > > > > > > > > > > > > to create a copy of a resource if the > > > > > > > > > > > > > resource has ACPI_RESOURCE_SOURCE field in > > > > > > > > > > > > > it. > > > > > > > > > > > > > > > > > > > > > > > > Hans, > > > > > > > > > > > > > > > > > > > > > > > > could you please test the following patch? > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c index > > > > > > > > > > > > dcf101d..e842635 100644 --- > > > > > > > > > > > > a/sys/dev/acpica/acpi_pci_link.c +++ > > > > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > > > > @@ -767,6 +767,8 @@ > > > > > > > > > > > > acpi_pci_link_srs_from_crs link->l_irq; > > > > > > > > > > > > else > > > > > > > > > > > > resptr->Data.ExtendedIrq.Interrupts[0] = > > > > > > > > > > > > 0; > > > > > > > > > > > > + memset(&resptr->Data.ExtendedIrq.Resource > > > > > > > > > > > >So urce , 0, + > > > > > > > > > > > > sizeof(ACPI_RESOURCE_SOURCE)); link++; > > > > > > > > > > > > i++; > > > > > > > > > > > > break; > > > > > > > > > > > > > > > > > > > > > > Hmm... Very interesting. Can you please try > > > > > > > > > > > this, too? > > > > > > > > > > > > > > > > > > > > Linux doesn't set the resource source bits up at > > > > > > > > > > all when doing _SRS, so I'd rather just do that. > > > > > > > > > > I think what I'd prefer is that we not use the > > > > > > > > > > prs_template, perhaps just save the type of the > > > > > > > > > > resource and build a new resource object from > > > > > > > > > > scratch where the resource is zero'd, the > > > > > > > > > > appropriate bits are set and then that resource > > > > > > > > > > is appended to the buffer being built. > > > > > > > > > > > > > > > > > > "Linux doesn't do it" is wrong if I am reading the > > > > > > > > > spec. correctly, i.e., _CRS, _PRS and _SRS must > > > > > > > > > have the same format and size. > > > > > > > > > > > > > > > > Umm, but we aren't setting up the raw bits for _SRS. > > > > > > > > We are creating a list of ACPI_RESOURCE objects that > > > > > > > > ACPICA then encodes into a buffer to send to _SRS. > > > > > > > > > > > > > > Yes, I understand. However, ACPICA is expecting the > > > > > > > same size of buffer *including* the optional parts if I > > > > > > > am reading the code right. Besides, I don't think there > > > > > > > is any harm in doing the right thing. ;-) > > > > > > > > > > > > To be clear, I am suggesting to take an ACPI_RESOURCE > > > > > > object, bzero it, then set the type and the IRQ and > > > > > > that's it. Leave the ResourceSource bits as zero. The > > > > > > size will still be set based on the actual type (or if > > > > > > needed we can use the cached size from the template copy > > > > > > we save from _PRS). The point would be to start from a > > > > > > zero structure instead of from a copy of what we got from > > > > > > _PRS. > > > > > > > > > > It may work if we don't use l_prs_template. > > > > > > > > Well, we still need much of the info from the _PRS resource > > > > (the type, etc.), but I think we should not blindly use the > > > > template directly when building the buffer for _SRS. > > > > > > Actually, I think we should get the information directly from > > > _CRS as ACPI spec. is suggesting. > > > > I would be fine with that, but that does not work if _CRS doesn't > > work (the acpi_pci_link_srs_from_links() case). > > For that case, we must use the template, of course. In fact, my > patch is more useful for this particular case. :-) > > > Are we allowed to modify the buffer ACPICA gives us from _CRS and > > then pass that back to _SRS? > > I believe so. If we go with that route, we don't have to worry > about ResourceSource.StringPtr or acpi_AppendBufferResource() > copying stale pointers. Please see the attached patch. It seems working fine. :-) Note I had to adjust resource length to prevent reading/writing beyond buffer size. It should work okay for acpi_pci_link_srs_from_links() case, I believe. It's a hack anyway. ;-) Jung-uk Kim --Boundary-00=_CVc0MZ2e68ehPVT Content-Type: text/plain; charset="iso-8859-1"; name="acpi_pci_link2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="acpi_pci_link2.diff" --- sys/dev/acpica/acpi_pci_link.c 2010-03-05 15:07:53.000000000 -0500 +++ sys/dev/acpica/acpi_pci_link.c 2010-11-03 16:09:40.000000000 -0400 @@ -268,6 +268,7 @@ link_add_crs(ACPI_RESOURCE *res, void *c static ACPI_STATUS link_add_prs(ACPI_RESOURCE *res, void *context) { + ACPI_RESOURCE *tmp; struct link_res_request *req; struct link *link; UINT8 *irqs = NULL; @@ -321,8 +322,17 @@ link_add_prs(ACPI_RESOURCE *res, void *c * Stash a copy of the resource for later use when doing * _SRS. */ - bcopy(res, &link->l_prs_template, sizeof(ACPI_RESOURCE)); + tmp = &link->l_prs_template; + bcopy(res, tmp, sizeof(*res)); if (is_ext_irq) { + /* + * XXX acpi_AppendBufferResource() cannot handle + * optional ResourceSource. + */ + bzero(&tmp->Data.ExtendedIrq.ResourceSource, + sizeof(tmp->Data.ExtendedIrq.ResourceSource)); + tmp->Length = sizeof(tmp->Data.ExtendedIrq); + link->l_num_irqs = res->Data.ExtendedIrq.InterruptCount; ext_irqs = res->Data.ExtendedIrq.Interrupts; @@ -688,18 +698,17 @@ acpi_pci_link_add_reference(device_t dev static ACPI_STATUS acpi_pci_link_srs_from_crs(struct acpi_pci_link_softc *sc, ACPI_BUFFER *srsbuf) { - ACPI_RESOURCE *resource, *end, newres, *resptr; - ACPI_BUFFER crsbuf; + ACPI_RESOURCE *end, *res; ACPI_STATUS status; struct link *link; int i, in_dpf; /* Fetch the _CRS. */ ACPI_SERIAL_ASSERT(pci_link); - crsbuf.Pointer = NULL; - crsbuf.Length = ACPI_ALLOCATE_BUFFER; - status = AcpiGetCurrentResources(acpi_get_handle(sc->pl_dev), &crsbuf); - if (ACPI_SUCCESS(status) && crsbuf.Pointer == NULL) + srsbuf->Pointer = NULL; + srsbuf->Length = ACPI_ALLOCATE_BUFFER; + status = AcpiGetCurrentResources(acpi_get_handle(sc->pl_dev), srsbuf); + if (ACPI_SUCCESS(status) && srsbuf->Pointer == NULL) status = AE_NO_MEMORY; if (ACPI_FAILURE(status)) { if (bootverbose) @@ -710,14 +719,13 @@ acpi_pci_link_srs_from_crs(struct acpi_p } /* Fill in IRQ resources via link structures. */ - srsbuf->Pointer = NULL; link = sc->pl_links; i = 0; in_dpf = DPF_OUTSIDE; - resource = (ACPI_RESOURCE *)crsbuf.Pointer; - end = (ACPI_RESOURCE *)((char *)crsbuf.Pointer + crsbuf.Length); + res = (ACPI_RESOURCE *)srsbuf->Pointer; + end = (ACPI_RESOURCE *)((char *)srsbuf->Pointer + srsbuf->Length); for (;;) { - switch (resource->Type) { + switch (res->Type) { case ACPI_RESOURCE_TYPE_START_DEPENDENT: switch (in_dpf) { case DPF_OUTSIDE: @@ -731,67 +739,44 @@ acpi_pci_link_srs_from_crs(struct acpi_p __func__); break; } - resptr = NULL; break; case ACPI_RESOURCE_TYPE_END_DEPENDENT: /* We are finished with DPF parsing. */ KASSERT(in_dpf != DPF_OUTSIDE, ("%s: end dpf when not parsing a dpf", __func__)); in_dpf = DPF_OUTSIDE; - resptr = NULL; break; case ACPI_RESOURCE_TYPE_IRQ: MPASS(i < sc->pl_num_links); - MPASS(link->l_prs_template.Type == ACPI_RESOURCE_TYPE_IRQ); - newres = link->l_prs_template; - resptr = &newres; - resptr->Data.Irq.InterruptCount = 1; + res->Data.Irq.InterruptCount = 1; if (PCI_INTERRUPT_VALID(link->l_irq)) { KASSERT(link->l_irq < NUM_ISA_INTERRUPTS, ("%s: can't put non-ISA IRQ %d in legacy IRQ resource type", __func__, link->l_irq)); - resptr->Data.Irq.Interrupts[0] = link->l_irq; + res->Data.Irq.Interrupts[0] = link->l_irq; } else - resptr->Data.Irq.Interrupts[0] = 0; + res->Data.Irq.Interrupts[0] = 0; link++; i++; break; case ACPI_RESOURCE_TYPE_EXTENDED_IRQ: MPASS(i < sc->pl_num_links); - MPASS(link->l_prs_template.Type == ACPI_RESOURCE_TYPE_EXTENDED_IRQ); - newres = link->l_prs_template; - resptr = &newres; - resptr->Data.ExtendedIrq.InterruptCount = 1; + res->Data.ExtendedIrq.InterruptCount = 1; if (PCI_INTERRUPT_VALID(link->l_irq)) - resptr->Data.ExtendedIrq.Interrupts[0] = + res->Data.ExtendedIrq.Interrupts[0] = link->l_irq; else - resptr->Data.ExtendedIrq.Interrupts[0] = 0; + res->Data.ExtendedIrq.Interrupts[0] = 0; link++; i++; break; - default: - resptr = resource; } - if (resptr != NULL) { - status = acpi_AppendBufferResource(srsbuf, resptr); - if (ACPI_FAILURE(status)) { - device_printf(sc->pl_dev, - "Unable to build resources: %s\n", - AcpiFormatException(status)); - if (srsbuf->Pointer != NULL) - AcpiOsFree(srsbuf->Pointer); - AcpiOsFree(crsbuf.Pointer); - return (status); - } - } - if (resource->Type == ACPI_RESOURCE_TYPE_END_TAG) + if (res->Type == ACPI_RESOURCE_TYPE_END_TAG) break; - resource = ACPI_NEXT_RESOURCE(resource); - if (resource >= end) + res = ACPI_NEXT_RESOURCE(res); + if (res >= end) break; } - AcpiOsFree(crsbuf.Pointer); return (AE_OK); } --Boundary-00=_CVc0MZ2e68ehPVT-- From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 3 20:50:18 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 9AAE0106566B; Wed, 3 Nov 2010 20:50:17 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Wed, 3 Nov 2010 16:49:59 -0400 User-Agent: KMail/1.6.2 References: <201010121209.06397.hselasky@c2i.net> <201011031351.18832.jkim@FreeBSD.org> <201011031625.38864.jkim@FreeBSD.org> In-Reply-To: <201011031625.38864.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011031650.01869.jkim@FreeBSD.org> Cc: Andriy Gapon , Lin Ming , "Moore, Robert" Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 20:50:18 -0000 On Wednesday 03 November 2010 04:25 pm, Jung-uk Kim wrote: > Note I had to adjust resource length to prevent reading/writing > beyond buffer size. It should work okay for > acpi_pci_link_srs_from_links() case, I believe. It's a hack > anyway. ;-) I realized two MPASS() checks were removed accidentally. They are still valid, so they won't be removed in the actual commit if it works and everyone agrees. Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 3 21:12:30 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B995E106566B; Wed, 3 Nov 2010 21:12:30 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9512A8FC14; Wed, 3 Nov 2010 21:12:29 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA14335; Wed, 03 Nov 2010 23:12:28 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PDkd9-000ArV-Pp; Wed, 03 Nov 2010 23:12:27 +0200 Message-ID: <4CD1D03B.2010606@freebsd.org> Date: Wed, 03 Nov 2010 23:12:27 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jung-uk Kim References: <201010121209.06397.hselasky@c2i.net> <201011031351.18832.jkim@FreeBSD.org> <201011031625.38864.jkim@FreeBSD.org> <201011031650.01869.jkim@FreeBSD.org> In-Reply-To: <201011031650.01869.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 21:12:30 -0000 on 03/11/2010 22:49 Jung-uk Kim said the following: > On Wednesday 03 November 2010 04:25 pm, Jung-uk Kim wrote: >> Note I had to adjust resource length to prevent reading/writing >> beyond buffer size. It should work okay for >> acpi_pci_link_srs_from_links() case, I believe. It's a hack >> anyway. ;-) > > I realized two MPASS() checks were removed accidentally. They are > still valid, so they won't be removed in the actual commit if it > works and everyone agrees. I guess we are mostly waiting for hps's testing at this point? Whom mysteriously has already disappeared from the cc-list :-) On the other hand, I think there is no reason to keep Robert and Lin Ming (sorry couldn't tell what is the first name and what is the last name) on this quite technical discussion of this now very FreeBSD-specific issue. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 4 04:50:26 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E26D1065673; Thu, 4 Nov 2010 04:50:26 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx1.freebsd.org (Postfix) with ESMTP id 04D948FC12; Thu, 4 Nov 2010 04:50:25 +0000 (UTC) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 03 Nov 2010 21:50:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.58,293,1286175600"; d="scan'208";a="623385120" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by fmsmga002.fm.intel.com with ESMTP; 03 Nov 2010 21:50:15 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.226.213) by orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 3 Nov 2010 21:50:15 -0700 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx601.amr.corp.intel.com ([10.22.226.213]) with mapi; Wed, 3 Nov 2010 21:50:15 -0700 From: "Moore, Robert" To: Jung-uk Kim , "freebsd-acpi@FreeBSD.org" Date: Wed, 3 Nov 2010 21:50:14 -0700 Thread-Topic: MacBookPro 5,1 Thread-Index: Act7mL5mgEKePTp5Qd6JZ2pP697SbwAQkZyg Message-ID: <4911F71203A09E4D9981D27F9D830858BC469ABD@orsmsx503.amr.corp.intel.com> References: <201010121209.06397.hselasky@c2i.net> <201011031351.18832.jkim@FreeBSD.org> <201011031625.38864.jkim@FreeBSD.org> <201011031650.01869.jkim@FreeBSD.org> In-Reply-To: <201011031650.01869.jkim@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Brown , "Lin, Ming M" , Andriy Gapon , Len Subject: RE: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 04:50:26 -0000 We are interested here. Our goal is to simplify your ACPI implementation. I've we've screwed up, tell us. If we can help in ACPICA, please let us know. We have at least 2 software e= ngineers that are full-time on this project. Robert B Moore Intel Corporation >-----Original Message----- >From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >acpi@freebsd.org] On Behalf Of Jung-uk Kim >Sent: Wednesday, November 03, 2010 1:50 PM >To: freebsd-acpi@FreeBSD.org >Cc: Andriy Gapon; Lin, Ming M; Moore, Robert >Subject: Re: MacBookPro 5,1 > >On Wednesday 03 November 2010 04:25 pm, Jung-uk Kim wrote: >> Note I had to adjust resource length to prevent reading/writing >> beyond buffer size. It should work okay for >> acpi_pci_link_srs_from_links() case, I believe. It's a hack >> anyway. ;-) > >I realized two MPASS() checks were removed accidentally. They are >still valid, so they won't be removed in the actual commit if it >works and everyone agrees. > >Jung-uk Kim >_______________________________________________ >freebsd-acpi@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 4 07:43:09 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B65771065722; Thu, 4 Nov 2010 07:43:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id DFF068FC08; Thu, 4 Nov 2010 07:43:08 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=YVWlvYxprtm3eZkTSn8A:9 a=MD6KUaXlHPFlIH-rEaqQEoxC81YA:4 a=PUjeQqilurYA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 43862100; Thu, 04 Nov 2010 08:43:06 +0100 From: Hans Petter Selasky To: "Jung-uk Kim" , freebsd-acpi@freebsd.org Date: Thu, 4 Nov 2010 08:44:17 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201010121209.06397.hselasky@c2i.net> <4CD02E6D.1070106@freebsd.org> <201011021529.05977.jkim@FreeBSD.org> In-Reply-To: <201011021529.05977.jkim@FreeBSD.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011040844.17109.hselasky@c2i.net> Cc: Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 07:43:09 -0000 On Tuesday 02 November 2010 20:29:01 Jung-uk Kim wrote: > > Hans, > > > > could you please test the following patch? > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 > > --- a/sys/dev/acpica/acpi_pci_link.c > > +++ b/sys/dev/acpica/acpi_pci_link.c > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > link->l_irq; > > else > > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > > > > + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, > > + sizeof(ACPI_RESOURCE_SOURCE)); > > > > link++; > > i++; > > break; The "Bug" statements disappeared with this patch! Which patch is next to try? --HPS From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 4 07:48:56 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA3571065674; Thu, 4 Nov 2010 07:48:56 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 4EBAD8FC18; Thu, 4 Nov 2010 07:48:54 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=gl0LPzB4YDQuuzpDoHYit7deEV0cOo++Sg28kyvF6vg= c=1 sm=1 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=rW1h7RCZl3BHQJt7948A:9 a=zWoYtayFVqiKAM4tiDK4RKWMj9cA:4 a=PUjeQqilurYA:10 a=_e-PnofileROuYtC:21 a=Rf4u6i7AX05FFheI:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44192821; Thu, 04 Nov 2010 08:48:53 +0100 From: Hans Petter Selasky To: "Jung-uk Kim" Date: Thu, 4 Nov 2010 08:50:04 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201010121209.06397.hselasky@c2i.net> <201011031351.18832.jkim@FreeBSD.org> <201011031625.38864.jkim@FreeBSD.org> In-Reply-To: <201011031625.38864.jkim@FreeBSD.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011040850.04401.hselasky@c2i.net> Cc: freebsd-acpi@freebsd.org, Lin Ming , Andriy Gapon , "Moore, Robert" Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 07:48:56 -0000 On Wednesday 03 November 2010 21:25:28 Jung-uk Kim wrote: > On Wednesday 03 November 2010 01:51 pm, Jung-uk Kim wrote: > > On Wednesday 03 November 2010 12:47 pm, John Baldwin wrote: > > > On Wednesday, November 03, 2010 12:25:37 pm Jung-uk Kim wrote: > > > > On Wednesday 03 November 2010 08:28 am, John Baldwin wrote: > > > > > On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote: > > > > > > On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote: > > > > > > > On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim > > > > > > > > > > > > > > > > > > > > > > Linux doesn't set the resource source bits up at > > > > > > > > > > > all when doing _SRS, so I'd rather just do that. > > > > > > > > > > > I think what I'd prefer is that we not use the > > > > > > > > > > > prs_template, perhaps just save the type of the > > > > > > > > > > > resource and build a new resource object from > > > > > > > > > > > scratch where the resource is zero'd, the > > > > > > > > > > > appropriate bits are set and then that resource > > > > > > > > > > > is appended to the buffer being built. > > > > > > > > > > > > > > > > > > > > "Linux doesn't do it" is wrong if I am reading the > > > > > > > > > > spec. correctly, i.e., _CRS, _PRS and _SRS must > > > > > > > > > > have the same format and size. > > > > > > > > > > > > > > > > > > Umm, but we aren't setting up the raw bits for _SRS. > > > > > > > > > We are creating a list of ACPI_RESOURCE objects that > > > > > > > > > ACPICA then encodes into a buffer to send to _SRS. > > > > > > > > > > > > > > > > Yes, I understand. However, ACPICA is expecting the > > > > > > > > same size of buffer *including* the optional parts if I > > > > > > > > am reading the code right. Besides, I don't think there > > > > > > > > is any harm in doing the right thing. ;-) > > > > > > > > > > > > > > To be clear, I am suggesting to take an ACPI_RESOURCE > > > > > > > object, bzero it, then set the type and the IRQ and > > > > > > > that's it. Leave the ResourceSource bits as zero. The > > > > > > > size will still be set based on the actual type (or if > > > > > > > needed we can use the cached size from the template copy > > > > > > > we save from _PRS). The point would be to start from a > > > > > > > zero structure instead of from a copy of what we got from > > > > > > > _PRS. > > > > > > > > > > > > It may work if we don't use l_prs_template. > > > > > > > > > > Well, we still need much of the info from the _PRS resource > > > > > (the type, etc.), but I think we should not blindly use the > > > > > template directly when building the buffer for _SRS. > > > > > > > > Actually, I think we should get the information directly from > > > > _CRS as ACPI spec. is suggesting. > > > > > > I would be fine with that, but that does not work if _CRS doesn't > > > work (the acpi_pci_link_srs_from_links() case). > > > > For that case, we must use the template, of course. In fact, my > > patch is more useful for this particular case. :-) > > > > > Are we allowed to modify the buffer ACPICA gives us from _CRS and > > > then pass that back to _SRS? > > > > I believe so. If we go with that route, we don't have to worry > > about ResourceSource.StringPtr or acpi_AppendBufferResource() > > copying stale pointers. > > Please see the attached patch. It seems working fine. :-) > > Note I had to adjust resource length to prevent reading/writing beyond > buffer size. It should work okay for acpi_pci_link_srs_from_links() > case, I believe. It's a hack anyway. ;-) > Hi, The acpi_pci_link2.diff patch also works fine. No more "Bug" statements as per Lin and Moore's debug patch. The patch was tested separately from the "memset()" patch. Both patches work. --HPS From owner-freebsd-acpi@FreeBSD.ORG Fri Nov 5 02:24:01 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BA3C106564A; Fri, 5 Nov 2010 02:24:01 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id 0499A8FC13; Fri, 5 Nov 2010 02:24:00 +0000 (UTC) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 04 Nov 2010 19:24:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.58,299,1286175600"; d="scan'208";a="344906026" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by azsmga001.ch.intel.com with ESMTP; 04 Nov 2010 19:24:00 -0700 Received: from orsmsx606.amr.corp.intel.com (10.22.226.128) by orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 4 Nov 2010 19:23:59 -0700 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx606.amr.corp.intel.com ([10.22.226.128]) with mapi; Thu, 4 Nov 2010 19:23:59 -0700 From: "Moore, Robert" To: Hans Petter Selasky , Jung-uk Kim , "freebsd-acpi@freebsd.org" Date: Thu, 4 Nov 2010 19:23:58 -0700 Thread-Topic: MacBookPro 5,1 Thread-Index: Act78/xATnxsujcQTGeF1xiG0DQ7CgAm1KMQ Message-ID: <4911F71203A09E4D9981D27F9D830858BC46A471@orsmsx503.amr.corp.intel.com> References: <201010121209.06397.hselasky@c2i.net> <4CD02E6D.1070106@freebsd.org> <201011021529.05977.jkim@FreeBSD.org> <201011040844.17109.hselasky@c2i.net> In-Reply-To: <201011040844.17109.hselasky@c2i.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 02:24:01 -0000 You cannot assume that a full memcpy has been performed on the structure wh= en you invoke the equals operator. This is basic C >-----Original Message----- >From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >acpi@freebsd.org] On Behalf Of Hans Petter Selasky >Sent: Thursday, November 04, 2010 12:44 AM >To: Jung-uk Kim; freebsd-acpi@freebsd.org >Subject: Re: MacBookPro 5,1 > >On Tuesday 02 November 2010 20:29:01 Jung-uk Kim wrote: >> > Hans, >> > >> > could you please test the following patch? >> > >> > diff --git a/sys/dev/acpica/acpi_pci_link.c >> > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 >> > --- a/sys/dev/acpica/acpi_pci_link.c >> > +++ b/sys/dev/acpica/acpi_pci_link.c >> > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs >> > >> > link->l_irq; >> > else >> > resptr->Data.ExtendedIrq.Interrupts[0] = =3D >0; >> > >> > + memset(&resptr->Data.ExtendedIrq.ResourceSource, >0, >> > + sizeof(ACPI_RESOURCE_SOURCE)); >> > >> > link++; >> > i++; >> > break; > >The "Bug" statements disappeared with this patch! Which patch is next to >try? > >--HPS >_______________________________________________ >freebsd-acpi@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Fri Nov 5 03:57:55 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FE6D106564A; Fri, 5 Nov 2010 03:57:55 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mx1.freebsd.org (Postfix) with ESMTP id 3220D8FC15; Fri, 5 Nov 2010 03:57:54 +0000 (UTC) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 04 Nov 2010 20:57:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.58,300,1286175600"; d="scan'208";a="674540892" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by orsmga001.jf.intel.com with ESMTP; 04 Nov 2010 20:57:54 -0700 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx603.amr.corp.intel.com ([10.22.226.49]) with mapi; Thu, 4 Nov 2010 20:57:54 -0700 From: "Moore, Robert" To: "Moore, Robert" , Hans Petter Selasky , Jung-uk Kim , "freebsd-acpi@freebsd.org" Date: Thu, 4 Nov 2010 20:57:53 -0700 Thread-Topic: MacBookPro 5,1 Thread-Index: Act78/xATnxsujcQTGeF1xiG0DQ7CgAm1KMQAANcfwA= Message-ID: <4911F71203A09E4D9981D27F9D830858BC46A4B1@orsmsx503.amr.corp.intel.com> References: <201010121209.06397.hselasky@c2i.net> <4CD02E6D.1070106@freebsd.org> <201011021529.05977.jkim@FreeBSD.org> <201011040844.17109.hselasky@c2i.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Therien, Guy" Subject: RE: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 03:57:55 -0000 The problem is stale pointers within the structure, yes? Cannot copy the structure. I will never do this kind of thing again. When ACPICA was designed 12 years ago, memory was expensive. Bob >-----Original Message----- >From: Moore, Robert >Sent: Thursday, November 04, 2010 7:24 PM >To: 'Hans Petter Selasky'; Jung-uk Kim; freebsd-acpi@freebsd.org >Subject: RE: MacBookPro 5,1 > > >You cannot assume that a full memcpy has been performed on the structure >when you invoke the equals operator. > >This is basic C > > > > > >>-----Original Message----- >>From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>acpi@freebsd.org] On Behalf Of Hans Petter Selasky >>Sent: Thursday, November 04, 2010 12:44 AM >>To: Jung-uk Kim; freebsd-acpi@freebsd.org >>Subject: Re: MacBookPro 5,1 >> >>On Tuesday 02 November 2010 20:29:01 Jung-uk Kim wrote: >>> > Hans, >>> > >>> > could you please test the following patch? >>> > >>> > diff --git a/sys/dev/acpica/acpi_pci_link.c >>> > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 >>> > --- a/sys/dev/acpica/acpi_pci_link.c >>> > +++ b/sys/dev/acpica/acpi_pci_link.c >>> > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs >>> > >>> > link->l_irq; >>> > else >>> > resptr->Data.ExtendedIrq.Interrupts[0] = =3D >>0; >>> > >>> > + memset(&resptr->Data.ExtendedIrq.ResourceSource= , >>0, >>> > + sizeof(ACPI_RESOURCE_SOURCE)); >>> > >>> > link++; >>> > i++; >>> > break; >> >>The "Bug" statements disappeared with this patch! Which patch is next to >>try? >> >>--HPS >>_______________________________________________ >>freebsd-acpi@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Fri Nov 5 20:15:32 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 7CB91106566C; Fri, 5 Nov 2010 20:15:32 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Fri, 5 Nov 2010 16:14:53 -0400 User-Agent: KMail/1.6.2 References: <201010121209.06397.hselasky@c2i.net> In-Reply-To: <201010121209.06397.hselasky@c2i.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051615.24705.jkim@FreeBSD.org> Cc: "Moore, Robert" , jhb@FreeBSD.org, avg@FreeBSD.org Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 20:15:32 -0000 On Tuesday 12 October 2010 06:09 am, Hans Petter Selasky wrote: > Hi, > > My MacBookPro 5,1 does not boot using -current because memory > inside the ACPI kernel module is used after free. > > The following patch temporily mitigates the problem: > > /usr/src/sys/dev/acpica/Osd/OsdMemory.c > > void > AcpiOsFree(void *Memory) > { > + if (cold == 0) > free(Memory, M_ACPICA); > } > > Is there any way to debug this from user-land? FYI, this problem should be fixed in r214848. While I am here, I'd like to give many thanks to hps for trying out patches, to avg for the great in-depth analysis and initial patch, to ACPICA developers for continuous support and invaluable comments! Thank you, all folks! Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Fri Nov 5 20:26:35 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 3D4581065673; Fri, 5 Nov 2010 20:26:34 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Fri, 5 Nov 2010 16:26:19 -0400 User-Agent: KMail/1.6.2 References: <201010121209.06397.hselasky@c2i.net> <201011051615.24705.jkim@FreeBSD.org> In-Reply-To: <201011051615.24705.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051626.26913.jkim@FreeBSD.org> Cc: "Moore, Robert" , jhb@FreeBSD.org, avg@FreeBSD.org Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 20:26:35 -0000 On Friday 05 November 2010 04:14 pm, Jung-uk Kim wrote: > On Tuesday 12 October 2010 06:09 am, Hans Petter Selasky wrote: > > Hi, > > > > My MacBookPro 5,1 does not boot using -current because memory > > inside the ACPI kernel module is used after free. > > > > The following patch temporily mitigates the problem: > > > > /usr/src/sys/dev/acpica/Osd/OsdMemory.c > > > > void > > AcpiOsFree(void *Memory) > > { > > + if (cold == 0) > > free(Memory, M_ACPICA); > > } > > > > Is there any way to debug this from user-land? > > FYI, this problem should be fixed in r214848. And r214849. I forgot to change one line. :-( Sorry, Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Fri Nov 5 20:31:44 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63B6010656A3 for ; Fri, 5 Nov 2010 20:31:44 +0000 (UTC) (envelope-from judmarc@fastmail.fm) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2B87B8FC1A for ; Fri, 5 Nov 2010 20:31:43 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 588254D5; Fri, 5 Nov 2010 16:31:43 -0400 (EDT) Received: from web2.messagingengine.com ([10.202.2.212]) by compute3.internal (MEProxy); Fri, 05 Nov 2010 16:31:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:from:to:cc:mime-version:content-transfer-encoding:content-type:references:subject:in-reply-to:date; s=smtpout; bh=9fewMvkrqDARW1tCzpPbbHJkagA=; b=PhIBzuXPX33h8sq7PWikTGMKIY1yAXFGH5YnBVFAX1hM5qQrZySw9RXfoCSUTLFcBFCV9TlH7cZps6KamhUJavoIg8Ckadlb/5zPtM8soT3EViAjRaX/Qhl0LjJts4DnXwUT3hLOUSvdc/LsYLTvTJx9eEFPeqeWn+v4gqF7M90= Received: by web2.messagingengine.com (Postfix, from userid 99) id 11F81B31981; Fri, 5 Nov 2010 16:31:43 -0400 (EDT) Message-Id: <1288989102.26864.1403831935@webmail.messagingengine.com> X-Sasl-Enc: OIHOmQNuRCqnWWL07vylU4rwIeI52D2KxeadLPUBMGEK 1288989102 From: "Jud" To: "Jung-uk Kim" , "freebsd-acpi" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface References: <201010121209.06397.hselasky@c2i.net> <201011051615.24705.jkim@FreeBSD.org> In-Reply-To: <201011051615.24705.jkim@FreeBSD.org> Date: Fri, 05 Nov 2010 16:31:42 -0400 Cc: avg@FreeBSD.org Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 20:31:44 -0000 On Fri, 05 Nov 2010 16:14 -0400, "Jung-uk Kim" wrote: > On Tuesday 12 October 2010 06:09 am, Hans Petter Selasky wrote: > > Hi, > > > > My MacBookPro 5,1 does not boot using -current because memory > > inside the ACPI kernel module is used after free. > > > > The following patch temporily mitigates the problem: > > > > /usr/src/sys/dev/acpica/Osd/OsdMemory.c > > > > void > > AcpiOsFree(void *Memory) > > { > > + if (cold == 0) > > free(Memory, M_ACPICA); > > } > > > > Is there any way to debug this from user-land? > > FYI, this problem should be fixed in r214848. > > While I am here, I'd like to give many thanks to hps for trying out > patches, to avg for the great in-depth analysis and initial patch, to > ACPICA developers for continuous support and invaluable comments! > > Thank you, all folks! Let me add my grateful thanks (to Jung-uk Kim as well). I've been looking forward to installing FreeBSD on my MacBook Pro 5,5 for quite a while, and to judge from various forums, so have other owners of certain MacBook Pro models. Jud -- "I'd take the awe of understanding over the awe of ignorance any day." - Douglas Adams From owner-freebsd-acpi@FreeBSD.ORG Sat Nov 6 10:10:58 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10E1E106564A; Sat, 6 Nov 2010 10:10:58 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1B1748FC0A; Sat, 6 Nov 2010 10:10:56 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA27435; Sat, 06 Nov 2010 12:10:49 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PEfjU-000MKn-RE; Sat, 06 Nov 2010 12:10:48 +0200 Message-ID: <4CD529A7.7080206@icyb.net.ua> Date: Sat, 06 Nov 2010 12:10:47 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Moore, Robert" References: <201010121209.06397.hselasky@c2i.net> <4CD02E6D.1070106@freebsd.org> <201011021529.05977.jkim@FreeBSD.org> <201011040844.17109.hselasky@c2i.net> <4911F71203A09E4D9981D27F9D830858BC46A4B1@orsmsx503.amr.corp.intel.com> In-Reply-To: <4911F71203A09E4D9981D27F9D830858BC46A4B1@orsmsx503.amr.corp.intel.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Therien, Guy" , "freebsd-acpi@freebsd.org" Subject: Re: MacBookPro 5,1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:10:58 -0000 on 05/11/2010 05:57 Moore, Robert said the following: > The problem is stale pointers within the structure, yes? > > Cannot copy the structure. I will never do this kind of thing again. Yes, that was the problem with resource structs that have an ACPI_RESOURCE_SOURCE field, that field would need a deep copy to handle StringPtr in it. Perhaps ACPICA could provide a convenience function for resource copying? Perhaps with an option to carry on optional fields like ACPI_RESOURCE_SOURCE or resetting them? Thank you. -- Andriy Gapon