From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 11:06:58 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D07316A401 for ; Mon, 25 Feb 2008 11:06:58 +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 4085213C458 for ; Mon, 25 Feb 2008 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1PB6wwH032886 for ; Mon, 25 Feb 2008 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1PB6vQv032882 for freebsd-acpi@FreeBSD.org; Mon, 25 Feb 2008 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Feb 2008 11:06:57 GMT Message-Id: <200802251106.m1PB6vQv032882@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, 25 Feb 2008 11:06:58 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/114113 acpi [acpi] [patch] ACPI kernel panic during S3 suspend / r o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o amd64/115011 acpi ACPI problem ,reboot system down. o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o bin/118973 acpi [acpi]: Kernel panic with acpi boot o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/120953 acpi [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is 20 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 s kern/73823 acpi [request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o kern/89411 acpi [acpi] acpiconf bug o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI o kern/98171 acpi [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop o kern/103365 acpi [acpi] acpi poweroff doesn't work with geli device att o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/111591 acpi [acpi] dev.acpi_ibm.0.events returns I/O error (regres o kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/114165 acpi [acpi] Dell C810 - ACPI problem o kern/114649 acpi [patch][acpi] panic: recursed on non-recursive mutex o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o amd64/120568 acpi cannot install 7.0-rc1: ACPI problem with abit ip35 pr 20 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 11:28:03 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3F6316A404; Mon, 25 Feb 2008 11:28:03 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7B4FF13C45B; Mon, 25 Feb 2008 11:28:03 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1PBS3md038135; Mon, 25 Feb 2008 11:28:03 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1PBS3Lc038131; Mon, 25 Feb 2008 11:28:03 GMT (envelope-from gavin) Date: Mon, 25 Feb 2008 11:28:03 GMT Message-Id: <200802251128.m1PBS3Lc038131@freefall.freebsd.org> To: trondsg@gmail.com, gavin@FreeBSD.org, gavin@FreeBSD.org, freebsd-acpi@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/90243: Laptop fan doesn't turn off (ACPI enabled) (Packard Bell EasyNote E3245) 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, 25 Feb 2008 11:28:03 -0000 Synopsis: Laptop fan doesn't turn off (ACPI enabled) (Packard Bell EasyNote E3245) State-Changed-From-To: feedback->suspended State-Changed-By: gavin State-Changed-When: Mon Feb 25 11:25:21 UTC 2008 State-Changed-Why: Mark suspended as submitter is unable to test again to confirm if this is still an issue Responsible-Changed-From-To: gavin->freebsd-acpi Responsible-Changed-By: gavin Responsible-Changed-When: Mon Feb 25 11:25:21 UTC 2008 Responsible-Changed-Why: Over to -acpi mailing list. http://www.freebsd.org/cgi/query-pr.cgi?pr=90243 From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 17:59:35 2008 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 CF4B316A408 for ; Mon, 25 Feb 2008 17:59:35 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id B190313C458 for ; Mon, 25 Feb 2008 17:59:35 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 76898 invoked from network); 25 Feb 2008 17:59:35 -0000 Received: from adsl-71-141-98-131.dsl.snfc21.pacbell.net (HELO ?192.168.1.77?) (nate-mail@71.141.98.131) by root.org with ESMTPA; 25 Feb 2008 17:59:35 -0000 Message-ID: <47C30201.3060501@root.org> Date: Mon, 25 Feb 2008 09:59:29 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Andriy Gapon References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> <47BAF97A.80405@icyb.net.ua> <47BAFB27.1050509@root.org> <47BB2D1F.8000008@icyb.net.ua> <47BEF0C1.5090800@icyb.net.ua> <47BEF211.4030608@icyb.net.ua> In-Reply-To: <47BEF211.4030608@icyb.net.ua> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 25 Feb 2008 17:59:35 -0000 Andriy Gapon wrote: > on 22/02/2008 17:56 Andriy Gapon said the following: >> Please find attached a patch that makes sure that acpi_thermal is >> initialized after PCI bus is available, so that it is possible to decide >> about hardware quirks based on PCI information. >> The code uses the same approach as ichss does. >> The patch is tested to work. > > Oops! I attached on older version of the patch, sorry. > Correct patch is here. > (parent of acpi_throttle is cpu, not acpi) > >> NOTE: This patch in contaminated! It contains code that forces throttle >> duty width to be 3 bits for PIIX4E and PIIX4M. This is in accordance >> with the chipsets specifications. Some motherboard/bios vendors lie >> about this value in FADT. >> If not accepted, this quirk can be easily stripped from the patch as its >> code is contained in distinct hunks. Ok, couple comments I think should be addressed before committing: * This only adds a child to cpu0. On an SMP machine, we should have a device instance attached to each cpu. On machines where each CPU has its own throttling register, this is necessary to program the new rate. * Is it necessary to add "device_probe_and_attach(child)"? I guess if the child is added after the cpu parent's probe/attach run has completed, that could be a problem. * I'm uncomfortable with moving the whole driver probe under pci. I'd rather the pci probe happen separately and provide information to the cpufreq probe. But I'm not sure this is feasible. I wonder if John might have any advice on how to coordinate between PCI and cpufreq? -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 21:04:11 2008 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 C975516A40E; Mon, 25 Feb 2008 21:04:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 491AC13C4F8; Mon, 25 Feb 2008 21:04:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id B9E63744002; Mon, 25 Feb 2008 23:04:08 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 4rzVSFl3rI17; Mon, 25 Feb 2008 23:04:08 +0200 (EET) Received: from [10.74.68.211] (unknown [193.138.145.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id A23A0744001; Mon, 25 Feb 2008 23:04:07 +0200 (EET) Message-ID: <47C32D3C.2020205@icyb.net.ua> Date: Mon, 25 Feb 2008 23:03:56 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: Nate Lawson References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> <47BAF97A.80405@icyb.net.ua> <47BAFB27.1050509@root.org> <47BB2D1F.8000008@icyb.net.ua> <47BEF0C1.5090800@icyb.net.ua> <47BEF211.4030608@icyb.net.ua> <47C30201.3060501@root.org> In-Reply-To: <47C30201.3060501@root.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 25 Feb 2008 21:04:11 -0000 on 25/02/2008 19:59 Nate Lawson said the following: > Andriy Gapon wrote: >> on 22/02/2008 17:56 Andriy Gapon said the following: >>> Please find attached a patch that makes sure that acpi_thermal is >>> initialized after PCI bus is available, so that it is possible to decide >>> about hardware quirks based on PCI information. >>> The code uses the same approach as ichss does. >>> The patch is tested to work. >> Oops! I attached on older version of the patch, sorry. >> Correct patch is here. >> (parent of acpi_throttle is cpu, not acpi) >> >>> NOTE: This patch in contaminated! It contains code that forces throttle >>> duty width to be 3 bits for PIIX4E and PIIX4M. This is in accordance >>> with the chipsets specifications. Some motherboard/bios vendors lie >>> about this value in FADT. >>> If not accepted, this quirk can be easily stripped from the patch as its >>> code is contained in distinct hunks. > > Ok, couple comments I think should be addressed before committing: > > * This only adds a child to cpu0. On an SMP machine, we should have a > device instance attached to each cpu. On machines where each CPU has > its own throttling register, this is necessary to program the new rate. > > * Is it necessary to add "device_probe_and_attach(child)"? I guess if > the child is added after the cpu parent's probe/attach run has > completed, that could be a problem. > > * I'm uncomfortable with moving the whole driver probe under pci. I'd > rather the pci probe happen separately and provide information to the > cpufreq probe. But I'm not sure this is feasible. I wonder if John > might have any advice on how to coordinate between PCI and cpufreq? > Nate, these are very good points. It seems that I wrote something very specific to my case and didn't consider other scenarios. I completely forgot about SMP case. I need to think more about this. A possible blanket solution would be to probe/attach all and any cpu child devices after pci bus is attached. But I don't know if this is a viable solution in general and if it's possible to implement at all. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 06:47:35 2008 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 6EF0B16A407 for ; Tue, 26 Feb 2008 06:47:35 +0000 (UTC) (envelope-from amistry@am-productions.biz) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.freebsd.org (Postfix) with ESMTP id 36ABE13C448 for ; Tue, 26 Feb 2008 06:47:35 +0000 (UTC) (envelope-from amistry@am-productions.biz) Received: from [192.168.1.100] (adsl-68-77-177-92.dsl.wotnoh.ameritech.net [68.77.177.92]) (authenticated bits=0) by mail.united-ware.com (8.14.2/8.14.2) with ESMTP id m1Q6iIi2025545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Feb 2008 01:44:19 -0500 (EST) (envelope-from amistry@am-productions.biz) From: Anish Mistry Organization: AM Productions To: freebsd-acpi@freebsd.org Date: Tue, 26 Feb 2008 01:41:00 -0500 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2289078.G23u2fOGhO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802260141.10243.amistry@am-productions.biz> X-Virus-Scanned: ClamAV 0.91.2/5991/Mon Feb 25 13:48:35 2008 on mail.united-ware.com X-Virus-Status: Clean Subject: ASL External References 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, 26 Feb 2008 06:47:35 -0000 --nextPart2289078.G23u2fOGhO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline How do I populate and External reference in an ASL? I'm trying to get=20 the acpi_fujitsu driver to work without=20 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D121102 The method I'm looking to implement: External (\_SB_.PCI0.GFX0.LCD_.BLNF, MethodObj) // 0 Arguments http://am-productions.biz/docs/smallguy.asl =2D-=20 Anish Mistry amistry@am-productions.biz AM Productions http://am-productions.biz/ --nextPart2289078.G23u2fOGhO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHw7R9xqA5ziudZT0RApLXAKC5w6Ne6yaRzD6cL1z4aJ9A7ur/lQCfYRZp 1jZz+ViZoAH+3ld3ctoh9a0= =ALPR -----END PGP SIGNATURE----- --nextPart2289078.G23u2fOGhO-- From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 06:47:36 2008 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 1B5C516A400 for ; Tue, 26 Feb 2008 06:47:36 +0000 (UTC) (envelope-from amistry@am-productions.biz) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.freebsd.org (Postfix) with ESMTP id ADD8213C45B for ; Tue, 26 Feb 2008 06:47:35 +0000 (UTC) (envelope-from amistry@am-productions.biz) Received: from [192.168.1.100] (adsl-68-77-177-92.dsl.wotnoh.ameritech.net [68.77.177.92]) (authenticated bits=0) by mail.united-ware.com (8.14.2/8.14.2) with ESMTP id m1Q6kf2d025593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Feb 2008 01:46:42 -0500 (EST) (envelope-from amistry@am-productions.biz) From: Anish Mistry Organization: AM Productions To: freebsd-acpi@freebsd.org Date: Tue, 26 Feb 2008 01:43:33 -0500 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1579712.2EENQUga9h"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802260143.34113.amistry@am-productions.biz> X-Virus-Scanned: ClamAV 0.91.2/5991/Mon Feb 25 13:48:35 2008 on mail.united-ware.com X-Virus-Status: Clean Subject: Fujitsu P8010 Can't Suspend "Operation not supported" 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, 26 Feb 2008 06:47:36 -0000 --nextPart1579712.2EENQUga9h Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I just got a P8010 and it can't seem to suspend. If I call=20 acpiconf -s 3 I just get an "Operation not supported" error. =46reeBSD 7.0-RELEASE amd64 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: S1 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.cpu.cx_lowest: C3 hw.acpi.acline: 1 hw.acpi.battery.life: 96 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 26.8C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 95.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 100.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1.temperature: 26.8C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 0 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 95.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 100.0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.fujitsu.pointer_enable: 1 hw.acpi.fujitsu.lcd_brightness: 1 hw.acpi.fujitsu.backlight: 1 hw.acpi.fujitsu.lcd_brightness_radix: 8 http://am-productions.biz/docs/smallguy.asl http://am-productions.biz/docs/smallguy-dmesg.txt http://am-productions.biz/docs/smallguy-pciconf.txt S5 does work. =2D-=20 Anish Mistry amistry@am-productions.biz AM Productions http://am-productions.biz/ --nextPart1579712.2EENQUga9h Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHw7UWxqA5ziudZT0RApBVAJ9ABtgotg34yLwhoqdYTGavyPEGnwCeP8FF 9l8ODJoAHj5e6cVfVFJYCNI= =VpZ6 -----END PGP SIGNATURE----- --nextPart1579712.2EENQUga9h-- From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 13:16:28 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 446691065672; Tue, 26 Feb 2008 13:16:28 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 36BDB13C4D1; Tue, 26 Feb 2008 13:16:28 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1QDGSo0095313; Tue, 26 Feb 2008 13:16:28 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1QDGSdC095309; Tue, 26 Feb 2008 13:16:28 GMT (envelope-from gavin) Date: Tue, 26 Feb 2008 13:16:28 GMT Message-Id: <200802261316.m1QDGSdC095309@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-acpi@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/121102: Update acpi_fujitsu for the P8010 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, 26 Feb 2008 13:16:28 -0000 Synopsis: Update acpi_fujitsu for the P8010 Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: gavin Responsible-Changed-When: Tue Feb 26 13:15:59 UTC 2008 Responsible-Changed-Why: Over to acpi mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=121102 From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 16:24:49 2008 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 E2052106566B for ; Tue, 26 Feb 2008 16:24:49 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id BBC2D13C455 for ; Tue, 26 Feb 2008 16:24:49 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 27796 invoked from network); 26 Feb 2008 16:24:49 -0000 Received: from adsl-71-141-98-131.dsl.snfc21.pacbell.net (HELO ?192.168.1.77?) (nate-mail@71.141.98.131) by root.org with ESMTPA; 26 Feb 2008 16:24:49 -0000 Message-ID: <47C43D4B.2070502@root.org> Date: Tue, 26 Feb 2008 08:24:43 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Anish Mistry References: <200802260143.34113.amistry@am-productions.biz> In-Reply-To: <200802260143.34113.amistry@am-productions.biz> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Fujitsu P8010 Can't Suspend "Operation not supported" 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, 26 Feb 2008 16:24:50 -0000 Anish Mistry wrote: > I just got a P8010 and it can't seem to suspend. If I call > acpiconf -s 3 I just get an "Operation not supported" error. > > FreeBSD 7.0-RELEASE amd64 There is no amd64 asm wakecode implemented yet. Someone needs to look at the Linux version and our i386 acpi_wakecode.S and write it. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 16:50:25 2008 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 1A9EA1065688; Tue, 26 Feb 2008 16:50:24 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Tue, 26 Feb 2008 11:50:11 -0500 User-Agent: KMail/1.6.2 References: <200802260143.34113.amistry@am-productions.biz> <47C43D4B.2070502@root.org> In-Reply-To: <47C43D4B.2070502@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200802261150.13834.jkim@FreeBSD.org> Cc: Anish Mistry Subject: Re: Fujitsu P8010 Can't Suspend "Operation not supported" 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, 26 Feb 2008 16:50:25 -0000 On Tuesday 26 February 2008 11:24 am, Nate Lawson wrote: > Anish Mistry wrote: > > I just got a P8010 and it can't seem to suspend. If I call > > acpiconf -s 3 I just get an "Operation not supported" error. > > > > FreeBSD 7.0-RELEASE amd64 > > There is no amd64 asm wakecode implemented yet. Someone needs to > look at the Linux version and our i386 acpi_wakecode.S and write > it. And NetBSD's: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/amd64/acpi/ Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 07:54:53 2008 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 94BE5106566B; Wed, 27 Feb 2008 07:54:53 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 0C2D413C43E; Wed, 27 Feb 2008 07:54:52 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 7C14343E2B9; Wed, 27 Feb 2008 09:54:50 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 8gobYn4SFVPX; Wed, 27 Feb 2008 09:54:50 +0200 (EET) Received: from [91.193.172.111] (unknown [91.193.172.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3158543E252; Wed, 27 Feb 2008 09:54:49 +0200 (EET) Message-ID: <47C5173E.40207@icyb.net.ua> Date: Wed, 27 Feb 2008 09:54:38 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: Nate Lawson References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> <47BAF97A.80405@icyb.net.ua> <47BAFB27.1050509@root.org> <47BB2D1F.8000008@icyb.net.ua> <47BEF0C1.5090800@icyb.net.ua> <47BEF211.4030608@icyb.net.ua> <47C30201.3060501@root.org> <47C32D3C.2020205@icyb.net.ua> In-Reply-To: <47C32D3C.2020205@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 27 Feb 2008 07:54:53 -0000 on 25/02/2008 23:03 Andriy Gapon said the following: > Nate, > these are very good points. It seems that I wrote something very > specific to my case and didn't consider other scenarios. I completely > forgot about SMP case. > I need to think more about this. > A possible blanket solution would be to probe/attach all and any cpu > child devices after pci bus is attached. But I don't know if this is a > viable solution in general and if it's possible to implement at all. I looked through some code while pursuing the above idea. Of course, things are more complicated if one has to consider legacy scenarios (no ACPI) too, but for the scope of this issue I sticked to the case when ACPI is available. It seems that children of acpi are added in acpi_probe_children function. First we walk over all devices declared in DSDT and create child devices for those that are interesting to us. AcpiWalkNamespace with acpi_probe_child is used for that. When we call BUS_ADD_CHILD for a device we typically specify an order value based on a device's level/depth. For some special devices we set specific (early) order value in acpi_probe_order (based on HID). Then we add devices that are not auto-detected but rather add themselves via device_identify method. Then we perform probe and attach for all added devices via bus_generic_attach, and the devices are probed and attached according to their 'order' attribute. >From this, my conclusion is that relative order of cpu and pci bridge is generally undetermined in this case. This is because neither of them has a specific order assigned. So their order depends on their level and, well, order in DSDT. Typically, processor would have a smaller or equal level compared to host-pci bridge. In my particular case I believe that the levels are the same: \_PR_.CPU0 \_SB_.PCI0 And processor appears earlier in DSDT, so they both have the same order value but processor is added earlier. Another thing is that acpi_cpu and acpi_pcib_acpi (using their "full names") are the buses themselves, so they identify/probe/attach their children in their attach methods. Thus, whichever has earlier order will also probe and attach (all of) its children earlier. So what I am getting at - it is certainly not hard to make acpi_pcib_acpi (and consecutively pci) be attached earlier than acpi_cpu. All is needed is to add another special case in acpi_probe_order after the existing ones, I actually did it as an experiment: else if (acpi_MatchHid(handle, "PNP0A03")) *order = 4; This worked for me as expected and without any side effects. But I have a big concern about whether we have any devices/drivers that rely on a current typical order. That is, drivers that expect cpu device/bus to be already probed and attached at the time when probe/attach is called for something on pci bus. I guess one example here is famous ichss that adds a child to cpu bus in its pci probe routine, and calls device_probe_and_attach for it in the same place too. I guess that while BUS_ADD_CHILD should work at that place, device_probe_and_attach may not because cpu itself is not probed and attached yet. On the other hand, as I said in the beginning, I think that even now there are no strict guarantees about the order, it just happens to work. Anyway, I am not sure if the discussed change in ordering has any merit. It seems that whatever the order it would be convenient in some places and inconvenient in others, so some jumping through the hoops is inevitable. I wonder if it would be possible to create some mechanism for attaching "important" devices first and then the rest later. E.g. cpu and pcib+pci are attached first (in whatever order), then their children are attached later (in whatever order). What is important is that all those "late" children can expect both cpu and pci to be fully available. P.S. sorry for high-jacking a topic, an unrelated question: shouldn't ISA PnP devices get configured (assigned resources) before any PCI devices ? http://docs.FreeBSD.org/cgi/mid.cgi?47C338D5.2080906 -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 18:31:05 2008 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 723CB1065671; Wed, 27 Feb 2008 18:31:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id DA8898FC1A; Wed, 27 Feb 2008 18:31:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 233599853-1834499 for multiple; Wed, 27 Feb 2008 13:28:00 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m1RITrOg035092; Wed, 27 Feb 2008 13:29:53 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andriy Gapon Date: Wed, 27 Feb 2008 11:26:29 -0500 User-Agent: KMail/1.9.7 References: <47B96989.6070008@icyb.net.ua> <47C32D3C.2020205@icyb.net.ua> <47C5173E.40207@icyb.net.ua> In-Reply-To: <47C5173E.40207@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802271126.30132.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 27 Feb 2008 13:29:53 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/6010/Wed Feb 27 07:54:14 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 27 Feb 2008 18:31:05 -0000 On Wednesday 27 February 2008 02:54:38 am Andriy Gapon wrote: > on 25/02/2008 23:03 Andriy Gapon said the following: > > Nate, > > these are very good points. It seems that I wrote something very > > specific to my case and didn't consider other scenarios. I completely > > forgot about SMP case. > > I need to think more about this. > > A possible blanket solution would be to probe/attach all and any cpu > > child devices after pci bus is attached. But I don't know if this is a > > viable solution in general and if it's possible to implement at all. > > I looked through some code while pursuing the above idea. Of course, > things are more complicated if one has to consider legacy scenarios (no > ACPI) too, but for the scope of this issue I sticked to the case when > ACPI is available. > It seems that children of acpi are added in acpi_probe_children > function. First we walk over all devices declared in DSDT and create > child devices for those that are interesting to us. AcpiWalkNamespace > with acpi_probe_child is used for that. When we call BUS_ADD_CHILD for a > device we typically specify an order value based on a device's > level/depth. For some special devices we set specific (early) order > value in acpi_probe_order (based on HID). > Then we add devices that are not auto-detected but rather add themselves > via device_identify method. Then we perform probe and attach for all > added devices via bus_generic_attach, and the devices are probed and > attached according to their 'order' attribute. > From this, my conclusion is that relative order of cpu and pci bridge is > generally undetermined in this case. This is because neither of them has > a specific order assigned. So their order depends on their level and, > well, order in DSDT. > Typically, processor would have a smaller or equal level compared to > host-pci bridge. In my particular case I believe that the levels are the > same: > \_PR_.CPU0 > \_SB_.PCI0 > And processor appears earlier in DSDT, so they both have the same order > value but processor is added earlier. > > Another thing is that acpi_cpu and acpi_pcib_acpi (using their "full > names") are the buses themselves, so they identify/probe/attach their > children in their attach methods. Thus, whichever has earlier order will > also probe and attach (all of) its children earlier. > > So what I am getting at - it is certainly not hard to make > acpi_pcib_acpi (and consecutively pci) be attached earlier than > acpi_cpu. All is needed is to add another special case in > acpi_probe_order after the existing ones, I actually did it as an > experiment: > else if (acpi_MatchHid(handle, "PNP0A03")) > *order = 4; > This worked for me as expected and without any side effects. > > But I have a big concern about whether we have any devices/drivers that > rely on a current typical order. That is, drivers that expect cpu > device/bus to be already probed and attached at the time when > probe/attach is called for something on pci bus. > I guess one example here is famous ichss that adds a child to cpu bus in > its pci probe routine, and calls device_probe_and_attach for it in the > same place too. I guess that while BUS_ADD_CHILD should work at that > place, device_probe_and_attach may not because cpu itself is not probed > and attached yet. > > On the other hand, as I said in the beginning, I think that even now > there are no strict guarantees about the order, it just happens to work. > > Anyway, I am not sure if the discussed change in ordering has any merit. > It seems that whatever the order it would be convenient in some places > and inconvenient in others, so some jumping through the hoops is inevitable. > > I wonder if it would be possible to create some mechanism for attaching > "important" devices first and then the rest later. E.g. cpu and pcib+pci > are attached first (in whatever order), then their children are attached > later (in whatever order). What is important is that all those "late" > children can expect both cpu and pci to be fully available. I actually have had patches for a while to make CPU devices attach in a certain order with respect to Host-PCI bridges precisely to help address this. What I did was to force CPUs to probe before PCI devices so then the ichss drivers current method (adding devices to CPUs) always works as the CPUs are around when ichss goes to attach devices to them. This is the patch I've had for a while. It also attaches Host-PCI bridges in a more deterministic order: --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi.c 2007/10/09 07:52:34 +++ //depot/user/jhb/acpipci/dev/acpica/acpi.c 2008/01/22 23:22:19 @@ -1533,18 +1534,32 @@ static int acpi_probe_order(ACPI_HANDLE handle, int *order) { + ACPI_OBJECT_TYPE type; + u_int addr; /* * 1. I/O port and memory system resource holders * 2. Embedded controllers (to handle early accesses) - * 3. PCI Link Devices + * 3. CPUs + * 4. PCI Link Devices + * 11 - 266. Host-PCI bridges sorted by _ADR */ + AcpiGetType(handle, &type); if (acpi_MatchHid(handle, "PNP0C01") || acpi_MatchHid(handle, "PNP0C02")) *order = 1; else if (acpi_MatchHid(handle, "PNP0C09")) *order = 2; + else if (type == ACPI_TYPE_PROCESSOR) + *order = 3; else if (acpi_MatchHid(handle, "PNP0C0F")) - *order = 3; + *order = 4; + else if (acpi_MatchHid(handle, "PNP0A03")) { + if (ACPI_SUCCESS(acpi_GetInteger(handle, "_ADR", &addr))) + *order = 11 + ACPI_ADR_PCI_SLOT(addr) * (PCI_FUNCMAX + 1) + + ACPI_ADR_PCI_FUNC(addr); + else + *order = 11; + } return (0); } @@ -1591,14 +1606,16 @@ break; /* - * Create a placeholder device for this node. Sort the placeholder - * so that the probe/attach passes will run breadth-first. Orders - * less than ACPI_DEV_BASE_ORDER are reserved for special objects - * (i.e., system resources). Larger values are used for all other - * devices. + * Create a placeholder device for this node. Sort the + * placeholder so that the probe/attach passes will run + * breadth-first. Orders less than ACPI_DEV_BASE_ORDER + * are reserved for special objects (i.e., system + * resources). Values between ACPI_DEV_BASE_ORDER and 300 + * are reserved for Host-PCI bridges. Larger values are + * used for all other devices. */ ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "scanning '%s'\n", handle_str)); - order = (level + 1) * ACPI_DEV_BASE_ORDER; + order = level * 10 + 300; acpi_probe_order(handle, &order); child = BUS_ADD_CHILD(bus, order, NULL, -1); if (child == NULL) With this patch PCI drivers that want to work with CPU devices would use the same approach as ichss. I'm not sure that is the best approach though. The fact that smist0 wants to check if ichss0 is attached probably wouldn't work as with this patch smist0 would attach first before ichss0 got a chance to probe via PCI. We could flip this around to have PCI bridges first before CPUs. As you suggest. However, that will break ichss in its current form as cpu0 won't exist yet (the device wouldn't be probed, so it would be called cpu0 yet). This is begging for multi-pass. :( (But that's another topic). In practice, I think you could change ichss to not use a PCI probe, but to just read config registers directly and hardcode the address of the ICH. You could even walk PCI bus 0 looking for a PCI-ISA bridge instead of hardcoding the address I think. Then ichss would just be a CPU device and not depend on the PCI bus at all. I'm not sure if that is workable for the other case you are worried about. BTW, once an order is decided upon of CPUs relative to Host-PCI bridges we can fix that order for the non-ACPI case easily enough in legacy.c. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 22:14:16 2008 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 F15B8106566C; Wed, 27 Feb 2008 22:14:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 898358FC1A; Wed, 27 Feb 2008 22:14:14 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id A882B43E74D; Thu, 28 Feb 2008 00:14:12 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id s5yoMGLTo90z; Thu, 28 Feb 2008 00:14:12 +0200 (EET) Received: from [91.193.172.111] (unknown [91.193.172.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id E89B943C6D9; Thu, 28 Feb 2008 00:14:10 +0200 (EET) Message-ID: <47C5E0A6.5030102@icyb.net.ua> Date: Thu, 28 Feb 2008 00:13:58 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: John Baldwin References: <47B96989.6070008@icyb.net.ua> <47C32D3C.2020205@icyb.net.ua> <47C5173E.40207@icyb.net.ua> <200802271126.30132.jhb@freebsd.org> In-Reply-To: <200802271126.30132.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 27 Feb 2008 22:14:16 -0000 on 27/02/2008 18:26 John Baldwin said the following: > On Wednesday 27 February 2008 02:54:38 am Andriy Gapon wrote: [snip] >> So what I am getting at - it is certainly not hard to make >> acpi_pcib_acpi (and consecutively pci) be attached earlier than >> acpi_cpu. All is needed is to add another special case in >> acpi_probe_order after the existing ones, I actually did it as an >> experiment: >> else if (acpi_MatchHid(handle, "PNP0A03")) >> *order = 4; >> This worked for me as expected and without any side effects. >> >> But I have a big concern about whether we have any devices/drivers that >> rely on a current typical order. That is, drivers that expect cpu >> device/bus to be already probed and attached at the time when >> probe/attach is called for something on pci bus. >> I guess one example here is famous ichss that adds a child to cpu bus in >> its pci probe routine, and calls device_probe_and_attach for it in the >> same place too. I guess that while BUS_ADD_CHILD should work at that >> place, device_probe_and_attach may not because cpu itself is not probed >> and attached yet. >> >> On the other hand, as I said in the beginning, I think that even now >> there are no strict guarantees about the order, it just happens to work. >> >> Anyway, I am not sure if the discussed change in ordering has any merit. >> It seems that whatever the order it would be convenient in some places >> and inconvenient in others, so some jumping through the hoops is inevitable. >> >> I wonder if it would be possible to create some mechanism for attaching >> "important" devices first and then the rest later. E.g. cpu and pcib+pci >> are attached first (in whatever order), then their children are attached >> later (in whatever order). What is important is that all those "late" >> children can expect both cpu and pci to be fully available. > > I actually have had patches for a while to make CPU devices attach in a > certain order with respect to Host-PCI bridges precisely to help address > this. What I did was to force CPUs to probe before PCI devices so then the > ichss drivers current method (adding devices to CPUs) always works as the > CPUs are around when ichss goes to attach devices to them. > > This is the patch I've had for a while. It also attaches Host-PCI bridges in > a more deterministic order: > > --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi.c 2007/10/09 07:52:34 > +++ //depot/user/jhb/acpipci/dev/acpica/acpi.c 2008/01/22 23:22:19 > @@ -1533,18 +1534,32 @@ > static int > acpi_probe_order(ACPI_HANDLE handle, int *order) > { > + ACPI_OBJECT_TYPE type; > + u_int addr; > > /* > * 1. I/O port and memory system resource holders > * 2. Embedded controllers (to handle early accesses) > - * 3. PCI Link Devices > + * 3. CPUs > + * 4. PCI Link Devices > + * 11 - 266. Host-PCI bridges sorted by _ADR > */ > + AcpiGetType(handle, &type); > if (acpi_MatchHid(handle, "PNP0C01") || acpi_MatchHid(handle, "PNP0C02")) > *order = 1; > else if (acpi_MatchHid(handle, "PNP0C09")) > *order = 2; > + else if (type == ACPI_TYPE_PROCESSOR) > + *order = 3; > else if (acpi_MatchHid(handle, "PNP0C0F")) > - *order = 3; > + *order = 4; > + else if (acpi_MatchHid(handle, "PNP0A03")) { > + if (ACPI_SUCCESS(acpi_GetInteger(handle, "_ADR", &addr))) > + *order = 11 + ACPI_ADR_PCI_SLOT(addr) * (PCI_FUNCMAX + 1) + > + ACPI_ADR_PCI_FUNC(addr); > + else > + *order = 11; > + } > return (0); > } > > @@ -1591,14 +1606,16 @@ > break; > > /* > - * Create a placeholder device for this node. Sort the placeholder > - * so that the probe/attach passes will run breadth-first. Orders > - * less than ACPI_DEV_BASE_ORDER are reserved for special objects > - * (i.e., system resources). Larger values are used for all other > - * devices. > + * Create a placeholder device for this node. Sort the > + * placeholder so that the probe/attach passes will run > + * breadth-first. Orders less than ACPI_DEV_BASE_ORDER > + * are reserved for special objects (i.e., system > + * resources). Values between ACPI_DEV_BASE_ORDER and 300 > + * are reserved for Host-PCI bridges. Larger values are > + * used for all other devices. > */ > ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "scanning '%s'\n", handle_str)); > - order = (level + 1) * ACPI_DEV_BASE_ORDER; > + order = level * 10 + 300; > acpi_probe_order(handle, &order); > child = BUS_ADD_CHILD(bus, order, NULL, -1); > if (child == NULL) > > With this patch PCI drivers that want to work with CPU devices would use the > same approach as ichss. I'm not sure that is the best approach though. The > fact that smist0 wants to check if ichss0 is attached probably wouldn't work > as with this patch smist0 would attach first before ichss0 got a chance to > probe via PCI. > > We could flip this around to have PCI bridges first before CPUs. As you > suggest. However, that will break ichss in its current form as cpu0 won't > exist yet (the device wouldn't be probed, so it would be called cpu0 yet). > > This is begging for multi-pass. :( (But that's another topic). > > In practice, I think you could change ichss to not use a PCI probe, but to > just read config registers directly and hardcode the address of the ICH. You > could even walk PCI bus 0 looking for a PCI-ISA bridge instead of hardcoding > the address I think. Then ichss would just be a CPU device and not depend on > the PCI bus at all. I'm not sure if that is workable for the other case you > are worried about. > > BTW, once an order is decided upon of CPUs relative to Host-PCI bridges we can > fix that order for the non-ACPI case easily enough in legacy.c. > John, thank you for this detailed reply! I looked through the code and I think that ichss is the only device that explicitly requires cpu and pci buses to be "configured". acpi_throttle is another one that implicitly requires that. My personal preference is to probe/attach pci first and then go with cpu. This is mostly because pci can provide a lot of useful information and resources to various devices. On the other hand, cpu mostly exists so that others could attach to it (it does provide a little bit, but it's a very little bit). So, in my opinion, it is more likely that a child of cpu would need something from pci than vice versa. If we agree on this order and implement it, then I agree with you that it would be quite easy to modify ichss to be a "normal" child of cpu and use pci_find_device to find a proper pci device. And the rest of the code that uses pci_read_config, bus_set_resource and bus_alloc_resource_any would remain practically the same. I'd even say that this would be a trivial change. And I'd even say that this would be a change in right direction, because ichss would lose most of its 'specialness'. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 04:14:54 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F22E1106566C for ; Thu, 28 Feb 2008 04:14:54 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 976158FC12 for ; Thu, 28 Feb 2008 04:14:54 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id m1S4ErXb022409; Wed, 27 Feb 2008 23:14:53 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 27 Feb 2008 23:14:53 -0500 (EST) Date: Wed, 27 Feb 2008 23:14:53 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Alexandre \"Sunny\" Kovalenko" In-Reply-To: <1203646096.16055.22.camel@RabbitsDen> Message-ID: References: <1200369199.2054.38.camel@RabbitsDen> <1203131179.833.32.camel@RabbitsDen> <1203549287.1019.43.camel@RabbitsDen> <1203555741.1019.50.camel@RabbitsDen> <1203646096.16055.22.camel@RabbitsDen> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: acpi@freebsd.org Subject: Re: How to disable acpi thermal? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 04:14:55 -0000 On Thu, 21 Feb 2008, Alexandre "Sunny" Kovalenko wrote: > > On Wed, 2008-02-20 at 20:14 -0500, Daniel Eischen wrote: >> On Wed, 20 Feb 2008, Alexandre \Sunny\ Kovalenko wrote: >> >>> >>> On Wed, 2008-02-20 at 18:48 -0500, Daniel Eischen wrote: >>>> On Wed, 20 Feb 2008, Alexandre \Sunny\ Kovalenko wrote: >>>> >>>>> I assume (possibly incorrectly) that 1) your CPU is capable of the >>>>> frequency throttling and 2) you are using frequency governor of some >>>>> sort (see cpufreq(4) for detail). If this is not the case, the change >>>>> will not help. >>>> >>>> I don't know about 1): >>>> >>>> CPU: Intel Pentium III (933.08-MHz 686-class CPU) >>>> Origin = "GenuineIntel" Id = 0x686 Stepping = 6 >>>> Features=0x383fbff >>>> >>>> and 2), no, I'm not using a frequency governor from what I can >>>> tell. >>>> >>>> $ sysctl -a | grep dev.cpu >>>> dev.cpu.0.%desc: ACPI CPU >>>> dev.cpu.0.%driver: cpu >>>> dev.cpu.0.%location: handle=\_PR_.CPU0 >>>> dev.cpu.0.%pnpinfo: _HID=none _UID=0 >>>> dev.cpu.0.%parent: acpi0 >>>> dev.cpu.0.cx_supported: C1/0 >>>> dev.cpu.0.cx_lowest: C1 >>>> dev.cpu.0.cx_usage: 100.00% >>>> >>>> $ sudo kldload /boot/kernel/cpufreq.ko >>>> >>>> $ sysctl -a | grep dev.cpu >>>> dev.cpu.0.%desc: ACPI CPU >>>> dev.cpu.0.%driver: cpu >>>> dev.cpu.0.%location: handle=\_PR_.CPU0 >>>> dev.cpu.0.%pnpinfo: _HID=none _UID=0 >>>> dev.cpu.0.%parent: acpi0 >>>> dev.cpu.0.cx_supported: C1/0 >>>> dev.cpu.0.cx_lowest: C1 >>>> dev.cpu.0.cx_usage: 100.00% >>>> >>>> >>>>> Also, since I have sent you that change, I have learned that setting >>>>> hw.acpi.thermal.user_override=1 and hw.acpi.thermal.tz0._PSV=85C might >>>>> accomplish the same thing as the ASL change. I saw it working for the >>>>> thermal zone which already had sensible _PSV, but I have no hardware to >>>>> try this approach when _PSV is not present in the ASL. >>>> >>>> Well, this is a server board, not a laptop, so I'm not sure >>>> it even has CPU throttling. >>>> >>> As far as I can tell from the stuff above -- it does not. I was confused >>> by presence of some pieces in the ASL, which would normally indicate >>> that it does. One thing, which surprises me, is that with the lack of >>> throttling and, what appears to be single speed fan or even a heatsink, >>> I do not see how its thermal mode could behave differently in the >>> presence of the load. Could you, please, send me output of the sysctl >>> machdep. >> >> $ sysctl machdep >> machdep.enable_panic_key: 0 >> machdep.adjkerntz: 0 >> machdep.wall_cmos_clock: 0 >> machdep.disable_rtc_set: 0 >> machdep.conspeed: 9600 >> machdep.gdbspeed: 9600 >> machdep.conrclk: 1843200 >> machdep.disable_mtrrs: 0 >> machdep.guessed_bootdev: 2687500288 >> machdep.cpu_idle_hlt: 1 >> machdep.prot_fault_translation: 0 >> machdep.panic_on_nmi: 1 >> machdep.kdb_on_nmi: 1 >> machdep.tsc_freq: 933073074 >> machdep.i8254_freq: 1193182 >> machdep.acpi_timer_freq: 3579545 >> machdep.acpi_root: 1009936 >> > OK, I give up. The only positive idea so far is that your CPU needed > these idle moments (machdep.cpu_idle_hlt: 1) to keep temperature under > the critical level. AFAICR 4.x did not know much of anything about ACPI, > so it did not exhibit any problems. > > To check whether this is the hardware issue or that of FreeBSD, you can > boot from some recent Linux LiveCD and run 'openssl speed aes -multi > 256', or some other CPU-intensive thing of you choice, and > 'cat /proc/acpi/thermal_zone/TZC0/temperature' periodically to see > whether temperature would raise as rapidly. It might not be a bad idea > to do the same (former) thing under FreeBSD to make sure that it does > indeed cause thermal shutdown ;) I've done this, to somewhat ambiguous results. I used OpenSUSE Live CD (V10.3 / KDE). So it booted into KDE just fine, and 'cat /proc/acpi/thermal_zone/TZC0/temperature' showed the temp ranging from 98C to 100C. When I ran 'openssl speed aes -multi 256' it (Linux) showed the temperature climb to as high as 104C, but still seemed to hover around 101-103C. It didn't shoot up much from the 99C. But all that was with KDE, so I don't know what the temp was without KDE running. In FreeBSD, using 'openssl speed aes -multi 256', the temp can climb as high as 117C (which is over the 110C _CRT cap). Since this is a server, I don't have any window manager running on it. > Another (and more dangerous) experiment would be to set > hw.acpi.thermal.user_override=1 and hw.acpi.thermal.tz0._CRT=150C and > see whether temperature would stabilize at some point above the old _CRT > value. This might cost you a CPU, though... I've already done that. It stablizes at about 117 or so. Since there's not much more we can do, I'll just drop the issue. Maybe I'll see if I can get new server to replace it, kind of a shame since it's got much more horsepower than it currently needs. -- DE From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 08:25:53 2008 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 722341065675 for ; Thu, 28 Feb 2008 08:25:53 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 206188FC25 for ; Thu, 28 Feb 2008 08:25:52 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id B49B274400E for ; Thu, 28 Feb 2008 10:25:50 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id bIhk1pvys2h2 for ; Thu, 28 Feb 2008 10:25:50 +0200 (EET) Received: from [91.193.172.111] (unknown [91.193.172.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 2FBE374400A for ; Thu, 28 Feb 2008 10:25:50 +0200 (EET) Message-ID: <47C67001.20101@icyb.net.ua> Date: Thu, 28 Feb 2008 10:25:37 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: mismatch between FACP and chipset spec 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, 28 Feb 2008 08:25:53 -0000 As some of you probably already know I have a motherboard based on 440BX/PIIX4E chipset: http://www.geocities.com/SiliconValley/3686/delta_mp2.html Here's some info from ACPI tables: PM1a_EVT_BLK=0x4000-0x4003 PM1a_CNT_BLK=0x4040-0x4041 PM_TMR_BLK=0x4008-0x400b I know that in my case 0x4000 is a base address of "Power Management IO Space" (as defined by PIIX4 specification). I see that descriptions of the registers and their bits match between ACPI specification and PIIX4 specification for registers in PM1a_EVT_BLK (PMSTS and PMEN registers in PIIX4 parlance) and PM_TMR_BLK (PMTMP register in PIIX4 parlance). But addresses given for PM1a_CNT_BLK are not documented at all! On the other hand ACPI description of that register perfectly matches description of PIIX4 PMCNTRL register that is located at 0x4004 with a given base address. So, this is 0x4040 vs. 0x4004, looks like a possible typo/mistake by an author of ACPI tables for this motherboard. Question: is there any way I can way override the address of PM1a_CNT_BLK? My guess is that there is zero chance that there would be any BIOS updates for this old and exotic motherboard (MP2-BX-X). I think that this register is mostly useful for BM_RLD bit which is used in C3 support. I don't use C3 (there is an errata for C3 with this chipset and there is no PM2_CNT register defined anyway), but I am curios anyway. And a mostly unrelated question. From the following code it seems that linux won't go even into C2 state if there is any bus master activity detected (but I am not what would happen with "demotion"/"promotion"): http://lxr.linux.no/linux/drivers/acpi/processor_idle.c#L389 -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 09:52:05 2008 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 030B71065671 for ; Thu, 28 Feb 2008 09:52:05 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id AF5E48FC1E for ; Thu, 28 Feb 2008 09:52:04 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so810930anc.13 for ; Thu, 28 Feb 2008 01:52:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=cpnXG1ioq4h4F1zC58/HgtfVwfalvxDUojXizvBjJPw=; b=HXh5U+fI/wdgalc0jNRZ9KTVEzgCqisfqVBRi7f1XXh7sbMmIDqDcbmH5UncBtOD2hHoZq9Kr9ZlFZYJIW5OhT8NMU89FciHiJWKQ3d5u91HJ0xaBAIDkUWEF9ZgQc+6cYZboX9JCrCgL7S9z3Vk9QO4K9j6/khWJDNbTgGjEvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=gP8NCgRvWVr4ddM5bzY+DSJTrTJWTm9euGYj84Mzk1LB1Za6niu0dt/N6fIuShRCMb+ZZX9lsTm4e5PbZb9hMW9mkPUoQib9l/zvzdBRdhRificiCe9TojZWmUqMCT0mrdoBLgNj48aRY5SbyGJyO2UmIvDcqSnArJRiMwgLW9Q= Received: by 10.100.242.20 with SMTP id p20mr9223016anh.68.1204192324014; Thu, 28 Feb 2008 01:52:04 -0800 (PST) Received: by 10.100.153.10 with HTTP; Thu, 28 Feb 2008 01:52:03 -0800 (PST) Message-ID: Date: Thu, 28 Feb 2008 09:52:03 +0000 From: "Rui Paulo" Sender: rpaulo@gmail.com To: "Andriy Gapon" In-Reply-To: <47C67001.20101@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47C67001.20101@icyb.net.ua> X-Google-Sender-Auth: 655faabb68b66ddf Cc: freebsd-acpi@freebsd.org Subject: Re: mismatch between FACP and chipset spec 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, 28 Feb 2008 09:52:05 -0000 On Thu, Feb 28, 2008 at 8:25 AM, Andriy Gapon wrote: > > As some of you probably already know I have a motherboard based on > 440BX/PIIX4E chipset: > http://www.geocities.com/SiliconValley/3686/delta_mp2.html > > Here's some info from ACPI tables: > PM1a_EVT_BLK=0x4000-0x4003 > PM1a_CNT_BLK=0x4040-0x4041 > PM_TMR_BLK=0x4008-0x400b > > I know that in my case 0x4000 is a base address of "Power Management IO > Space" (as defined by PIIX4 specification). > I see that descriptions of the registers and their bits match between > ACPI specification and PIIX4 specification for registers in PM1a_EVT_BLK > (PMSTS and PMEN registers in PIIX4 parlance) and PM_TMR_BLK (PMTMP > register in PIIX4 parlance). > But addresses given for PM1a_CNT_BLK are not documented at all! On the > other hand ACPI description of that register perfectly matches > description of PIIX4 PMCNTRL register that is located at 0x4004 with a > given base address. So, this is 0x4040 vs. 0x4004, looks like a possible > typo/mistake by an author of ACPI tables for this motherboard. > > Question: is there any way I can way override the address of > PM1a_CNT_BLK? My guess is that there is zero chance that there would be > any BIOS updates for this old and exotic motherboard (MP2-BX-X). Try dumping your ACPI tables, change the address and load the new tables on boot, http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html Regards. -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 12:29:37 2008 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 01BF6106567D; Thu, 28 Feb 2008 12:29:37 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1D18FC39; Thu, 28 Feb 2008 12:29:35 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id A743A43D97A; Thu, 28 Feb 2008 14:29:33 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq6eXOGP+GdN; Thu, 28 Feb 2008 14:29:33 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 4F42943D90C; Thu, 28 Feb 2008 14:29:33 +0200 (EET) Message-ID: <47C6A92C.7000700@icyb.net.ua> Date: Thu, 28 Feb 2008 14:29:32 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: Rui Paulo References: <47C67001.20101@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: mismatch between FACP and chipset spec 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, 28 Feb 2008 12:29:37 -0000 on 28/02/2008 11:52 Rui Paulo said the following: > On Thu, Feb 28, 2008 at 8:25 AM, Andriy Gapon wrote: >> As some of you probably already know I have a motherboard based on >> 440BX/PIIX4E chipset: >> http://www.geocities.com/SiliconValley/3686/delta_mp2.html >> >> Here's some info from ACPI tables: >> PM1a_EVT_BLK=0x4000-0x4003 >> PM1a_CNT_BLK=0x4040-0x4041 >> PM_TMR_BLK=0x4008-0x400b >> >> I know that in my case 0x4000 is a base address of "Power Management IO >> Space" (as defined by PIIX4 specification). >> I see that descriptions of the registers and their bits match between >> ACPI specification and PIIX4 specification for registers in PM1a_EVT_BLK >> (PMSTS and PMEN registers in PIIX4 parlance) and PM_TMR_BLK (PMTMP >> register in PIIX4 parlance). >> But addresses given for PM1a_CNT_BLK are not documented at all! On the >> other hand ACPI description of that register perfectly matches >> description of PIIX4 PMCNTRL register that is located at 0x4004 with a >> given base address. So, this is 0x4040 vs. 0x4004, looks like a possible >> typo/mistake by an author of ACPI tables for this motherboard. >> >> Question: is there any way I can way override the address of >> PM1a_CNT_BLK? My guess is that there is zero chance that there would be >> any BIOS updates for this old and exotic motherboard (MP2-BX-X). > > Try dumping your ACPI tables, change the address and load the new > tables on boot, > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html I have some experience with that (and I've been planning to share it for several years now). My impression that only DSDT can be changed this way, not the fixed tables. I could be wrong. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 13:49:36 2008 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 58D871065675 for ; Thu, 28 Feb 2008 13:49:36 +0000 (UTC) (envelope-from bostjanfe@hotmail.com) Received: from bay0-omc2-s4.bay0.hotmail.com (bay0-omc2-s4.bay0.hotmail.com [65.54.246.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3E87C8FC21 for ; Thu, 28 Feb 2008 13:49:36 +0000 (UTC) (envelope-from bostjanfe@hotmail.com) Received: from BAY110-W21 ([65.54.229.121]) by bay0-omc2-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Feb 2008 05:37:36 -0800 Message-ID: X-Originating-IP: [144.254.88.4] From: Bostjan Fele To: Date: Thu, 28 Feb 2008 19:37:35 +0600 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2008 13:37:36.0719 (UTC) FILETIME=[148185F0:01C87A0F] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem rebooting FreeBSD 7 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, 28 Feb 2008 13:49:36 -0000 Hi, I have problem with rebooting a FreeBSD. Most of the times it hangs up = waiting on CPUs to stop. Feb 27 19:49:40 ceiling reboot: rebooted by xxxxx Feb 27 19:49:40 ceiling syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...1 0 1 0 0 done All buffers synced. Uptime: 11h51m4s Rebooting... cpu_reset: Stopping other CPUs Tried with hw.acpi.disable_on_reboot and hw= .acpi.handle_reboot but did not help. But I can power down PC. Any suggesti= on is appreciated,Bostjan Copyright (c) 1992-2008 The FreeBSD Project.Copy= right (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 = The Regents of the University of California. All rights reserved.FreeBSD i= s a registered trademark of The FreeBSD Foundation.FreeBSD 7.0-PRERELEASE #= 9: Tue Feb 26 20:21:27 CET 2008Timecounter "i8254" frequency 1193182 Hz qua= lity 0CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2400.02-MHz K8-= class CPU) Origin =3D "GenuineIntel" Id =3D 0x6fb Stepping =3D 11 Featu= res=3D0xbfebfbff Features2= =3D0xe3bd AMD Feat= ures=3D0x20100800 AMD Features2=3D0x1 Cores per pack= age: 4usable memory =3D 4277628928 (4079 MB)avail memory =3D 4116414464 (3= 925 MB)ACPI APIC Table: FreeBSD/SMP: Multiprocessor System= Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP):= APIC ID: 2 cpu3 (AP): APIC ID: 3ioapic0: Changing APIC ID to 2ioapic0 irqs 0-23 on motherboardacpi0: on motherboardacp= i0: [ITHREAD]acpi0: Power Button (fixed)acpi0: reservation of 0, a0000 (3) = failedacpi0: reservation of 100000, cf4e0000 (3) failedTimecounter "ACPI-fa= st" frequency 3579545 Hz quality 1000acpi_timer0: <24-bit timer at 3.579545= MHz> port 0x408-0x40b on acpi0acpi_hpet0: iome= m 0xfed00000-0xfed003ff on acpi0Timecounter "HPET" frequency 14318180 Hz qu= ality 900cpu0: on acpi0acpi_perf0: = on cpu0p4tcc0: on cpu0cpu1: on a= cpi0est1: on cpu1est: CPU supports E= nhanced Speedstep, but is not recognized.est: cpu_vendor GenuineIntel, msr = 920092006000920device_attach: est1 attach returned 6p4tcc1: on cpu1cpu2: on acpi0est2: on cpu2est: CPU supports Enhanced Speedstep, but is not = recognized.est: cpu_vendor GenuineIntel, msr 920092006000920device_attach: = est2 attach returned 6p4tcc2: on cpu2cpu3: = on acpi0est3: on cpu3est:= CPU supports Enhanced Speedstep, but is not recognized.est: cpu_vendor Gen= uineIntel, msr 920092006000920device_attach: est3 attach returned 6p4tcc3: = on cpu3acpi_button0: on acpi= 0pcib0: port 0xcf8-0xcff on acpi0pci0: on pcib0vgapci0: port 0xe200-0xe207 mem 0xf32000= 00-0xf327ffff,0xe0000000-0xefffffff,0xf3000000-0xf30fffff irq 16 at device = 2.0 on pci0pci0: at device 26.0 (no driver attached)pci0:= at device 26.1 (no driver attached)pci0: at device 26.2 (no driver attached)pci0: at device 26.= 7 (no driver attached)pci0: at device 27.0 (no driver attached= )pcib1: irq 16 at device 28.0 on pci0pci1: on pcib1pcib2: irq 16 at device 28.4 on pci0pci2= : on pcib2atapci0: port = 0xc000-0xc007,0xc100-0xc103,0xc200-0xc207,0xc300-0xc303,0xc400-0xc40f irq 1= 6 at device 0.0 on pci2atapci0: [ITHREAD]ata2: on atapci0at= a2: [ITHREAD]pcib3: irq 17 at device 28.5 on pci0pci3= : on pcib3re0: po= rt 0xd000-0xd0ff mem 0xf2000000-0xf2000fff irq 17 at device 0.0 on pci3re0:= Using 2 MSI messagesmiibus0: on re0rgephy0: PHY 1 on miibus0rgephy0: 10baseT, 10baseT-FDX, 100baseT= X, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, autore0: Ethernet address: 00:1= a:4d:58:3c:d5re0: [FILTER]re0: [FILTER]pci0: at device 29= .0 (no driver attached)pci0: at device 29.1 (no driver at= tached)pci0: at device 29.2 (no driver attached)pci0: at device 29.7 (no driver attached)pcib4: at device 30.0 on pci0pci4: on pcib4pci4: at device 7.0 (no driver attached)isab0: at devic= e 31.0 on pci0isa0: on isab0atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f,0xfc00-0xfc0f at= device 31.2 on pci0ata0: on atapci1ata0: [ITHREAD]ata1: on atapci1ata1: [ITHREAD]pci0: at device = 31.3 (no driver attached)atapci2: port 0xe8= 00-0xe807,0xe900-0xe903,0xea00-0xea07,0xeb00-0xeb03,0xec00-0xec0f,0xed00-0x= ed0f irq 19 at device 31.5 on pci0atapci2: [ITHREAD]ata3: o= n atapci2ata3: [ITHREAD]ata4: on atapci2ata4: [ITHREAD]sio0= : configured irq 4 not in bitmap of probed irqs 0sio0: port may not be enab= ledsio0: configured irq 4 not in bitmap of probed irqs 0sio0: port may not = be enabledsio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0= x10 on acpi0sio0: type 16550A, consolesio0: [FILTER]sio1: configured irq 3 = not in bitmap of probed irqs 0sio1: port may not be enabledsio1: configured= irq 3 not in bitmap of probed irqs 0sio1: port may not be enabledsio1: <16= 550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0sio1: type 16550As= io1: [FILTER]atkbdc0: at port 0x60,0x64 on is= a0atkbd0: irq 1 on atkbdc0kbd0 at atkbd0atkbd0: [GIANT-LOCKED= ]atkbd0: [ITHREAD]sc0: at flags 0x100 on isa0sc0: VGA <16 = virtual consoles, flags=3D0x300>vga0: at port 0x3c0-0x3df= iomem 0xa0000-0xbffff on isa0Timecounters tick every 1.000 msecad0: 381553= MB at ata0-master SATA300acd0: DVDR at ata1-master SATA150SMP: AP CPU #1 Launched!SMP: AP = CPU #3 Launched!SMP: AP CPU #2 Launched!Trying to mount root from ufs:/dev/= ad0s1are0: link state changed to UPpid 619 (ntpd), uid 0: exited on signal = 11 (core dumped)re0: link state changed to DOWNre0: link state changed to U= Pre0: link state changed to DOWNre0: link state changed to UP Express yourself instantly with MSN Messenger! MSN Messenger=20 _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/= From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 13:57:34 2008 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 DA3A81065671; Thu, 28 Feb 2008 13:57:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE878FC16; Thu, 28 Feb 2008 13:57:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 233689963-1834499 for multiple; Thu, 28 Feb 2008 08:54:57 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m1SDuYQc046128; Thu, 28 Feb 2008 08:56:51 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andriy Gapon Date: Thu, 28 Feb 2008 08:56:31 -0500 User-Agent: KMail/1.9.7 References: <47B96989.6070008@icyb.net.ua> <200802271126.30132.jhb@freebsd.org> <47C5E0A6.5030102@icyb.net.ua> In-Reply-To: <47C5E0A6.5030102@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802280856.31548.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 28 Feb 2008 08:56:52 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/6023/Thu Feb 28 07:50:11 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 28 Feb 2008 13:57:34 -0000 On Wednesday 27 February 2008 05:13:58 pm Andriy Gapon wrote: > on 27/02/2008 18:26 John Baldwin said the following: > > On Wednesday 27 February 2008 02:54:38 am Andriy Gapon wrote: > [snip] > John, > > thank you for this detailed reply! > I looked through the code and I think that ichss is the only device that > explicitly requires cpu and pci buses to be "configured". acpi_throttle > is another one that implicitly requires that. > My personal preference is to probe/attach pci first and then go with > cpu. This is mostly because pci can provide a lot of useful information > and resources to various devices. On the other hand, cpu mostly exists > so that others could attach to it (it does provide a little bit, but > it's a very little bit). So, in my opinion, it is more likely that a > child of cpu would need something from pci than vice versa. > > If we agree on this order and implement it, then I agree with you that > it would be quite easy to modify ichss to be a "normal" child of cpu and > use pci_find_device to find a proper pci device. And the rest of the > code that uses pci_read_config, bus_set_resource and > bus_alloc_resource_any would remain practically the same. > I'd even say that this would be a trivial change. > And I'd even say that this would be a change in right direction, because > ichss would lose most of its 'specialness'. Actually, we can make ichss rather simple w/o changing it much by having it just set a global variable in its PCI probe routine and checking that global when attaching to the CPU. One other thing that concerns me is that cpufreq drivers want to know about each other (e.g. smist checks for ichss0, etc.). I'd rather that if we have multiple drivers controlling the same back-end hardware (via difference interfaces) they all use the same driver name (e.g. speedstep0) and use probe priority to decide which driver wins if both ichss0 and smist0 can handle a CPU for example. Here is a patch to make CPUs come after PCI and an attempt to fix ICH. Note that if we made ichss_identify() manually look for the PCI device by bsf instead of using a probe routine to find it we could remove the pci "driver" completely and make it work on kldload. It also fixes a bug that the attempt to enable SS via a PCI config register write could never work as it passed a cpu0 device_t to pci_read_config/pci_write_config in ichss_probe() previously. I moved this to attach() (where it belongs) and used the right device_t so this should work now. I have no hardware to test it on though. --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi.c 2008/01/28 02:00:16 +++ //depot/user/jhb/acpipci/dev/acpica/acpi.c 2008/02/28 13:34:35 @@ -1533,18 +1523,31 @@ static int acpi_probe_order(ACPI_HANDLE handle, int *order) { + ACPI_OBJECT_TYPE type; + u_int addr; /* * 1. I/O port and memory system resource holders * 2. Embedded controllers (to handle early accesses) * 3. PCI Link Devices + * 11 - 266. Host-PCI bridges sorted by _ADR + * 280. CPUs */ + AcpiGetType(handle, &type); if (acpi_MatchHid(handle, "PNP0C01") || acpi_MatchHid(handle, "PNP0C02")) *order = 1; else if (acpi_MatchHid(handle, "PNP0C09")) *order = 2; else if (acpi_MatchHid(handle, "PNP0C0F")) *order = 3; + else if (acpi_MatchHid(handle, "PNP0A03")) { + if (ACPI_SUCCESS(acpi_GetInteger(handle, "_ADR", &addr))) + *order = 11 + ACPI_ADR_PCI_SLOT(addr) * (PCI_FUNCMAX + 1) + + ACPI_ADR_PCI_FUNC(addr); + else + *order = 11; + } else if (type == ACPI_TYPE_PROCESSOR) + *order = 280; return (0); } @@ -1591,14 +1594,17 @@ break; /* - * Create a placeholder device for this node. Sort the placeholder - * so that the probe/attach passes will run breadth-first. Orders - * less than ACPI_DEV_BASE_ORDER are reserved for special objects - * (i.e., system resources). Larger values are used for all other - * devices. + * Create a placeholder device for this node. Sort the + * placeholder so that the probe/attach passes will run + * breadth-first. Orders less than ACPI_DEV_BASE_ORDER + * are reserved for special objects (i.e., system + * resources). Orders between ACPI_DEV_BASE_ORDER and 300 + * are used for Host-PCI bridges (and effectively all + * their children) and CPUs. Larger values are used for + * all other devices. */ ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "scanning '%s'\n", handle_str)); - order = (level + 1) * ACPI_DEV_BASE_ORDER; + order = level * 10 + 300; acpi_probe_order(handle, &order); child = BUS_ADD_CHILD(bus, order, NULL, -1); if (child == NULL) --- //depot/vendor/freebsd/src/sys/dev/cpufreq/ichss.c 2006/05/16 14:41:44 +++ //depot/user/jhb/acpipci/dev/cpufreq/ichss.c 2008/02/28 13:47:21 @@ -92,6 +92,7 @@ rman_get_bushandle((reg)), 0, (val))) static int ichss_pci_probe(device_t dev); +static void ichss_identify(device_t parent, driver_t *driver); static int ichss_probe(device_t dev); static int ichss_attach(device_t dev); static int ichss_detach(device_t dev); @@ -103,6 +104,7 @@ static device_method_t ichss_methods[] = { /* Device interface */ + DEVMETHOD(device_identify, ichss_identify), DEVMETHOD(device_probe, ichss_probe), DEVMETHOD(device_attach, ichss_attach), DEVMETHOD(device_detach, ichss_detach), @@ -130,6 +132,8 @@ static devclass_t ichss_pci_devclass; DRIVER_MODULE(ichss_pci, pci, ichss_pci_driver, ichss_pci_devclass, 0, 0); +static device_t ich_device; + #if 0 #define DPRINT(x...) printf(x) #else @@ -147,8 +151,6 @@ static int ichss_pci_probe(device_t dev) { - device_t child, parent; - uint32_t pmbase; /* * TODO: add a quirk to disable if we see the 82815_MC along @@ -160,46 +162,55 @@ pci_get_device(dev) != PCI_DEV_82801DB)) return (ENXIO); - /* Only one CPU is supported for this hardware. */ - if (devclass_get_device(ichss_devclass, 0)) - return (ENXIO); + ich_device = dev; + return (ENXIO); +} + +static void +ichss_identify(device_t parent, driver_t *driver) +{ + device_t child; + uint32_t pmbase; + + if (ich_device == NULL) + return; + + if (resource_disabled("ichss", 0)) + return; /* - * Add a child under the CPU parent. It appears that ICH SpeedStep - * only requires a single CPU to set the value (since the chipset - * is shared by all CPUs.) Thus, we only add a child to cpu 0. + * It appears that ICH SpeedStep only requires a single CPU to + * set the value (since the chipset is shared by all CPUs.) + * Thus, we only add a child to cpu 0. */ - parent = devclass_get_device(devclass_find("cpu"), 0); - KASSERT(parent != NULL, ("cpu parent is NULL")); - child = BUS_ADD_CHILD(parent, 0, "ichss", 0); - if (child == NULL) { - device_printf(parent, "add SpeedStep child failed\n"); - return (ENXIO); - } + if (device_get_unit(parent) != 0) + return; /* Find the PMBASE register from our PCI config header. */ - pmbase = pci_read_config(dev, ICHSS_PMBASE_OFFSET, sizeof(pmbase)); + pmbase = pci_read_config(ich_device, ICHSS_PMBASE_OFFSET, + sizeof(pmbase)); if ((pmbase & ICHSS_IO_REG) == 0) { printf("ichss: invalid PMBASE memory type\n"); - return (ENXIO); + return; } pmbase &= ICHSS_PMBASE_MASK; if (pmbase == 0) { printf("ichss: invalid zero PMBASE address\n"); - return (ENXIO); + return; } DPRINT("ichss: PMBASE is %#x\n", pmbase); + child = BUS_ADD_CHILD(parent, 0, "ichss", 0); + if (child == NULL) { + device_printf(parent, "add SpeedStep child failed\n"); + return; + } + /* Add the bus master arbitration and control registers. */ bus_set_resource(child, SYS_RES_IOPORT, 0, pmbase + ICHSS_BM_OFFSET, 1); bus_set_resource(child, SYS_RES_IOPORT, 1, pmbase + ICHSS_CTRL_OFFSET, 1); - - /* Attach the new CPU child now. */ - device_probe_and_attach(child); - - return (ENXIO); } static int @@ -207,11 +218,7 @@ { device_t est_dev, perf_dev; int error, type; - uint16_t ss_en; - if (resource_disabled("ichss", 0)) - return (ENXIO); - /* * If the ACPI perf driver has attached and is not just offering * info, let it manage things. Also, if Enhanced SpeedStep is @@ -227,14 +234,6 @@ if (est_dev && device_is_attached(est_dev)) return (ENXIO); - /* Activate SpeedStep control if not already enabled. */ - ss_en = pci_read_config(dev, ICHSS_PMCFG_OFFSET, sizeof(ss_en)); - if ((ss_en & ICHSS_ENABLE) == 0) { - printf("ichss: enabling SpeedStep support\n"); - pci_write_config(dev, ICHSS_PMCFG_OFFSET, - ss_en | ICHSS_ENABLE, sizeof(ss_en)); - } - device_set_desc(dev, "SpeedStep ICH"); return (-1000); } @@ -243,6 +242,7 @@ ichss_attach(device_t dev) { struct ichss_softc *sc; + uint16_t ss_en; sc = device_get_softc(dev); sc->dev = dev; @@ -264,6 +264,14 @@ return (ENXIO); } + /* Activate SpeedStep control if not already enabled. */ + ss_en = pci_read_config(ich_device, ICHSS_PMCFG_OFFSET, sizeof(ss_en)); + if ((ss_en & ICHSS_ENABLE) == 0) { + device_printf(dev, "enabling SpeedStep support\n"); + pci_write_config(ich_device, ICHSS_PMCFG_OFFSET, + ss_en | ICHSS_ENABLE, sizeof(ss_en)); + } + /* Setup some defaults for our exported settings. */ sc->sets[0].freq = CPUFREQ_VAL_UNKNOWN; sc->sets[0].volts = CPUFREQ_VAL_UNKNOWN; -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 14:10:03 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDA671065677 for ; Thu, 28 Feb 2008 14:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A4E878FC13 for ; Thu, 28 Feb 2008 14:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1SEA3oB040909 for ; Thu, 28 Feb 2008 14:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1SEA2wk040906; Thu, 28 Feb 2008 14:10:02 GMT (envelope-from gnats) Date: Thu, 28 Feb 2008 14:10:02 GMT Message-Id: <200802281410.m1SEA2wk040906@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Aurel Bodenmann Cc: Subject: Re: kern/120953: [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is absurd, ignored (-73.0C) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Aurel Bodenmann List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 14:10:03 -0000 The following reply was made to PR kern/120953; it has been noted by GNATS. From: Aurel Bodenmann To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/120953: [acpi]: FreeBSD 6.3 Release: =?UTF-8?Q?=20acpi=5Ftz=30?= =?UTF-8?Q?=3A=20=5FTMP=20value=20is=20absurd=2C=20ignored=20=28-=37=33=2E?= =?UTF-8?Q?=30C=29?= Date: Thu, 28 Feb 2008 14:49:08 +0100 Same here: I'm running FreeBSD 7.0-STABLE, CPU is a Pentium M 1.73 Ghz (CPU: Intel(R) Pentium(R) M processor 1.73GHz (1729.01-MHz 686-class CPU)). The system is an AOpen XC CubeMZ915-M (http://xc.aopen.com.tw/CubeProduct_01.aspx?Auno=2170&mdstyl=22) with a 915G/ICH6 chipset. Below you'll find the dmesg and sysctl output (interesting is, that the sysctl output says temperature is -273.2°C (so 0K) while the dmesg output says something different). # dmesg | tail acpi_tz0: _TMP value is absurd, ignored (-108.0C) acpi_tz0: _TMP value is absurd, ignored (-108.0C) acpi_tz0: _TMP value is absurd, ignored (-109.0C) acpi_tz0: _TMP value is absurd, ignored (-108.0C) acpi_tz0: _TMP value is absurd, ignored (-108.0C) acpi_tz0: _TMP value is absurd, ignored (-107.0C) acpi_tz0: _TMP value is absurd, ignored (-107.0C) acpi_tz0: _TMP value is absurd, ignored (-107.0C) acpi_tz0: _TMP value is absurd, ignored (-105.0C) acpi_tz0: _TMP value is absurd, ignored (-108.0C) # sysctl hw.acpi.thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: -273.2C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 50.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 100.0C hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 4 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 60 With kind regards Aurel Bodenmann -- WWW: http://www.bodenmann.biz E-Mail: mailto:aurel@bodenmann.biz Home: ++41 (0)79 824 31 22 Always look on the bright side of life! From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 18:11:15 2008 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 46D7C1065672 for ; Thu, 28 Feb 2008 18:11:15 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id D86EE8FC20 for ; Thu, 28 Feb 2008 18:11:14 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 40683 invoked from network); 28 Feb 2008 18:11:15 -0000 Received: from adsl-71-141-98-131.dsl.snfc21.pacbell.net (HELO ?192.168.1.77?) (nate-mail@71.141.98.131) by root.org with ESMTPA; 28 Feb 2008 18:11:15 -0000 Message-ID: <47C6F939.4060301@root.org> Date: Thu, 28 Feb 2008 10:11:05 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: John Baldwin References: <47B96989.6070008@icyb.net.ua> <200802271126.30132.jhb@freebsd.org> <47C5E0A6.5030102@icyb.net.ua> <200802280856.31548.jhb@freebsd.org> In-Reply-To: <200802280856.31548.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Andriy Gapon Subject: Re: acpi_throttle: quirk based on pci info 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, 28 Feb 2008 18:11:15 -0000 John Baldwin wrote: > Actually, we can make ichss rather simple w/o changing it much by having it > just set a global variable in its PCI probe routine and checking that global > when attaching to the CPU. I like your approach. > One other thing that concerns me is that cpufreq drivers want to know about > each other (e.g. smist checks for ichss0, etc.). I'd rather that if we have > multiple drivers controlling the same back-end hardware (via difference > interfaces) they all use the same driver name (e.g. speedstep0) and use probe > priority to decide which driver wins if both ichss0 and smist0 can handle a > CPU for example. It took me a while to figure out what the generic interface was actually hooking up to in terms of hardware. For example, some laptops export p4tcc via acpi_throttle. Others export a SMI/BIOS equivalent that programs the chipset instead of the CPU. Unfortunately, there doesn't seem to be an easy way to figure out if two drivers are talking to the same hardware so it seems the right choice is to only use the generic interface if the hw-specific one fails to attach. I think making acpi_throttle attach at a lower priority than ichss, est, and smist is the best approach. I wouldn't want to change the names as it would be hard to figure out which hw is actually being driven. Still, there needs to be a way for them to indicate that they attach to the same hw as acpi_throttle. Your global may be the best approach for now. > Here is a patch to make CPUs come after PCI and an attempt to fix ICH. Note > that if we made ichss_identify() manually look for the PCI device by bsf > instead of using a probe routine to find it we could remove the pci "driver" > completely and make it work on kldload. It also fixes a bug that the attempt > to enable SS via a PCI config register write could never work as it passed a > cpu0 device_t to pci_read_config/pci_write_config in ichss_probe() > previously. I moved this to attach() (where it belongs) and used the right > device_t so this should work now. I have no hardware to test it on though. ICH SpeedStep is pretty old. You need Pentium 3 era laptops, i.e IBM T23. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 18:17:54 2008 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 34C28106566B for ; Thu, 28 Feb 2008 18:17:54 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6A48FC24 for ; Thu, 28 Feb 2008 18:17:54 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 43773 invoked from network); 28 Feb 2008 18:17:54 -0000 Received: from adsl-71-141-98-131.dsl.snfc21.pacbell.net (HELO ?192.168.1.77?) (nate-mail@71.141.98.131) by root.org with ESMTPA; 28 Feb 2008 18:17:54 -0000 Message-ID: <47C6FACC.9090502@root.org> Date: Thu, 28 Feb 2008 10:17:48 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Andriy Gapon References: <47C67001.20101@icyb.net.ua> In-Reply-To: <47C67001.20101@icyb.net.ua> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: mismatch between FACP and chipset spec 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, 28 Feb 2008 18:17:54 -0000 Andriy Gapon wrote: > As some of you probably already know I have a motherboard based on > 440BX/PIIX4E chipset: > http://www.geocities.com/SiliconValley/3686/delta_mp2.html > > Here's some info from ACPI tables: > PM1a_EVT_BLK=0x4000-0x4003 > PM1a_CNT_BLK=0x4040-0x4041 > PM_TMR_BLK=0x4008-0x400b > > I know that in my case 0x4000 is a base address of "Power Management IO > Space" (as defined by PIIX4 specification). > I see that descriptions of the registers and their bits match between > ACPI specification and PIIX4 specification for registers in PM1a_EVT_BLK > (PMSTS and PMEN registers in PIIX4 parlance) and PM_TMR_BLK (PMTMP > register in PIIX4 parlance). > But addresses given for PM1a_CNT_BLK are not documented at all! On the > other hand ACPI description of that register perfectly matches > description of PIIX4 PMCNTRL register that is located at 0x4004 with a > given base address. So, this is 0x4040 vs. 0x4004, looks like a possible > typo/mistake by an author of ACPI tables for this motherboard. 440BX is pretty old, and typos like that were common back then. ACPI was less used and drivers would just hardcode 0x4004 or whatever. > Question: is there any way I can way override the address of > PM1a_CNT_BLK? My guess is that there is zero chance that there would be > any BIOS updates for this old and exotic motherboard (MP2-BX-X). No generic way. You'd have to add a quirk to acpi.c/acpi_quirks and use that to override FADT. > I think that this register is mostly useful for BM_RLD bit which is used > in C3 support. I don't use C3 (there is an errata for C3 with this > chipset and there is no PM2_CNT register defined anyway), but I am > curios anyway. Seems like a lot of effort for no gain. Since you are getting good at debugging, can we get you newer hardware to play with? :) > And a mostly unrelated question. From the following code it seems that > linux won't go even into C2 state if there is any bus master activity > detected (but I am not what would happen with "demotion"/"promotion"): > http://lxr.linux.no/linux/drivers/acpi/processor_idle.c#L389 I don't think so. I think cx->demotion.threshold.bm is a flag that says whether the idle state the CPU is entering requires bus mastering awareness. It will probably only be set for C3. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 18:54:05 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 169061065670 for ; Thu, 28 Feb 2008 18:54:05 +0000 (UTC) (envelope-from SRS0=658fa5cc26f7e4877ad0c167a9a47d5ad903c517=625=es.net=oberman@es.net) Received: from postal1.es.net (postal3.es.net [IPv6:2001:400:14:3::8]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4FA8FC1A for ; Thu, 28 Feb 2008 18:54:04 +0000 (UTC) (envelope-from SRS0=658fa5cc26f7e4877ad0c167a9a47d5ad903c517=625=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IUE13902 for ; Thu, 28 Feb 2008 10:54:02 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 7B7F74500E for ; Thu, 28 Feb 2008 10:54:02 -0800 (PST) To: acpi@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1204224842_12619P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 28 Feb 2008 10:54:02 -0800 From: "Kevin Oberman" Message-Id: <20080228185402.7B7F74500E@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; X-Sender: X-To_Name: X-To_Domain: freebsd.org X-To: acpi@freebsd.org X-To_Email: acpi@freebsd.org X-To_Alias: acpi Cc: Subject: 7.0 systems shows no CPU states numbers with ACPI 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, 28 Feb 2008 18:54:05 -0000 --==_Exmh_1204224842_12619P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have an old Dell desktop with a 1 GHz PIII CPU. After upgrade to V7 yesterday I no longer see any CPU usage information in top(1) or the CPU plots in gkrellm. (Yes, my kernel and world are in sync and I cleaned out /usr/obj/* and /usr/include/* when I upgraded my system.) I disabled ACPI and everything worked again. The ASL is pretty small. The output of acpidump -dt is only about 3100 lines. I have placed it along with a verbose dmesg and the config (PAK) at: http://home.comcast.net/~ykoberman/FreeBSD/pak.asl.bz2 http://home.comcast.net/~ykoberman/FreeBSD/PAK http://home.comcast.net/~ykoberman/FreeBSD/dmesg.boot Any idea what failed? I was running current on this system in the middle of last year and it worked then, so it was sometime between then and now. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1204224842_12619P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFHxwNKkn3rs5h7N1ERAoXqAKCmrGxGd4lXhtPxZ3Ed9yIZzXh/ngCeOgk+ zBOqpQ/JqyrV5KyRDtWoILo= =oY6l -----END PGP SIGNATURE----- --==_Exmh_1204224842_12619P-- From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 19:05:00 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A8081065670 for ; Thu, 28 Feb 2008 19:05:00 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 5980A8FC13 for ; Thu, 28 Feb 2008 19:05:00 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 62415 invoked from network); 28 Feb 2008 19:05:01 -0000 Received: from adsl-71-141-98-131.dsl.snfc21.pacbell.net (HELO ?192.168.1.77?) (nate-mail@71.141.98.131) by root.org with ESMTPA; 28 Feb 2008 19:05:01 -0000 Message-ID: <47C705D6.6080706@root.org> Date: Thu, 28 Feb 2008 11:04:54 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Kevin Oberman References: <20080228185402.7B7F74500E@ptavv.es.net> In-Reply-To: <20080228185402.7B7F74500E@ptavv.es.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org Subject: Re: 7.0 systems shows no CPU states numbers with ACPI 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, 28 Feb 2008 19:05:00 -0000 Kevin Oberman wrote: > I have an old Dell desktop with a 1 GHz PIII CPU. > > After upgrade to V7 yesterday I no longer see any CPU usage information > in top(1) or the CPU plots in gkrellm. (Yes, my kernel and world are in > sync and I cleaned out /usr/obj/* and /usr/include/* when I upgraded my > system.) I disabled ACPI and everything worked again. > > The ASL is pretty small. The output of acpidump -dt is only about 3100 > lines. I have placed it along with a verbose dmesg and the config (PAK) at: > http://home.comcast.net/~ykoberman/FreeBSD/pak.asl.bz2 > http://home.comcast.net/~ykoberman/FreeBSD/PAK > http://home.comcast.net/~ykoberman/FreeBSD/dmesg.boot > > Any idea what failed? I was running current on this system in the middle > of last year and it worked then, so it was sometime between then and now. Only thing I can think of is that cpufreq is now enabled by default. Try disabling it: hint.cpufreq.0.disabled="1" -- Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 19:14:45 2008 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 C8FB31065670 for ; Thu, 28 Feb 2008 19:14:45 +0000 (UTC) (envelope-from kayve@sfsu.edu) Received: from iron3.sfsu.edu (iron3.sfsu.edu [130.212.10.128]) by mx1.freebsd.org (Postfix) with ESMTP id A78A18FC27 for ; Thu, 28 Feb 2008 19:14:45 +0000 (UTC) (envelope-from kayve@sfsu.edu) X-onepass: IPPSC X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAGaQxkeC1Apk/2dsb2JhbACRepw/ Received: from smtp01.sfsu.edu ([130.212.10.100]) by iron3.sfsu.edu with ESMTP; 28 Feb 2008 10:46:37 -0800 Received: from libra.sfsu.edu ([130.212.10.238]) by mail05a.sfsu.edu (Lotus Domino Release 7.0.3HF100) with ESMTP id 2008022810463738-117 ; Thu, 28 Feb 2008 10:46:37 -0800 Date: Thu, 28 Feb 2008 10:46:37 -0800 (PST) From: KAYVEN RIESE To: freebsd-acpi@freebsd.org Message-ID: MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MAIL05a/SERVERS/SFSU(Release 7.0.3HF100 | December 5, 2007) at 02/28/2008 10:46:37, Serialize by Router on SMTP01/SERVERS/SFSU(Release 7.0.3HF312 | February 8, 2008) at 02/28/2008 10:46:38, Serialize complete at 02/28/2008 10:46:38 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: ACPI errors in dmesg 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, 28 Feb 2008 19:14:45 -0000 I have ACPI errors in my dmesg, and I don't know what to do about it. Do I need new hardware? If so, can I get more specific information? How do I fix this? Follows is the first part of dmesg with the errors: kv_bsd#dmesg Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.73GHz (600.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff Features2=0x180 AMD Features=0x100000 real memory = 1072955392 (1023 MB) avail memory = 1040961536 (992 MB) kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_.ACS_] (Node 0xc4ba8440), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed [\\_SB_.AC__._INI] (Node 0xc4bac0a0), AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST acpi0: Power Button (fixed) ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node 0xc4baf420), AE_NOT_EXIST Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 *----------------------------------------------------------* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *----------------------------------------------------------* From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 19:17:34 2008 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 0AAF0106566C; Thu, 28 Feb 2008 19:17:34 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 69FF88FC26; Thu, 28 Feb 2008 19:17:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id C339974400A; Thu, 28 Feb 2008 21:17:31 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id VRBMt37nlbnF; Thu, 28 Feb 2008 21:17:31 +0200 (EET) Received: from [91.193.172.111] (unknown [91.193.172.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 7E32443F5C4; Thu, 28 Feb 2008 21:17:30 +0200 (EET) Message-ID: <47C708BE.3020108@icyb.net.ua> Date: Thu, 28 Feb 2008 21:17:18 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: Nate Lawson References: <47B96989.6070008@icyb.net.ua> <200802271126.30132.jhb@freebsd.org> <47C5E0A6.5030102@icyb.net.ua> <200802280856.31548.jhb@freebsd.org> <47C6F939.4060301@root.org> In-Reply-To: <47C6F939.4060301@root.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 28 Feb 2008 19:17:34 -0000 on 28/02/2008 20:11 Nate Lawson said the following: > John Baldwin wrote: >> Actually, we can make ichss rather simple w/o changing it much by having it >> just set a global variable in its PCI probe routine and checking that global >> when attaching to the CPU. > > I like your approach. I like it too. And I also think that if pci-cpu ordering is implemented, then pci_find_bsf approach that John mentioned should work too. So there would be no need to attach to pci bus at all - all pci-specific stuff could be done through the chipset device. >> One other thing that concerns me is that cpufreq drivers want to know about >> each other (e.g. smist checks for ichss0, etc.). I'd rather that if we have >> multiple drivers controlling the same back-end hardware (via difference >> interfaces) they all use the same driver name (e.g. speedstep0) and use probe >> priority to decide which driver wins if both ichss0 and smist0 can handle a >> CPU for example. > > It took me a while to figure out what the generic interface was actually > hooking up to in terms of hardware. For example, some laptops export > p4tcc via acpi_throttle. Others export a SMI/BIOS equivalent that > programs the chipset instead of the CPU. Unfortunately, there doesn't > seem to be an easy way to figure out if two drivers are talking to the > same hardware so it seems the right choice is to only use the generic > interface if the hw-specific one fails to attach. > > I think making acpi_throttle attach at a lower priority than ichss, est, > and smist is the best approach. I wouldn't want to change the names as > it would be hard to figure out which hw is actually being driven. > Still, there needs to be a way for them to indicate that they attach to > the same hw as acpi_throttle. Your global may be the best approach for now. And there is another thing: as I understand there could be multiple "cpufreq-ish" devices attached simultaneously - some providing absolute values, some providing relative ones, and "the" cpufreq device aggregates them. John's suggestion has a lot of appeal. Maybe it could be implemented in some other form, but that definitely would require detailed analysis. >> Here is a patch to make CPUs come after PCI and an attempt to fix ICH. Note >> that if we made ichss_identify() manually look for the PCI device by bsf >> instead of using a probe routine to find it we could remove the pci "driver" >> completely and make it work on kldload. It also fixes a bug that the attempt >> to enable SS via a PCI config register write could never work as it passed a >> cpu0 device_t to pci_read_config/pci_write_config in ichss_probe() >> previously. I moved this to attach() (where it belongs) and used the right >> device_t so this should work now. I have no hardware to test it on though. > > ICH SpeedStep is pretty old. You need Pentium 3 era laptops, i.e IBM T23. Unfortunately I can not test this particular driver too for the same reason. I will test the acpi ordering patch and its interaction with acpi_throttle (with my private quirk for PIIX4E). -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 19:29:18 2008 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 82749106566C for ; Thu, 28 Feb 2008 19:29:18 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id E603B8FC1A for ; Thu, 28 Feb 2008 19:29:17 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id BE49F74400B; Thu, 28 Feb 2008 21:29:16 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id GxBE217EDPgI; Thu, 28 Feb 2008 21:29:16 +0200 (EET) Received: from [91.193.172.111] (unknown [91.193.172.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id D70C374400A; Thu, 28 Feb 2008 21:29:15 +0200 (EET) Message-ID: <47C70B87.5060301@icyb.net.ua> Date: Thu, 28 Feb 2008 21:29:11 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: Nate Lawson References: <47C67001.20101@icyb.net.ua> <47C6FACC.9090502@root.org> In-Reply-To: <47C6FACC.9090502@root.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: mismatch between FACP and chipset spec 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, 28 Feb 2008 19:29:18 -0000 on 28/02/2008 20:17 Nate Lawson said the following: > Andriy Gapon wrote: >> As some of you probably already know I have a motherboard based on >> 440BX/PIIX4E chipset: >> http://www.geocities.com/SiliconValley/3686/delta_mp2.html >> >> Here's some info from ACPI tables: >> PM1a_EVT_BLK=0x4000-0x4003 >> PM1a_CNT_BLK=0x4040-0x4041 >> PM_TMR_BLK=0x4008-0x400b >> >> I know that in my case 0x4000 is a base address of "Power Management IO >> Space" (as defined by PIIX4 specification). >> I see that descriptions of the registers and their bits match between >> ACPI specification and PIIX4 specification for registers in PM1a_EVT_BLK >> (PMSTS and PMEN registers in PIIX4 parlance) and PM_TMR_BLK (PMTMP >> register in PIIX4 parlance). >> But addresses given for PM1a_CNT_BLK are not documented at all! On the >> other hand ACPI description of that register perfectly matches >> description of PIIX4 PMCNTRL register that is located at 0x4004 with a >> given base address. So, this is 0x4040 vs. 0x4004, looks like a possible >> typo/mistake by an author of ACPI tables for this motherboard. > > 440BX is pretty old, and typos like that were common back then. ACPI > was less used and drivers would just hardcode 0x4004 or whatever. > >> Question: is there any way I can way override the address of >> PM1a_CNT_BLK? My guess is that there is zero chance that there would be >> any BIOS updates for this old and exotic motherboard (MP2-BX-X). > > No generic way. You'd have to add a quirk to acpi.c/acpi_quirks and use > that to override FADT. > >> I think that this register is mostly useful for BM_RLD bit which is used >> in C3 support. I don't use C3 (there is an errata for C3 with this >> chipset and there is no PM2_CNT register defined anyway), but I am >> curios anyway. > > Seems like a lot of effort for no gain. Since you are getting good at > debugging, can we get you newer hardware to play with? :) Nate, thank you for pointing me to acpi_quirks and for confirming my doubts over worthwhileness of this endeavor. And thanks for the compliment too :-) As to the question that followed it - I am very "selfish" when it comes to my FreeBSD contributions. That is, I use FreeBSD for a variety of applications and my contributions are what I really need here and now. And sometimes I really do need something, and sometimes it's just an "itch". But I am thinking about getting a laptop soon. Of course I will install FreeBSD on it, so it might be that something useful for other people will come of it. Maybe someday (when I get a lot of free time) I will even consider taking on hibernation. >> And a mostly unrelated question. From the following code it seems that >> linux won't go even into C2 state if there is any bus master activity >> detected (but I am not what would happen with "demotion"/"promotion"): >> http://lxr.linux.no/linux/drivers/acpi/processor_idle.c#L389 > > I don't think so. I think cx->demotion.threshold.bm is a flag that says > whether the idle state the CPU is entering requires bus mastering > awareness. It will probably only be set for C3. Got it. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 20:43:23 2008 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 9FA721065677 for ; Thu, 28 Feb 2008 20:43:23 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 678438FC26 for ; Thu, 28 Feb 2008 20:43:23 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 6D1CA61BB2E; Thu, 28 Feb 2008 12:17:52 -0800 (PST) Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25708-10; Thu, 28 Feb 2008 12:17:51 -0800 (PST) Received: from iago.office.miralink.com (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id F3AC961BB26; Thu, 28 Feb 2008 12:17:50 -0800 (PST) Message-ID: <47C716EE.3040909@miralink.com> Date: Thu, 28 Feb 2008 12:17:50 -0800 From: Sean Bruno User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: KAYVEN RIESE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Feb 28 12:17:52 2008 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 47c716f0190861592213743 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.499 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1, UPPERCASE_25_50=0] X-Spam-Score: -4.499 X-Spam-Level: Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI errors in dmesg 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, 28 Feb 2008 20:43:23 -0000 KAYVEN RIESE wrote: > > I have ACPI errors in my dmesg, and I don't know what to do about > it. Do I need new hardware? If so, can I get more specific information? > How do I fix this? > > Follows is the first part of dmesg with the errors: > > > kv_bsd#dmesg > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 > root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) M processor 1.73GHz (600.02-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 > > Features=0xafe9fbff > > Features2=0x180 > AMD Features=0x100000 > real memory = 1072955392 (1023 MB) > avail memory = 1040961536 (992 MB) > kbd1 at kbdmux0 > ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) > acpi0: on motherboard > ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler > ACPI-1304: *** Error: Method execution failed > [\\_SB_.PCI0.SBRG.EC0_.ACS_] (Node 0xc4ba8440), AE_NOT_EXIST > ACPI-1304: *** Error: Method execution failed [\\_SB_.AC__._INI] > (Node 0xc4bac0a0), AE_NOT_EXIST > ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler > ACPI-1304: *** Error: Method execution failed > [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST > ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > acpi0: Power Button (fixed) > ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler > ACPI-1304: *** Error: Method execution failed > [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST > ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler > ACPI-1304: *** Error: Method execution failed > [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST > ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler > ACPI-1304: *** Error: Method execution failed > [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST > ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler > ACPI-1304: *** Error: Method execution failed > [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST > ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler > ACPI-1304: *** Error: Method execution failed > [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST > ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler > ACPI-1304: *** Error: Method execution failed > [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST > ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler > ACPI-1304: *** Error: Method execution failed > [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST > ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] > (Node 0xc4baf420), AE_NOT_EXIST > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > Can you please post your motherboard model and BIOS revision? Sean From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 21:09:58 2008 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 A54221065672 for ; Thu, 28 Feb 2008 21:09:58 +0000 (UTC) (envelope-from kayve@sfsu.edu) Received: from iron1.sfsu.edu (iron1.sfsu.edu [130.212.10.35]) by mx1.freebsd.org (Postfix) with ESMTP id 7BBF38FC15 for ; Thu, 28 Feb 2008 21:09:58 +0000 (UTC) (envelope-from kayve@sfsu.edu) X-onepass: IPPSC X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJixxkeC1Apk/2dsb2JhbACuQg Received: from smtp01.sfsu.edu ([130.212.10.100]) by iron1.sfsu.edu with ESMTP; 28 Feb 2008 13:09:58 -0800 Received: from libra.sfsu.edu ([130.212.10.238]) by mail05a.sfsu.edu (Lotus Domino Release 7.0.3HF100) with ESMTP id 2008022813095610-143 ; Thu, 28 Feb 2008 13:09:56 -0800 Date: Thu, 28 Feb 2008 13:09:55 -0800 (PST) From: KAYVEN RIESE To: Sean Bruno In-Reply-To: <47C716EE.3040909@miralink.com> Message-ID: References: <47C716EE.3040909@miralink.com> MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MAIL05a/SERVERS/SFSU(Release 7.0.3HF100 | December 5, 2007) at 02/28/2008 13:09:56, Serialize by Router on SMTP01/SERVERS/SFSU(Release 7.0.3HF312 | February 8, 2008) at 02/28/2008 13:09:56, Serialize complete at 02/28/2008 13:09:56 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI errors in dmesg 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, 28 Feb 2008 21:09:58 -0000 On Thu, 28 Feb 2008, Sean Bruno wrote: > KAYVEN RIESE wrote: >> >> I have ACPI errors in my dmesg, and I don't know what to do about >> it. Do I need new hardware? If so, can I get more specific information? >> How do I fix this? >> >> Follows is the first part of dmesg with the errors: >> >> >> kv_bsd#dmesg >> Copyright (c) 1992-2007 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 >> root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Pentium(R) M processor 1.73GHz (600.02-MHz 686-class CPU) >> Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 >> >> Features=0xafe9fbff >> Features2=0x180 >> AMD Features=0x100000 >> real memory = 1072955392 (1023 MB) >> avail memory = 1040961536 (992 MB) >> kbd1 at kbdmux0 >> ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) >> acpi0: on motherboard >> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >> ACPI-1304: *** Error: Method execution failed >> [\\_SB_.PCI0.SBRG.EC0_.ACS_] (Node 0xc4ba8440), AE_NOT_EXIST >> ACPI-1304: *** Error: Method execution failed [\\_SB_.AC__._INI] (Node >> 0xc4bac0a0), AE_NOT_EXIST >> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >> ACPI-1304: *** Error: Method execution failed >> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> acpi0: Power Button (fixed) >> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >> ACPI-1304: *** Error: Method execution failed >> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >> ACPI-1304: *** Error: Method execution failed >> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >> ACPI-1304: *** Error: Method execution failed >> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >> ACPI-1304: *** Error: Method execution failed >> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >> ACPI-1304: *** Error: Method execution failed >> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >> ACPI-1304: *** Error: Method execution failed >> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >> ACPI-1304: *** Error: Method execution failed >> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node >> 0xc4baf420), AE_NOT_EXIST >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> > Can you please post your motherboard model and BIOS revision? I'm not really sure how to do that, but here is a free photoserver where I have pictures of my BIOS: http://www.monkeyview.net/id/965/fsck/bios/index.vhtml (click on one of the more interesting of the 49 photos there for a better look) Here is a super album with more pictures: http://www.monkeyview.net/id/965/fsck/index.vhtml Will the rest of the dmesg output help? Here that is acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe0000000-0xefffffff at device 0.0 o n pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) uhci0: port 0xe800-0xe81f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe880-0xe89f irq 5 at d evice 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xec00-0xec1f irq 10 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xffaffc00-0xffafffff i rq 10 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 bge0: mem 0xff9f0000-0xff9fffff irq 4 at device 0.0 on pci2 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge0: Ethernet address: 00:11:d8:22:c9:91 cbb0: at device 1.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: at device 1.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 fwohci0: mem 0xff9ef800-0xff9effff irq 10 at device 1.2 on pci2 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:e0:18:00:03:26:4c:e9 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:e0:18:26:4c:e9 fwe0: Ethernet address: 02:e0:18:26:4c:e9 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci2: at device 2.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x37 6,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcm0: port 0xee00-0xeeff,0xe000-0xe03f mem 0xffaff800-0xf faff9ff,0xffaff400-0xffaff4ff irq 4 at device 31.5 on pci0 pcm0: pci0: at device 31.6 (no driver attached) acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 port 0x2f8-0x2ff irq 3 drq 1 flags 0x10 on acpi0 sio0: type 16550A ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on ac pi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: Logitech USB Optical Mouse, rev 2.00/43.01, addr 2, iclass 3/1 ums0: 8 buttons and Z dir. Timecounter "TSC" frequency 600024447 Hz quality 800 Timecounters tick every 1.000 msec ad0: 114473MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s2a bge0: link state changed to DOWN cpu0: Cx states changed cpu0: Cx states changed bge0: link state changed to UP pid 54590 (npviewer.bin), uid 1001: exited on signal 11 (core dumped) > > Sean > > *----------------------------------------------------------* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *----------------------------------------------------------* From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 21:15:02 2008 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 C91D5106567C for ; Thu, 28 Feb 2008 21:15:02 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by mx1.freebsd.org (Postfix) with ESMTP id 76AF38FC2D for ; Thu, 28 Feb 2008 21:15:02 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so3985425wxd.7 for ; Thu, 28 Feb 2008 13:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=XkKHMMy5waCqAYo7ZDZtVLyVoKdlqYyKk/0qMvFQNxM=; b=SznWGsVRrapcZ3l5qvdadSH0LGzNFoA+z1iP1hBeOc0rkkROnakdacVJXFwyok2oL/2LvJtlhs76Fzz1Fv4SaHpN7L07BSVlepRpLesdGf5/qr5Nac1kMfPuolO2d4cYkcAjI/JEgn+gLZw2BHkPANrMZfD4rH4U1Nbz/tfAPE4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=utbHjZN53+HsSvz8xIkR5m6L2bpjeZznypY7kUqqr4g0sc3oDt+76ScBaeS+VZUYQIl8YPSXBW9fCa2BSqfDvFUR/UxneF+KSBEFaVzFWixavXlxoImUtuOPmvae0dmn4+adYJW4GJzfb94bP+Etah4wZPdsIn0/bzZGpJiWIiw= Received: by 10.100.96.9 with SMTP id t9mr16608930anb.35.1204233301682; Thu, 28 Feb 2008 13:15:01 -0800 (PST) Received: by 10.100.153.10 with HTTP; Thu, 28 Feb 2008 13:15:01 -0800 (PST) Message-ID: Date: Thu, 28 Feb 2008 21:15:01 +0000 From: "Rui Paulo" Sender: rpaulo@gmail.com To: "Andriy Gapon" In-Reply-To: <47C6A92C.7000700@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47C67001.20101@icyb.net.ua> <47C6A92C.7000700@icyb.net.ua> X-Google-Sender-Auth: 436580077160cf4e Cc: freebsd-acpi@freebsd.org Subject: Re: mismatch between FACP and chipset spec 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, 28 Feb 2008 21:15:02 -0000 On Thu, Feb 28, 2008 at 12:29 PM, Andriy Gapon wrote: > on 28/02/2008 11:52 Rui Paulo said the following: > > > > On Thu, Feb 28, 2008 at 8:25 AM, Andriy Gapon wrote: > >> As some of you probably already know I have a motherboard based on > >> 440BX/PIIX4E chipset: > >> http://www.geocities.com/SiliconValley/3686/delta_mp2.html > >> > >> Here's some info from ACPI tables: > >> PM1a_EVT_BLK=0x4000-0x4003 > >> PM1a_CNT_BLK=0x4040-0x4041 > >> PM_TMR_BLK=0x4008-0x400b > >> > >> I know that in my case 0x4000 is a base address of "Power Management IO > >> Space" (as defined by PIIX4 specification). > >> I see that descriptions of the registers and their bits match between > >> ACPI specification and PIIX4 specification for registers in PM1a_EVT_BLK > >> (PMSTS and PMEN registers in PIIX4 parlance) and PM_TMR_BLK (PMTMP > >> register in PIIX4 parlance). > >> But addresses given for PM1a_CNT_BLK are not documented at all! On the > >> other hand ACPI description of that register perfectly matches > >> description of PIIX4 PMCNTRL register that is located at 0x4004 with a > >> given base address. So, this is 0x4040 vs. 0x4004, looks like a possible > >> typo/mistake by an author of ACPI tables for this motherboard. > >> > >> Question: is there any way I can way override the address of > >> PM1a_CNT_BLK? My guess is that there is zero chance that there would be > >> any BIOS updates for this old and exotic motherboard (MP2-BX-X). > > > > Try dumping your ACPI tables, change the address and load the new > > tables on boot, > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html > > I have some experience with that (and I've been planning to share it for > several years now). > My impression that only DSDT can be changed this way, not the fixed > tables. I could be wrong. Yes, I failed to see that this was not the DSDT. Sorry. -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 21:15:52 2008 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 5B2CD10656A7 for ; Thu, 28 Feb 2008 21:15:52 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id F00718FC17 for ; Thu, 28 Feb 2008 21:15:51 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id DEFB161BB1E; Thu, 28 Feb 2008 13:15:50 -0800 (PST) Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31941-09; Thu, 28 Feb 2008 13:15:47 -0800 (PST) Received: from iago.office.miralink.com (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id 6B5F061B9A3; Thu, 28 Feb 2008 13:15:47 -0800 (PST) Message-ID: <47C72483.1080709@miralink.com> Date: Thu, 28 Feb 2008 13:15:47 -0800 From: Sean Bruno User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: KAYVEN RIESE References: <47C716EE.3040909@miralink.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Feb 28 13:15:50 2008 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 47c72486164421410093335 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.499 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1] X-Spam-Score: -4.499 X-Spam-Level: Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI errors in dmesg 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, 28 Feb 2008 21:15:52 -0000 KAYVEN RIESE wrote: > > On Thu, 28 Feb 2008, Sean Bruno wrote: >> KAYVEN RIESE wrote: >>> >>> I have ACPI errors in my dmesg, and I don't know what to do about >>> it. Do I need new hardware? If so, can I get more specific >>> information? >>> How do I fix this? >>> >>> Follows is the first part of dmesg with the errors: >>> >>> >>> kv_bsd#dmesg >>> Copyright (c) 1992-2007 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, >>> 1994 >>> The Regents of the University of California. All rights >>> reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 >>> root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>> CPU: Intel(R) Pentium(R) M processor 1.73GHz (600.02-MHz 686-class CPU) >>> Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 >>> >>> Features=0xafe9fbff >>> >>> Features2=0x180 >>> AMD Features=0x100000 >>> real memory = 1072955392 (1023 MB) >>> avail memory = 1040961536 (992 MB) >>> kbd1 at kbdmux0 >>> ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >>> RF5413) >>> acpi0: on motherboard >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.ACS_] (Node 0xc4ba8440), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.AC__._INI] >>> (Node 0xc4bac0a0), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> acpi0: Power Button (fixed) >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>> >> Can you please post your motherboard model and BIOS revision? > > I'm not really sure how to do that, but here is a free photoserver > where I have pictures of my BIOS: > > http://www.monkeyview.net/id/965/fsck/bios/index.vhtml > > (click on one of the more interesting of the 49 photos there for > a better look) > > Here is a super album with more pictures: > > http://www.monkeyview.net/id/965/fsck/index.vhtml > > Will the rest of the dmesg output help? Here that is > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > cpu0: on acpi0 > acpi_throttle0: on cpu0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: mem 0xe0000000-0xefffffff at > device 0.0 o > n pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > uhci0: port 0xe800-0xe81f > irq 11 at > device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0xe880-0xe89f > irq 5 at d > evice 29.1 on pci0 > uhci1: [GIANT-LOCKED] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0xec00-0xec1f > irq 10 at > device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub2: 2 ports with 2 removable, self powered > ehci0: mem > 0xffaffc00-0xffafffff i > rq 10 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > usb3: EHCI version 1.0 > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 > uhub3: 6 ports with 6 removable, self powered > pcib2: at device 30.0 on pci0 > pci2: on pcib2 > bge0: mem > 0xff9f0000-0xff9fffff irq 4 at > device 0.0 on pci2 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX > -FDX, auto > bge0: Ethernet address: 00:11:d8:22:c9:91 > cbb0: at device 1.0 on pci2 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb1: at device 1.1 on pci2 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > fwohci0: mem 0xff9ef800-0xff9effff irq 10 at device 1.2 > on pci2 > fwohci0: OHCI version 1.0 (ROM=1) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:e0:18:00:03:26:4c:e9 > fwohci0: Phy 1394a available S400, 2 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:e0:18:26:4c:e9 > fwe0: Ethernet address: 02:e0:18:26:4c:e9 > fwe0: if_start running deferred for Giant > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire0: bus manager 0 (me) > pci2: at device 2.0 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x37 > 6,0xffa0-0xffaf at device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > pcm0: port 0xee00-0xeeff,0xe000-0xe03f mem > 0xffaff800-0xf > faff9ff,0xffaff400-0xffaff4ff irq 4 at device 31.5 on pci0 > pcm0: > pci0: at device 31.6 (no driver attached) > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_acad0: on acpi0 > battery0: on acpi0 > battery1: on acpi0 > acpi_button1: on acpi0 > acpi_tz0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > sio0: configured irq 3 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0 port 0x2f8-0x2ff irq 3 drq 1 flags 0x10 on acpi0 > sio0: type 16550A > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 > drq 3 on ac > pi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xcffff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ums0: Logitech USB Optical Mouse, rev 2.00/43.01, addr 2, iclass 3/1 > ums0: 8 buttons and Z dir. > Timecounter "TSC" frequency 600024447 Hz quality 800 > Timecounters tick every 1.000 msec > ad0: 114473MB at ata0-master UDMA100 > acd0: DVDR at ata1-master UDMA33 > Trying to mount root from ufs:/dev/ad0s2a > bge0: link state changed to DOWN > cpu0: Cx states changed > cpu0: Cx states changed > bge0: link state changed to UP > pid 54590 (npviewer.bin), uid 1001: exited on signal 11 (core dumped) > > >> >> Sean >> >> > > *----------------------------------------------------------* > Kayven Riese, BSCS, MS (Physiology and Biophysics) > (415) 902 5513 cellular > http://kayve.net > Webmaster http://ChessYoga.org > *----------------------------------------------------------* Ok, your BIOS version is 0208 I think. Who made your computer? Maybe from the make and model of the computer we can determine if there is a BIOS update for it. Sean From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 21:20:47 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B479E1065678 for ; Thu, 28 Feb 2008 21:20:47 +0000 (UTC) (envelope-from SRS0=658fa5cc26f7e4877ad0c167a9a47d5ad903c517=625=es.net=oberman@es.net) Received: from postal1.es.net (postal4.es.net [IPv6:2001:400:6000:1::66]) by mx1.freebsd.org (Postfix) with ESMTP id CCE788FC14 for ; Thu, 28 Feb 2008 21:20:46 +0000 (UTC) (envelope-from SRS0=658fa5cc26f7e4877ad0c167a9a47d5ad903c517=625=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id IXW79344; Thu, 28 Feb 2008 13:20:44 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C21404500E; Thu, 28 Feb 2008 13:20:43 -0800 (PST) To: Nate Lawson In-Reply-To: Your message of "Thu, 28 Feb 2008 11:04:54 PST." <47C705D6.6080706@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1204233643_15386P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 28 Feb 2008 13:20:43 -0800 From: "Kevin Oberman" Message-Id: <20080228212043.C21404500E@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ;; X-Sender: X-To_Name: Nate Lawson X-To_Domain: root.org X-To: Nate Lawson X-To_Email: nate@root.org X-To_Alias: nate Cc: acpi@freebsd.org Subject: Re: 7.0 systems shows no CPU states numbers with ACPI 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, 28 Feb 2008 21:20:47 -0000 --==_Exmh_1204233643_15386P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Thu, 28 Feb 2008 11:04:54 -0800 > From: Nate Lawson > > Kevin Oberman wrote: > > I have an old Dell desktop with a 1 GHz PIII CPU. > > > > After upgrade to V7 yesterday I no longer see any CPU usage information > > in top(1) or the CPU plots in gkrellm. (Yes, my kernel and world are in > > sync and I cleaned out /usr/obj/* and /usr/include/* when I upgraded my > > system.) I disabled ACPI and everything worked again. > > > > The ASL is pretty small. The output of acpidump -dt is only about 3100 > > lines. I have placed it along with a verbose dmesg and the config (PAK) at: > > http://home.comcast.net/~ykoberman/FreeBSD/pak.asl.bz2 > > http://home.comcast.net/~ykoberman/FreeBSD/PAK > > http://home.comcast.net/~ykoberman/FreeBSD/dmesg.boot > > > > Any idea what failed? I was running current on this system in the middle > > of last year and it worked then, so it was sometime between then and now. > > Only thing I can think of is that cpufreq is now enabled by default. > Try disabling it: > hint.cpufreq.0.disabled="1" No joy! I just rebooted with cpufreq disabled and it made no difference. I will try updating BIOS and see if that helps, but I don't think the time involved in hunting it down is justified. This system was scheduled for retirement last year and I hope to have a new dual core system before long. Thanks for the suggestion, though. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1204233643_15386P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFHxyWrkn3rs5h7N1ERApo0AJ9QKz1HjApUw4RKWPfMZPh++GElQgCgrgsJ ZAB4Iwk/f4t/djunblKAXRk= =RSF5 -----END PGP SIGNATURE----- --==_Exmh_1204233643_15386P-- From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 21:22:23 2008 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 102061065672 for ; Thu, 28 Feb 2008 21:22:23 +0000 (UTC) (envelope-from kayve@sfsu.edu) Received: from iron1.sfsu.edu (iron1.sfsu.edu [130.212.10.35]) by mx1.freebsd.org (Postfix) with ESMTP id DE5638FC2A for ; Thu, 28 Feb 2008 21:22:22 +0000 (UTC) (envelope-from kayve@sfsu.edu) X-onepass: IPPSC X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAq1xkeC1Apk/2dsb2JhbACuRw Received: from smtp01.sfsu.edu ([130.212.10.100]) by iron1.sfsu.edu with ESMTP; 28 Feb 2008 13:22:23 -0800 Received: from libra.sfsu.edu ([130.212.10.238]) by mail05a.sfsu.edu (Lotus Domino Release 7.0.3HF100) with ESMTP id 2008022813222088-145 ; Thu, 28 Feb 2008 13:22:20 -0800 Date: Thu, 28 Feb 2008 13:22:20 -0800 (PST) From: KAYVEN RIESE To: Sean Bruno In-Reply-To: <47C72483.1080709@miralink.com> Message-ID: References: <47C716EE.3040909@miralink.com> <47C72483.1080709@miralink.com> MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MAIL05a/SERVERS/SFSU(Release 7.0.3HF100 | December 5, 2007) at 02/28/2008 13:22:21, Serialize by Router on SMTP01/SERVERS/SFSU(Release 7.0.3HF312 | February 8, 2008) at 02/28/2008 13:22:21, Serialize complete at 02/28/2008 13:22:21 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI errors in dmesg 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, 28 Feb 2008 21:22:23 -0000 On Thu, 28 Feb 2008, Sean Bruno wrote: > KAYVEN RIESE wrote: >> >> On Thu, 28 Feb 2008, Sean Bruno wrote: >>> KAYVEN RIESE wrote: >>>> >>>> I have ACPI errors in my dmesg, and I don't know what to do about >>>> it. Do I need new hardware? If so, can I get more specific information? >>>> How do I fix this? >>>> >>>> Follows is the first part of dmesg with the errors: >>>> >>>> >>>> kv_bsd#dmesg >>>> Copyright (c) 1992-2007 The FreeBSD Project. >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>>> The Regents of the University of California. All rights reserved. >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>> FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 >>>> root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>> CPU: Intel(R) Pentium(R) M processor 1.73GHz (600.02-MHz 686-class CPU) >>>> Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 >>>> >>>> Features=0xafe9fbff >>>> Features2=0x180 >>>> AMD Features=0x100000 >>>> real memory = 1072955392 (1023 MB) >>>> avail memory = 1040961536 (992 MB) >>>> kbd1 at kbdmux0 >>>> ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >>>> RF5413) >>>> acpi0: on motherboard >>>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>>> ACPI-1304: *** Error: Method execution failed >>>> [\\_SB_.PCI0.SBRG.EC0_.ACS_] (Node 0xc4ba8440), AE_NOT_EXIST >>>> ACPI-1304: *** Error: Method execution failed [\\_SB_.AC__._INI] >>>> (Node 0xc4bac0a0), AE_NOT_EXIST >>>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>>> ACPI-1304: *** Error: Method execution failed >>>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> acpi0: Power Button (fixed) >>>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>>> ACPI-1304: *** Error: Method execution failed >>>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>>> ACPI-1304: *** Error: Method execution failed >>>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>>> ACPI-1304: *** Error: Method execution failed >>>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>>> ACPI-1304: *** Error: Method execution failed >>>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>>> ACPI-1304: *** Error: Method execution failed >>>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>>> ACPI-1304: *** Error: Method execution failed >>>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>>> ACPI-1304: *** Error: Method execution failed >>>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>>> (Node 0xc4baf420), AE_NOT_EXIST >>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>>> >>> Can you please post your motherboard model and BIOS revision? >> >> I'm not really sure how to do that, but here is a free photoserver >> where I have pictures of my BIOS: >> >> http://www.monkeyview.net/id/965/fsck/bios/index.vhtml >> >> (click on one of the more interesting of the 49 photos there for >> a better look) >> >> Here is a super album with more pictures: >> >> http://www.monkeyview.net/id/965/fsck/index.vhtml >> >> Will the rest of the dmesg output help? Here that is >> >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >> acpi_ec0: port 0x62,0x66 on acpi0 >> cpu0: on acpi0 >> acpi_throttle0: on cpu0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> agp0: mem 0xe0000000-0xefffffff at device >> 0.0 o >> n pci0 >> pcib1: at device 1.0 on pci0 >> pci1: on pcib1 >> pci1: at device 0.0 (no driver attached) >> uhci0: port 0xe800-0xe81f irq >> 11 at >> device 29.0 on pci0 >> uhci0: [GIANT-LOCKED] >> usb0: on uhci0 >> usb0: USB revision 1.0 >> uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub0: 2 ports with 2 removable, self powered >> uhci1: port 0xe880-0xe89f irq 5 >> at d >> evice 29.1 on pci0 >> uhci1: [GIANT-LOCKED] >> usb1: on uhci1 >> usb1: USB revision 1.0 >> uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub1: 2 ports with 2 removable, self powered >> uhci2: port 0xec00-0xec1f irq >> 10 at >> device 29.2 on pci0 >> uhci2: [GIANT-LOCKED] >> usb2: on uhci2 >> usb2: USB revision 1.0 >> uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub2: 2 ports with 2 removable, self powered >> ehci0: mem >> 0xffaffc00-0xffafffff i >> rq 10 at device 29.7 on pci0 >> ehci0: [GIANT-LOCKED] >> usb3: EHCI version 1.0 >> usb3: companion controllers, 2 ports each: usb0 usb1 usb2 >> usb3: on ehci0 >> usb3: USB revision 2.0 >> uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 >> uhub3: 6 ports with 6 removable, self powered >> pcib2: at device 30.0 on pci0 >> pci2: on pcib2 >> bge0: mem 0xff9f0000-0xff9fffff irq >> 4 at >> device 0.0 on pci2 >> miibus0: on bge0 >> brgphy0: on miibus0 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, >> 1000baseTX >> -FDX, auto >> bge0: Ethernet address: 00:11:d8:22:c9:91 >> cbb0: at device 1.0 on pci2 >> cardbus0: on cbb0 >> pccard0: <16-bit PCCard bus> on cbb0 >> cbb1: at device 1.1 on pci2 >> cardbus1: on cbb1 >> pccard1: <16-bit PCCard bus> on cbb1 >> fwohci0: mem 0xff9ef800-0xff9effff irq 10 at device 1.2 on >> pci2 >> fwohci0: OHCI version 1.0 (ROM=1) >> fwohci0: No. of Isochronous channels is 4. >> fwohci0: EUI64 00:e0:18:00:03:26:4c:e9 >> fwohci0: Phy 1394a available S400, 2 ports. >> fwohci0: Link S400, max_rec 2048 bytes. >> firewire0: on fwohci0 >> fwe0: on firewire0 >> if_fwe0: Fake Ethernet address: 02:e0:18:26:4c:e9 >> fwe0: Ethernet address: 02:e0:18:26:4c:e9 >> fwe0: if_start running deferred for Giant >> sbp0: on firewire0 >> fwohci0: Initiate bus reset >> fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode >> firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) >> firewire0: bus manager 0 (me) >> pci2: at device 2.0 (no driver attached) >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x37 >> 6,0xffa0-0xffaf at device 31.1 on pci0 >> ata0: on atapci0 >> ata1: on atapci0 >> pcm0: port 0xee00-0xeeff,0xe000-0xe03f mem >> 0xffaff800-0xf >> faff9ff,0xffaff400-0xffaff4ff irq 4 at device 31.5 on pci0 >> pcm0: >> pci0: at device 31.6 (no driver attached) >> acpi_lid0: on acpi0 >> acpi_button0: on acpi0 >> acpi_acad0: on acpi0 >> battery0: on acpi0 >> battery1: on acpi0 >> acpi_button1: on acpi0 >> acpi_tz0: on acpi0 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> psm0: irq 12 on atkbdc0 >> psm0: [GIANT-LOCKED] >> psm0: model Generic PS/2 mouse, device ID 0 >> sio0: configured irq 3 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0 port 0x2f8-0x2ff irq 3 drq 1 flags 0x10 on acpi0 >> sio0: type 16550A >> ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 >> on ac >> pi0 >> ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode >> ppc0: FIFO with 16/16/8 bytes threshold >> ppbus0: on ppc0 >> plip0: on ppbus0 >> lpt0: on ppbus0 >> lpt0: Interrupt-driven port >> ppi0: on ppbus0 >> pmtimer0 on isa0 >> orm0: at iomem 0xc0000-0xcffff on isa0 >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> ums0: Logitech USB Optical Mouse, rev 2.00/43.01, addr 2, iclass 3/1 >> ums0: 8 buttons and Z dir. >> Timecounter "TSC" frequency 600024447 Hz quality 800 >> Timecounters tick every 1.000 msec >> ad0: 114473MB at ata0-master UDMA100 >> acd0: DVDR at ata1-master UDMA33 >> Trying to mount root from ufs:/dev/ad0s2a >> bge0: link state changed to DOWN >> cpu0: Cx states changed >> cpu0: Cx states changed >> bge0: link state changed to UP >> pid 54590 (npviewer.bin), uid 1001: exited on signal 11 (core dumped) >> >> >>> >>> Sean >>> >>> >> >> *----------------------------------------------------------* >> Kayven Riese, BSCS, MS (Physiology and Biophysics) >> (415) 902 5513 cellular >> http://kayve.net >> Webmaster http://ChessYoga.org >> *----------------------------------------------------------* > Ok, your BIOS version is 0208 I think. Who made your computer? Maybe from > the make and model of the computer we can determine if there is a BIOS update > for it. I have pictures of the decals on the bottom. There are a total of 1143 pictures in this weblink: http://www.monkeyview.net/id/965/fsck/index.vhtml the little bracked numbers indicate how many pictures in the "SubAlbum" If you click the titles (e.g. my USB mousie) you get to the Subalbum. This subalbum has the picture of the decal on the bottom http://www.monkeyview.net/id/965/fsck/dmesg/index.vhtml clicking on a thumbnail gets a better view of the decal http://www.monkeyview.net/id/965/fsck/dmesg/PB12001901.vhtml I went to the store and told them to "upgrade the BIOS" but I guess I didn't know what to upgrade to. These errors have always been there, the BIOS upgrade didn't help. I built the computer from pieces a few years ago. This store "Central Computers" builds it for you. I bought a new HD and put it in myself more recently. > > Sean > *----------------------------------------------------------* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *----------------------------------------------------------* From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 21:35:58 2008 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 EF807106566B for ; Thu, 28 Feb 2008 21:35:58 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id BB23D8FC1D for ; Thu, 28 Feb 2008 21:35:58 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 12797 invoked from network); 28 Feb 2008 21:35:59 -0000 Received: from adsl-71-141-98-131.dsl.snfc21.pacbell.net (HELO ?192.168.1.77?) (nate-mail@71.141.98.131) by root.org with ESMTPA; 28 Feb 2008 21:35:59 -0000 Message-ID: <47C72939.4020704@root.org> Date: Thu, 28 Feb 2008 13:35:53 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: KAYVEN RIESE References: <47C716EE.3040909@miralink.com> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI errors in dmesg 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, 28 Feb 2008 21:35:59 -0000 KAYVEN RIESE wrote: > > On Thu, 28 Feb 2008, Sean Bruno wrote: >> KAYVEN RIESE wrote: >>> >>> I have ACPI errors in my dmesg, and I don't know what to do about >>> it. Do I need new hardware? If so, can I get more specific >>> information? >>> How do I fix this? >>> >>> Follows is the first part of dmesg with the errors: >>> >>> >>> kv_bsd#dmesg >>> Copyright (c) 1992-2007 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>> The Regents of the University of California. All rights >>> reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 >>> root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>> CPU: Intel(R) Pentium(R) M processor 1.73GHz (600.02-MHz 686-class CPU) >>> Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 >>> >>> Features=0xafe9fbff >>> >>> Features2=0x180 >>> AMD Features=0x100000 >>> real memory = 1072955392 (1023 MB) >>> avail memory = 1040961536 (992 MB) >>> kbd1 at kbdmux0 >>> ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >>> RF5413) >>> acpi0: on motherboard >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.ACS_] (Node 0xc4ba8440), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.AC__._INI] >>> (Node 0xc4bac0a0), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> acpi0: Power Button (fixed) >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler >>> ACPI-1304: *** Error: Method execution failed >>> [\\_SB_.PCI0.SBRG.EC0_.BATS] (Node 0xc4ba8420), AE_NOT_EXIST >>> ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> ACPI-0239: *** Error: Method execution failed [\\_SB_.BAT0._STA] >>> (Node 0xc4baf420), AE_NOT_EXIST >>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>> > > Will the rest of the dmesg output help? Here that is > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 This is the important part. Your EC just attached later. Now those messages are gone. Something is wrong with your ASL accessing the EC before it has been attached. If this causes functional problems later on, the solution is to try to make the EC attach earlier. Linux had to add that hack I think. It's a bit involved to do that though. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 22:17:22 2008 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 E7F4C1065677 for ; Thu, 28 Feb 2008 22:17:22 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.freebsd.org (Postfix) with ESMTP id 9AC868FC2B for ; Thu, 28 Feb 2008 22:17:22 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-250-179-2.dsl.wotnoh.ameritech.net [68.250.179.2]) (authenticated bits=0) by mail.united-ware.com (8.14.2/8.14.2) with ESMTP id m1SLmKLg048837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Feb 2008 16:48:21 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-acpi@freebsd.org Date: Thu, 28 Feb 2008 16:44:59 -0500 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1282092.B5Zy0IjyR3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802281645.00286.mistry.7@osu.edu> X-Virus-Scanned: ClamAV 0.91.2/6030/Thu Feb 28 14:36:36 2008 on mail.united-ware.com X-Virus-Status: Clean Subject: Fujitsu P8010: est: CPU supports Enhanced Speedstep, but is not recognized 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, 28 Feb 2008 22:17:23 -0000 --nextPart1282092.B5Zy0IjyR3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I got a new Fujitsu P8010 and est doesn't seem to attach to my dual=20 core processor since it doesn't recognize the CPU. My dmesg is=20 linked at the end of the email. Is there anything I can do to add=20 it? cpu0: on acpi0 ACPI: SSDT @ 0x0xcf6cac73/0x01F6 (v 1 FUJ FJNB1E3 0x01050000 FUJ =20 0x00000100) ACPI: SSDT @ 0x0xcf6cb173/0x05CD (v 1 FUJ FJNB1E3 0x01050000 FUJ =20 0x00000100) est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 619061906000619 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 ACPI: SSDT @ 0x0xcf6cb0bb/0x00B8 (v 1 FUJ FJNB1E3 0x01050000 FUJ =20 0x00000100) ACPI: SSDT @ 0x0xcf6cb740/0x0047 (v 1 FUJ FJNB1E3 0x01050000 FUJ =20 0x00000100) est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 619061906000619 device_attach: est1 attach returned 6 dmesg: http://am-productions.biz/docs/dmesg.boot =2D-=20 Anish Mistry --nextPart1282092.B5Zy0IjyR3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHxytcxqA5ziudZT0RAtkfAJwI2vF1dxjIN9gTx3ZX8VyzU2f2aACfRx8s o7smTvQRJFap7rHdEeOLgi8= =KAk9 -----END PGP SIGNATURE----- --nextPart1282092.B5Zy0IjyR3-- From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 23:33:09 2008 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 3170A1065670 for ; Thu, 28 Feb 2008 23:33:09 +0000 (UTC) (envelope-from jo.lindqvist@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id A87A18FC1C for ; Thu, 28 Feb 2008 23:33:08 +0000 (UTC) (envelope-from jo.lindqvist@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1730uge.37 for ; Thu, 28 Feb 2008 15:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=VFS5kobrtMKIPu94+f0Ekm2rpYvHS2v7EQDimCKnIIc=; b=va6l+Aqmzax9+21O4O1DHDvK42YohYCUXozoT2h2h0JtoMk2qpSIjBx1ORktRWkAse14vKHwa38bZoiWxxVSOsX6Di4BIQ4qRYJ0LXCWomWprQtqPyKWqiV0qpOI64JP3jxGiCyJITGIIQwz9FGKCx1avS1yFnw1ki1rZXctDqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=MdGnUNONY9gXuyK3dUB6h3i3YvO3CAkFz6K8AYftHHM8Ut1DNl341HFyRZIdhlagFOXyJfq/gzCQN8yr26XpD45WaQ+LUM+Hsjrr7hOvee5j4QeEn0ZZjvasUWsbiGnNEN4PeOyNjTwyDjTO+iVmdLwQJD2Te55La0zJ7hc96aU= Received: by 10.67.196.4 with SMTP id y4mr4367914ugp.39.1204240031077; Thu, 28 Feb 2008 15:07:11 -0800 (PST) Received: from ?192.168.11.11? ( [85.226.138.38]) by mx.google.com with ESMTPS id j1sm2157093ugf.74.2008.02.28.15.07.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Feb 2008 15:07:09 -0800 (PST) Message-ID: <47C73E8E.40706@gmail.com> Date: Fri, 29 Feb 2008 00:06:54 +0100 From: Jan-Olof Lindqvist User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Anish Mistry References: <200802281645.00286.mistry.7@osu.edu> In-Reply-To: <200802281645.00286.mistry.7@osu.edu> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Fujitsu P8010: est: CPU supports Enhanced Speedstep, but is not recognized 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, 28 Feb 2008 23:33:09 -0000 Anish Mistry wrote: > I got a new Fujitsu P8010 and est doesn't seem to attach to my dual > core processor since it doesn't recognize the CPU. My dmesg is > linked at the end of the email. Is there anything I can do to add > it? > > cpu0: on acpi0 > ACPI: SSDT @ 0x0xcf6cac73/0x01F6 (v 1 FUJ FJNB1E3 0x01050000 FUJ > 0x00000100) > ACPI: SSDT @ 0x0xcf6cb173/0x05CD (v 1 FUJ FJNB1E3 0x01050000 FUJ > 0x00000100) > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 619061906000619 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > cpu1: on acpi0 > ACPI: SSDT @ 0x0xcf6cb0bb/0x00B8 (v 1 FUJ FJNB1E3 0x01050000 FUJ > 0x00000100) > ACPI: SSDT @ 0x0xcf6cb740/0x0047 (v 1 FUJ FJNB1E3 0x01050000 FUJ > 0x00000100) > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 619061906000619 > device_attach: est1 attach returned 6 > > > dmesg: > http://am-productions.biz/docs/dmesg.boot I was about to say that est.c was not updated for 21 months so newer processors is likely not to be supported by Enhanced Speedstep but 3 hours ago there was a patch notified :) http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/cpufreq/est.c It doesn't look like it's going to help us though. I have the exact same problem with all my new systems. Two core 2 duo and one core 2 quad. They run way to hot without the correct speedstep setting. The big issue that I can see is that the frequency-voltage tables are missing in FreeBSD est.c, but they are for example easily available at: http://developer.intel.com/products/processor/core2duo/ Someone with the knowledge and time just needs to implement it. -- Jan-Olof Lindqvist http://www.jail.se From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 29 01:03:30 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CA82106566C; Fri, 29 Feb 2008 01:03:30 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DD1468FC18; Fri, 29 Feb 2008 01:03:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1T13Tgb024598; Fri, 29 Feb 2008 01:03:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1T13T9c024594; Fri, 29 Feb 2008 01:03:29 GMT (envelope-from linimon) Date: Fri, 29 Feb 2008 01:03:29 GMT Message-Id: <200802290103.m1T13T9c024594@freefall.freebsd.org> To: William.Anderle@Alice.it, linimon@FreeBSD.org, freebsd-acpi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/98171: [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop (probably on all 3020 / 5020 series) 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, 29 Feb 2008 01:03:30 -0000 Synopsis: [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop (probably on all 3020 / 5020 series) State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Fri Feb 29 00:58:39 UTC 2008 State-Changed-Why: This was committed by njl on Tue Feb 27 2007 but never MFCed to RELENG_6. However, with bugmeister hat on, I'm going to go ahead and close it because 1) it would be a fairly large MFC, 2) there are other changes in RELENG_7 that happened later, which have also not been MFCed; and 3) njl has unfortunately turned in his commit bit in the meantime. If anyone is having this problem, the fix is to upgrade to RELENG_7. http://www.freebsd.org/cgi/query-pr.cgi?pr=98171 From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 29 02:00:47 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 694631065678; Fri, 29 Feb 2008 02:00:47 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2B57A8FC13; Fri, 29 Feb 2008 02:00:47 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1T20lJu004473; Fri, 29 Feb 2008 02:00:47 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1T20kdD004469; Fri, 29 Feb 2008 02:00:46 GMT (envelope-from linimon) Date: Fri, 29 Feb 2008 02:00:46 GMT Message-Id: <200802290200.m1T20kdD004469@freefall.freebsd.org> To: takeharu1219@ybb.ne.jp, linimon@FreeBSD.org, freebsd-acpi@FreeBSD.org, jhb@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/112544: [acpi] [patch] Add High Precision Event Timer Driver for userland timer facility 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, 29 Feb 2008 02:00:47 -0000 Synopsis: [acpi] [patch] Add High Precision Event Timer Driver for userland timer facility State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Fri Feb 29 01:57:50 UTC 2008 State-Changed-Why: To jhb: there seems to have been a commit, then an MFC to RELENG_6 via 1.1.4.1 on Jan 23 2008. Is there some reason this one needs to remain open? Responsible-Changed-From-To: freebsd-acpi->jhb Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 29 01:57:50 UTC 2008 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=112544 From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 29 15:41:04 2008 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 372281065673 for ; Fri, 29 Feb 2008 15:41:04 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.freebsd.org (Postfix) with ESMTP id DC6628FC17 for ; Fri, 29 Feb 2008 15:41:03 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-250-179-2.dsl.wotnoh.ameritech.net [68.250.179.2]) (authenticated bits=0) by mail.united-ware.com (8.14.2/8.14.2) with ESMTP id m1TFn49s057250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 10:49:04 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Yousif Hassan Date: Fri, 29 Feb 2008 10:45:32 -0500 User-Agent: KMail/1.9.7 References: <200802281645.00286.mistry.7@osu.edu> <47C73E8E.40706@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4076808.qizr8nOpjZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802291045.39977.mistry.7@osu.edu> X-Virus-Scanned: ClamAV 0.91.2/6039/Thu Feb 28 22:31:42 2008 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-acpi@freebsd.org Subject: Re: Fujitsu P8010: est: CPU supports Enhanced Speedstep, but is not recognized 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, 29 Feb 2008 15:41:04 -0000 --nextPart4076808.qizr8nOpjZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 29 February 2008, Yousif Hassan wrote: > > Anish Mistry wrote: > >> I got a new Fujitsu P8010 and est doesn't seem to attach to my > >> dual core processor since it doesn't recognize the CPU. My > >> dmesg is linked at the end of the email. Is there anything I > >> can do to add it? > >> > >> cpu0: on acpi0 > >> ACPI: SSDT @ 0x0xcf6cac73/0x01F6 (v 1 FUJ FJNB1E3=20 > >> 0x01050000 FUJ 0x00000100) > >> ACPI: SSDT @ 0x0xcf6cb173/0x05CD (v 1 FUJ FJNB1E3=20 > >> 0x01050000 FUJ 0x00000100) > >> est0: on cpu0 > >> est: CPU supports Enhanced Speedstep, but is not recognized. > >> est: cpu_vendor GenuineIntel, msr 619061906000619 > >> device_attach: est0 attach returned 6 > >> p4tcc0: on cpu0 > >> cpu1: on acpi0 > >> ACPI: SSDT @ 0x0xcf6cb0bb/0x00B8 (v 1 FUJ FJNB1E3=20 > >> 0x01050000 FUJ 0x00000100) > >> ACPI: SSDT @ 0x0xcf6cb740/0x0047 (v 1 FUJ FJNB1E3=20 > >> 0x01050000 FUJ 0x00000100) > >> est1: on cpu1 > >> est: CPU supports Enhanced Speedstep, but is not recognized. > >> est: cpu_vendor GenuineIntel, msr 619061906000619 > >> device_attach: est1 attach returned 6 > >> > >> > >> dmesg: > >> http://am-productions.biz/docs/dmesg.boot > > > > I was about to say that est.c was not updated for 21 months so > > newer processors is likely not to be supported by Enhanced > > Speedstep but 3 hours ago there was a patch notified :) > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/cpufreq/est.c > > > > It doesn't look like it's going to help us though. I have the > > exact same problem with all my new systems. Two core 2 duo and > > one core 2 quad. They run way to hot without the correct > > speedstep setting. > > > > The big issue that I can see is that the frequency-voltage tables > > are missing in FreeBSD est.c, but they are for example easily > > available at: > > http://developer.intel.com/products/processor/core2duo/ Someone > > with the knowledge and time just needs to implement it. > > Anish, are you running amd64? This seems to be a recurring theme > with amd64, based on some research I did and based on my anecdotal > evidence. Yes, I'm running amd64. > I see this problem on my HP dv9700t which features a Core 2 Duo > (T7500) if it boots an amd64 kernel. In this case, the p4tcc > driver attaches instead. Unfortunately, this driver only offers > relative frequency control - good but not great. My processor is an SL7100. > When I boot the same machine with i386 kernel, est attaches fine > and frequency control is far superior. I have tested it out in > numerous ways and it keeps the temperature nice and cool and scales > up and down as needed (if powerd is adaptive or if passive cooling > is on). > > Perhaps someone with more knowledge can confirm that there's > something fishy with amd64. Since it works in FreeBSD/i386, the > fix is probably simpler than not. > > Yousif =2D-=20 Anish Mistry --nextPart4076808.qizr8nOpjZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHyCicxqA5ziudZT0RAvBWAJ9SC5v5DQyvEWOHO6swXlf6apBs2QCfWsve z9LEkaRSyQMV/Yz20HzAX84= =q9jU -----END PGP SIGNATURE----- --nextPart4076808.qizr8nOpjZ-- From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 29 15:49:53 2008 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 A264C1065672 for ; Fri, 29 Feb 2008 15:49:53 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: from coruscant.far-far-away.us (coruscant.far-far-away.us [70.91.196.65]) by mx1.freebsd.org (Postfix) with SMTP id 231E08FC30 for ; Fri, 29 Feb 2008 15:49:53 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: (qmail 38896 invoked from network); 29 Feb 2008 10:43:41 -0500 Received: from pknat1.passkey.com (HELO alderaan) (68.162.198.134) by coruscant.far-far-away.us with SMTP; 29 Feb 2008 10:43:41 -0500 Message-ID: <863014ECF11048B78C23D1D31DCAFF40@alderaan> From: "Yousif Hassan" To: "Anish Mistry" References: <200802281645.00286.mistry.7@osu.edu> <47C73E8E.40706@gmail.com> <200802291045.39977.mistry.7@osu.edu> In-Reply-To: <200802291045.39977.mistry.7@osu.edu> Date: Fri, 29 Feb 2008 10:50:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: freebsd-acpi@freebsd.org Subject: Re: Fujitsu P8010: est: CPU supports Enhanced Speedstep, but is not recognized 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, 29 Feb 2008 15:49:53 -0000 On Friday 29 February 2008, Anish Mistry wrote: > On Friday 29 February 2008, Yousif Hassan wrote: > > Anish Mistry wrote: > >> I got a new Fujitsu P8010 and est doesn't seem to attach to my > >> dual core processor since it doesn't recognize the CPU. My > >> dmesg is linked at the end of the email. Is there anything I > >> can do to add it? >>Anish, are you running amd64? This seems to be a recurring theme >>with amd64, based on some research I did and based on my anecdotal >> evidence. >Yes, I'm running amd64. If you're willing, try an i386 kernel and see if the est driver attaches. If using i386 isn't a non-starter for you, that's a workaround. That said, I still hope someone who knows this stuff can comment on this definitively. It seems odd that i386 attaches est fine, but amd64 doesn't. --Yousif From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 29 15:50:48 2008 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 B1037106567C for ; Fri, 29 Feb 2008 15:50:48 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: from coruscant.far-far-away.us (coruscant.far-far-away.us [70.91.196.65]) by mx1.freebsd.org (Postfix) with SMTP id 45E808FC23 for ; Fri, 29 Feb 2008 15:50:48 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: (qmail 38726 invoked from network); 29 Feb 2008 10:17:54 -0500 Received: from pknat1.passkey.com (HELO alderaan) (68.162.198.134) by coruscant.far-far-away.us with SMTP; 29 Feb 2008 10:17:54 -0500 Message-ID: From: "Yousif Hassan" To: "Jan-Olof Lindqvist" , "Anish Mistry" References: <200802281645.00286.mistry.7@osu.edu> <47C73E8E.40706@gmail.com> In-Reply-To: <47C73E8E.40706@gmail.com> Date: Fri, 29 Feb 2008 10:25:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: freebsd-acpi@freebsd.org Subject: Re: Fujitsu P8010: est: CPU supports Enhanced Speedstep, but is not recognized 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, 29 Feb 2008 15:50:48 -0000 > Anish Mistry wrote: >> I got a new Fujitsu P8010 and est doesn't seem to attach to my dual >> core processor since it doesn't recognize the CPU. My dmesg is >> linked at the end of the email. Is there anything I can do to add >> it? >> >> cpu0: on acpi0 >> ACPI: SSDT @ 0x0xcf6cac73/0x01F6 (v 1 FUJ FJNB1E3 0x01050000 FUJ >> 0x00000100) >> ACPI: SSDT @ 0x0xcf6cb173/0x05CD (v 1 FUJ FJNB1E3 0x01050000 FUJ >> 0x00000100) >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 619061906000619 >> device_attach: est0 attach returned 6 >> p4tcc0: on cpu0 >> cpu1: on acpi0 >> ACPI: SSDT @ 0x0xcf6cb0bb/0x00B8 (v 1 FUJ FJNB1E3 0x01050000 FUJ >> 0x00000100) >> ACPI: SSDT @ 0x0xcf6cb740/0x0047 (v 1 FUJ FJNB1E3 0x01050000 FUJ >> 0x00000100) >> est1: on cpu1 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 619061906000619 >> device_attach: est1 attach returned 6 >> >> >> dmesg: >> http://am-productions.biz/docs/dmesg.boot > > I was about to say that est.c was not updated for 21 months so newer > processors is likely not to be supported by Enhanced Speedstep but 3 > hours ago there was a patch notified :) > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/cpufreq/est.c > > It doesn't look like it's going to help us though. I have the exact same > problem with all my new systems. Two core 2 duo and one core 2 quad. > They run way to hot without the correct speedstep setting. > > The big issue that I can see is that the frequency-voltage tables are > missing in FreeBSD est.c, but they are for example easily available at: > http://developer.intel.com/products/processor/core2duo/ Someone with the > knowledge and time just needs to implement it. Anish, are you running amd64? This seems to be a recurring theme with amd64, based on some research I did and based on my anecdotal evidence. I see this problem on my HP dv9700t which features a Core 2 Duo (T7500) if it boots an amd64 kernel. In this case, the p4tcc driver attaches instead. Unfortunately, this driver only offers relative frequency control - good but not great. When I boot the same machine with i386 kernel, est attaches fine and frequency control is far superior. I have tested it out in numerous ways and it keeps the temperature nice and cool and scales up and down as needed (if powerd is adaptive or if passive cooling is on). Perhaps someone with more knowledge can confirm that there's something fishy with amd64. Since it works in FreeBSD/i386, the fix is probably simpler than not. Yousif From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 29 17:50:45 2008 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 C9A9B106566C for ; Fri, 29 Feb 2008 17:50:45 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.freebsd.org (Postfix) with ESMTP id 6A39D8FC18 for ; Fri, 29 Feb 2008 17:50:45 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-250-179-2.dsl.wotnoh.ameritech.net [68.250.179.2]) (authenticated bits=0) by mail.united-ware.com (8.14.2/8.14.2) with ESMTP id m1THwpnP061623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 12:58:52 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Yousif Hassan Date: Fri, 29 Feb 2008 12:55:27 -0500 User-Agent: KMail/1.9.7 References: <200802281645.00286.mistry.7@osu.edu> <200802291045.39977.mistry.7@osu.edu> <863014ECF11048B78C23D1D31DCAFF40@alderaan> In-Reply-To: <863014ECF11048B78C23D1D31DCAFF40@alderaan> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3196446.yzcnMT3leC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802291255.28224.mistry.7@osu.edu> X-Virus-Scanned: ClamAV 0.91.2/6039/Thu Feb 28 22:31:42 2008 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-acpi@freebsd.org Subject: Re: Fujitsu P8010: est: CPU supports Enhanced Speedstep, but is not recognized (only amd64) 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, 29 Feb 2008 17:50:45 -0000 --nextPart3196446.yzcnMT3leC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 29 February 2008, Yousif Hassan wrote: > On Friday 29 February 2008, Anish Mistry wrote: > > On Friday 29 February 2008, Yousif Hassan wrote: > > > Anish Mistry wrote: > > >> I got a new Fujitsu P8010 and est doesn't seem to attach to my > > >> dual core processor since it doesn't recognize the CPU. My > > >> dmesg is linked at the end of the email. Is there anything I > > >> can do to add it? > > > > >>Anish, are you running amd64? This seems to be a recurring theme > >>with amd64, based on some research I did and based on my > >> anecdotal evidence. > > > >Yes, I'm running amd64. > > If you're willing, try an i386 kernel and see if the est driver > attaches. If using i386 isn't a non-starter for you, that's a > workaround. > > That said, I still hope someone who knows this stuff can comment on > this definitively. It seems odd that i386 attaches est fine, but > amd64 doesn't. Alright, I booted the i386 install CD and est attaches est0, est1,=20 p4tcc0, and p4tcc1. If a developer needs some debug information to=20 get this fixed let me know. I'm running with 4GB or RAM so I'd=20 rather stick with amd64. =2D-=20 Anish Mistry --nextPart3196446.yzcnMT3leC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHyEcQxqA5ziudZT0RAk3rAKDH5BdGMpm0ZDMnNZ6pwcuH8OTTcwCglU7Z KbwGvk6w9y2dM1y0Ux9IBog= =aMqt -----END PGP SIGNATURE----- --nextPart3196446.yzcnMT3leC-- From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 29 18:06:39 2008 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 1C9E71065673 for ; Fri, 29 Feb 2008 18:06:39 +0000 (UTC) (envelope-from jo.lindqvist@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 9C2158FC26 for ; Fri, 29 Feb 2008 18:06:38 +0000 (UTC) (envelope-from jo.lindqvist@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so454026uge.37 for ; Fri, 29 Feb 2008 10:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=dwuP1KgedxlqKa5/Vyg6/ekIoN5Q8ymX/AidpIINeuw=; b=pyuu9ngVqCu2s4H3HEYfFEgdxSvGG/gaQ0VTycwddRg2CvRyoWwDGZQ4xv73bqFIVDiZ70taJHzZ4wyE5Fy56wwJFv5/nbskZ50nJDcciz5tjDK4E/NysHOfdj9Cpr9Bt72IS8tQygEOF60TTSum74qat3gviF2Z/QhQpXQHfW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=EEl3XH/KzP+J8k0kgaZJx4xdSjHqKUUiRfsg9o/IGpumQPVNVxxJ2aiHNQvPaEE95hNx67QiZGAcxPWoDiFY8Tam/T+K+U6xLEKbaDk38pUp3Sg9OU0KCLLI0kjJRjoFLF/NxdvVqLzUOFGQf+/6qeg81uTDJPnvq4p2jb55XLw= Received: by 10.67.106.13 with SMTP id i13mr1881886ugm.49.1204308396700; Fri, 29 Feb 2008 10:06:36 -0800 (PST) Received: from ?192.168.11.11? ( [85.226.138.38]) by mx.google.com with ESMTPS id g30sm1842759ugd.54.2008.02.29.10.06.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Feb 2008 10:06:35 -0800 (PST) Message-ID: <47C849A8.10809@gmail.com> Date: Fri, 29 Feb 2008 19:06:32 +0100 From: Jan-Olof Lindqvist User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Yousif Hassan References: <200802281645.00286.mistry.7@osu.edu> <47C73E8E.40706@gmail.com> <200802291045.39977.mistry.7@osu.edu> <863014ECF11048B78C23D1D31DCAFF40@alderaan> In-Reply-To: <863014ECF11048B78C23D1D31DCAFF40@alderaan> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Fujitsu P8010: est: CPU supports Enhanced Speedstep, but is not recognized 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, 29 Feb 2008 18:06:39 -0000 Yousif Hassan wrote: > On Friday 29 February 2008, Anish Mistry wrote: >> On Friday 29 February 2008, Yousif Hassan wrote: >> > Anish Mistry wrote: >> >> I got a new Fujitsu P8010 and est doesn't seem to attach to my >> >> dual core processor since it doesn't recognize the CPU. My >> >> dmesg is linked at the end of the email. Is there anything I >> >> can do to add it? > > > >>> Anish, are you running amd64? This seems to be a recurring theme >>> with amd64, based on some research I did and based on my anecdotal >>> evidence. >> Yes, I'm running amd64. > > If you're willing, try an i386 kernel and see if the est driver > attaches. If using i386 isn't a non-starter for you, that's a workaround. > > That said, I still hope someone who knows this stuff can comment on this > definitively. It seems odd that i386 attaches est fine, but amd64 doesn't. > > --Yousif > Even if it does attach the est-driver, I don't think it receives the correct voltage to the processor. For example on my laptop I have been running FreeBSD i386 and now amd64 with the Core 2 duo T7700, the fan runs constantly and it feels hot where the processor is located. This is not the case when running for ex Linux. Maybe we should PR this? -- Jan-Olof Lindqvist http://www.jail.se From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 29 20:26:09 2008 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 9B6F21065673; Fri, 29 Feb 2008 20:26:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id E513B8FC1B; Fri, 29 Feb 2008 20:26:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 233866224-1834499 for multiple; Fri, 29 Feb 2008 15:24:14 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m1TKQ05v062199; Fri, 29 Feb 2008 15:26:01 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: linimon@freebsd.org Date: Fri, 29 Feb 2008 14:05:44 -0500 User-Agent: KMail/1.9.7 References: <200802290200.m1T20kdD004469@freefall.freebsd.org> In-Reply-To: <200802290200.m1T20kdD004469@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802291405.44386.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 29 Feb 2008 15:26:02 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/6047/Fri Feb 29 13:51:13 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: kern/112544: [acpi] [patch] Add High Precision Event Timer Driver for userland timer facility 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, 29 Feb 2008 20:26:09 -0000 On Thursday 28 February 2008 09:00:46 pm linimon@freebsd.org wrote: > Synopsis: [acpi] [patch] Add High Precision Event Timer Driver for userland timer facility > > State-Changed-From-To: open->feedback > State-Changed-By: linimon > State-Changed-When: Fri Feb 29 01:57:50 UTC 2008 > State-Changed-Why: > To jhb: there seems to have been a commit, then an MFC to RELENG_6 via > 1.1.4.1 on Jan 23 2008. Is there some reason this one needs to remain > open? The HPET contains multiple bits. One is a general count down timer that we use for timekeeping. In addition it contains a variable number of comparator registers each of which can be used to generate interrupts at varying frequencies (or one-shot interrupts, etc.). The current in-kernel HPET support only handles the count down timer. We do not have any support for the comparators. The code in the PR does include support for the comparators. However, it's aim is to export them for use by userland drivers. FreeBSD will probably end up using the HPET comparators to back deadline-style clock interrupts in place of the RTC or lapic timer at some point in which case certain pieces of this code may be useful. The commit I made just extracted a few of the changes in the original patch, it did not contain all of the changes in the patch. It is probably best to mark this as suspended and leave it as freebsd-acpi@ for now as I'm not currently planning on doing the deadline clock stuff. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Sat Mar 1 01:42:14 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 901511065671; Sat, 1 Mar 2008 01:42:14 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 64F7E8FC1E; Sat, 1 Mar 2008 01:42:14 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m211gEdd011086; Sat, 1 Mar 2008 01:42:14 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m211gDjB011082; Sat, 1 Mar 2008 01:42:13 GMT (envelope-from linimon) Date: Sat, 1 Mar 2008 01:42:13 GMT Message-Id: <200803010142.m211gDjB011082@freefall.freebsd.org> To: takeharu1219@ybb.ne.jp, linimon@FreeBSD.org, jhb@FreeBSD.org, freebsd-acpi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/112544: [acpi] [patch] Add High Precision Event Timer Driver for userland timer facility 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, 01 Mar 2008 01:42:14 -0000 Synopsis: [acpi] [patch] Add High Precision Event Timer Driver for userland timer facility State-Changed-From-To: feedback->suspended State-Changed-By: linimon State-Changed-When: Sat Mar 1 01:41:52 UTC 2008 State-Changed-Why: See note from jhb in Audit-Trail. Responsible-Changed-From-To: jhb->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 1 01:41:52 UTC 2008 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=112544 From owner-freebsd-acpi@FreeBSD.ORG Sat Mar 1 01:50:03 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53546106566B for ; Sat, 1 Mar 2008 01:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 417C58FC22 for ; Sat, 1 Mar 2008 01:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m211o2Xr011914 for ; Sat, 1 Mar 2008 01:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m211o2p2011913; Sat, 1 Mar 2008 01:50:02 GMT (envelope-from gnats) Date: Sat, 1 Mar 2008 01:50:02 GMT Message-Id: <200803010150.m211o2p2011913@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: linimon@lonesome.com (Mark Linimon) Cc: Subject: Re: kern/112544: [acpi] [patch] Add High Precision Event Timer Driver for userland timer facility X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Linimon List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 01:50:03 -0000 The following reply was made to PR kern/112544; it has been noted by GNATS. From: linimon@lonesome.com (Mark Linimon) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/112544: [acpi] [patch] Add High Precision Event Timer Driver for userland timer facility Date: Fri, 29 Feb 2008 19:41:46 -0600 ----- Forwarded message from John Baldwin ----- The HPET contains multiple bits. One is a general count down timer that we use for timekeeping. In addition it contains a variable number of comparator registers each of which can be used to generate interrupts at varying frequencies (or one-shot interrupts, etc.). The current in-kernel HPET support only handles the count down timer. We do not have any support for the comparators. The code in the PR does include support for the comparators. However, it's aim is to export them for use by userland drivers. FreeBSD will probably end up using the HPET comparators to back deadline-style clock interrupts in place of the RTC or lapic timer at some point in which case certain pieces of this code may be useful. The commit I made just extracted a few of the changes in the original patch, it did not contain all of the changes in the patch. It is probably best to mark this as suspended and leave it as freebsd-acpi@ for now as I'm not currently planning on doing the deadline clock stuff. -- John Baldwin ----- End forwarded message ----- From owner-freebsd-acpi@FreeBSD.ORG Sat Mar 1 08:50:15 2008 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 C7CA31065673; Sat, 1 Mar 2008 08:50:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4CCCD8FC13; Sat, 1 Mar 2008 08:50:14 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 7475A744013; Sat, 1 Mar 2008 10:50:12 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id IGj4xrRe+dry; Sat, 1 Mar 2008 10:50:12 +0200 (EET) Received: from [91.193.172.111] (unknown [91.193.172.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 58E2C74400D; Sat, 1 Mar 2008 10:50:11 +0200 (EET) Message-ID: <47C918B7.9040504@icyb.net.ua> Date: Sat, 01 Mar 2008 10:49:59 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: John Baldwin References: <47B96989.6070008@icyb.net.ua> <200802271126.30132.jhb@freebsd.org> <47C5E0A6.5030102@icyb.net.ua> <200802280856.31548.jhb@freebsd.org> In-Reply-To: <200802280856.31548.jhb@freebsd.org> Content-Type: multipart/mixed; boundary="------------000002010403000307090000" Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 01 Mar 2008 08:50:16 -0000 This is a multi-part message in MIME format. --------------000002010403000307090000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 28/02/2008 15:56 John Baldwin said the following: > On Wednesday 27 February 2008 05:13:58 pm Andriy Gapon wrote: >> on 27/02/2008 18:26 John Baldwin said the following: >>> On Wednesday 27 February 2008 02:54:38 am Andriy Gapon wrote: >> [snip] >> John, >> >> thank you for this detailed reply! >> I looked through the code and I think that ichss is the only device that >> explicitly requires cpu and pci buses to be "configured". acpi_throttle >> is another one that implicitly requires that. >> My personal preference is to probe/attach pci first and then go with >> cpu. This is mostly because pci can provide a lot of useful information >> and resources to various devices. On the other hand, cpu mostly exists >> so that others could attach to it (it does provide a little bit, but >> it's a very little bit). So, in my opinion, it is more likely that a >> child of cpu would need something from pci than vice versa. >> >> If we agree on this order and implement it, then I agree with you that >> it would be quite easy to modify ichss to be a "normal" child of cpu and >> use pci_find_device to find a proper pci device. And the rest of the >> code that uses pci_read_config, bus_set_resource and >> bus_alloc_resource_any would remain practically the same. >> I'd even say that this would be a trivial change. >> And I'd even say that this would be a change in right direction, because >> ichss would lose most of its 'specialness'. > > Actually, we can make ichss rather simple w/o changing it much by having it > just set a global variable in its PCI probe routine and checking that global > when attaching to the CPU. > > One other thing that concerns me is that cpufreq drivers want to know about > each other (e.g. smist checks for ichss0, etc.). I'd rather that if we have > multiple drivers controlling the same back-end hardware (via difference > interfaces) they all use the same driver name (e.g. speedstep0) and use probe > priority to decide which driver wins if both ichss0 and smist0 can handle a > CPU for example. > > Here is a patch to make CPUs come after PCI and an attempt to fix ICH. Note > that if we made ichss_identify() manually look for the PCI device by bsf > instead of using a probe routine to find it we could remove the pci "driver" > completely and make it work on kldload. It also fixes a bug that the attempt > to enable SS via a PCI config register write could never work as it passed a > cpu0 device_t to pci_read_config/pci_write_config in ichss_probe() > previously. I moved this to attach() (where it belongs) and used the right > device_t so this should work now. I have no hardware to test it on though. > Here is a patch that implements find by bsf idea in ichss that we also discussed. I don't own the actual hardware but I "tested" the patch by temporarily changing some ids and adding printfs instead of some actions. Another little difference that I've added (just in case) a protection against double-adding. I also tested acpi part of your patch - works great! Here's one strange thing - in your patch you accidentally have parameters of device_identify switched, I initially inherited that bug too. I got no error/warning from compiler whatsoever. It wasn't until I saw that device_get_unit(parent) returned garbage that I my untrained eye noticed the mistake. -- Andriy Gapon --------------000002010403000307090000 Content-Type: text/x-patch; name="ichss.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ichss.patch" --- ichss.c.orig 2006-05-16 17:36:24.000000000 +0300 +++ ichss.c 2008-03-01 01:37:53.000000000 +0200 @@ -91,7 +91,7 @@ (bus_space_write_1(rman_get_bustag((reg)), \ rman_get_bushandle((reg)), 0, (val))) -static int ichss_pci_probe(device_t dev); +static void ichss_identify(driver_t *driver, device_t parent); static int ichss_probe(device_t dev); static int ichss_attach(device_t dev); static int ichss_detach(device_t dev); @@ -103,6 +103,7 @@ static device_method_t ichss_methods[] = { /* Device interface */ + DEVMETHOD(device_identify, ichss_identify), DEVMETHOD(device_probe, ichss_probe), DEVMETHOD(device_attach, ichss_attach), DEVMETHOD(device_detach, ichss_detach), @@ -120,15 +121,7 @@ static devclass_t ichss_devclass; DRIVER_MODULE(ichss, cpu, ichss_driver, ichss_devclass, 0, 0); -static device_method_t ichss_pci_methods[] = { - DEVMETHOD(device_probe, ichss_pci_probe), - {0, 0} -}; -static driver_t ichss_pci_driver = { - "ichss_pci", ichss_pci_methods, 0 -}; -static devclass_t ichss_pci_devclass; -DRIVER_MODULE(ichss_pci, pci, ichss_pci_driver, ichss_pci_devclass, 0, 0); +static device_t ich_device; #if 0 #define DPRINT(x...) printf(x) @@ -136,70 +129,66 @@ #define DPRINT(x...) #endif -/* - * We detect the chipset by looking for its LPC bus ID during the PCI - * scan and reading its config registers during the probe. However, - * we add the ichss child under the cpu device since even though the - * chipset provides the control, it really affects the cpu only. - * - * XXX This approach does not work if the module is loaded after boot. - */ -static int -ichss_pci_probe(device_t dev) +static void +ichss_identify(driver_t *driver, device_t parent) { - device_t child, parent; + device_t child; uint32_t pmbase; + if (resource_disabled("ichss", 0)) + return; + /* - * TODO: add a quirk to disable if we see the 82815_MC along - * with the 82801BA and revision < 5. + * It appears that ICH SpeedStep only requires a single CPU to + * set the value (since the chipset is shared by all CPUs.) + * Thus, we only add a child to cpu 0. */ - if (pci_get_vendor(dev) != PCI_VENDOR_INTEL || - (pci_get_device(dev) != PCI_DEV_82801BA && - pci_get_device(dev) != PCI_DEV_82801CA && - pci_get_device(dev) != PCI_DEV_82801DB)) - return (ENXIO); + if (device_get_unit(parent) != 0) + return; - /* Only one CPU is supported for this hardware. */ - if (devclass_get_device(ichss_devclass, 0)) - return (ENXIO); + /* Avoid duplicates. */ + if (device_find_child(parent, "ichss", -1)) + return; /* - * Add a child under the CPU parent. It appears that ICH SpeedStep - * only requires a single CPU to set the value (since the chipset - * is shared by all CPUs.) Thus, we only add a child to cpu 0. + * ICH2/3/4-M I/O Controller Hub is at bus 0, slot 1F, function 0. + * E.g. see Section 6.1 "PCI Devices and Functions" and table 6.1 of + * Intel(r) 82801BA I/O Controller Hub 2 (ICH2) and Intel(r) 82801BAM + * I/O Controller Hub 2 Mobile (ICH2-M). */ - parent = devclass_get_device(devclass_find("cpu"), 0); - KASSERT(parent != NULL, ("cpu parent is NULL")); - child = BUS_ADD_CHILD(parent, 0, "ichss", 0); - if (child == NULL) { - device_printf(parent, "add SpeedStep child failed\n"); - return (ENXIO); - } + ich_device = pci_find_bsf(0, 0x1f, 0); + if (ich_device == NULL || + pci_get_vendor(ich_device) != PCI_VENDOR_INTEL || + (pci_get_device(ich_device) != PCI_DEV_82801BA && + pci_get_device(ich_device) != PCI_DEV_82801CA && + pci_get_device(ich_device) != PCI_DEV_82801DB)) + return; /* Find the PMBASE register from our PCI config header. */ - pmbase = pci_read_config(dev, ICHSS_PMBASE_OFFSET, sizeof(pmbase)); + pmbase = pci_read_config(ich_device, ICHSS_PMBASE_OFFSET, + sizeof(pmbase)); if ((pmbase & ICHSS_IO_REG) == 0) { printf("ichss: invalid PMBASE memory type\n"); - return (ENXIO); + return; } pmbase &= ICHSS_PMBASE_MASK; if (pmbase == 0) { printf("ichss: invalid zero PMBASE address\n"); - return (ENXIO); + return; } DPRINT("ichss: PMBASE is %#x\n", pmbase); + child = BUS_ADD_CHILD(parent, 0, "ichss", 0); + if (child == NULL) { + device_printf(parent, "add SpeedStep child failed\n"); + return; + } + /* Add the bus master arbitration and control registers. */ bus_set_resource(child, SYS_RES_IOPORT, 0, pmbase + ICHSS_BM_OFFSET, 1); bus_set_resource(child, SYS_RES_IOPORT, 1, pmbase + ICHSS_CTRL_OFFSET, 1); - - /* Attach the new CPU child now. */ - device_probe_and_attach(child); - - return (ENXIO); } static int @@ -207,10 +196,6 @@ { device_t est_dev, perf_dev; int error, type; - uint16_t ss_en; - - if (resource_disabled("ichss", 0)) - return (ENXIO); /* * If the ACPI perf driver has attached and is not just offering @@ -227,14 +212,6 @@ if (est_dev && device_is_attached(est_dev)) return (ENXIO); - /* Activate SpeedStep control if not already enabled. */ - ss_en = pci_read_config(dev, ICHSS_PMCFG_OFFSET, sizeof(ss_en)); - if ((ss_en & ICHSS_ENABLE) == 0) { - printf("ichss: enabling SpeedStep support\n"); - pci_write_config(dev, ICHSS_PMCFG_OFFSET, - ss_en | ICHSS_ENABLE, sizeof(ss_en)); - } - device_set_desc(dev, "SpeedStep ICH"); return (-1000); } @@ -243,6 +220,7 @@ ichss_attach(device_t dev) { struct ichss_softc *sc; + uint16_t ss_en; sc = device_get_softc(dev); sc->dev = dev; @@ -264,6 +242,14 @@ return (ENXIO); } + /* Activate SpeedStep control if not already enabled. */ + ss_en = pci_read_config(ich_device, ICHSS_PMCFG_OFFSET, sizeof(ss_en)); + if ((ss_en & ICHSS_ENABLE) == 0) { + device_printf(dev, "enabling SpeedStep support\n"); + pci_write_config(ich_device, ICHSS_PMCFG_OFFSET, + ss_en | ICHSS_ENABLE, sizeof(ss_en)); + } + /* Setup some defaults for our exported settings. */ sc->sets[0].freq = CPUFREQ_VAL_UNKNOWN; sc->sets[0].volts = CPUFREQ_VAL_UNKNOWN; --------------000002010403000307090000-- From owner-freebsd-acpi@FreeBSD.ORG Sat Mar 1 08:54:34 2008 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 15586106566C; Sat, 1 Mar 2008 08:54:34 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id B15CB8FC1D; Sat, 1 Mar 2008 08:54:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id C52D0744014; Sat, 1 Mar 2008 10:54:32 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ZjAM6c7YS2vd; Sat, 1 Mar 2008 10:54:32 +0200 (EET) Received: from [91.193.172.111] (unknown [91.193.172.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 1EAF1744013; Sat, 1 Mar 2008 10:54:31 +0200 (EET) Message-ID: <47C919C4.2050103@icyb.net.ua> Date: Sat, 01 Mar 2008 10:54:28 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: John Baldwin References: <47B96989.6070008@icyb.net.ua> <200802271126.30132.jhb@freebsd.org> <47C5E0A6.5030102@icyb.net.ua> <200802280856.31548.jhb@freebsd.org> <47C918B7.9040504@icyb.net.ua> In-Reply-To: <47C918B7.9040504@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 01 Mar 2008 08:54:34 -0000 on 01/03/2008 10:49 Andriy Gapon said the following: > Here is a patch that implements find by bsf idea in ichss that we also > discussed. > I don't own the actual hardware but I "tested" the patch by temporarily > changing some ids and adding printfs instead of some actions. Seems that I lost the following comment by accident. * TODO: add a quirk to disable if we see the 82815_MC along * with the 82801BA and revision < 5. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sat Mar 1 17:24:46 2008 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 E77CA1065672 for ; Sat, 1 Mar 2008 17:24:46 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6D98FC12 for ; Sat, 1 Mar 2008 17:24:45 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: by fg-out-1718.google.com with SMTP id 16so3580336fgg.35 for ; Sat, 01 Mar 2008 09:24:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; bh=1Y5obcSTnwVYl1ypYcpflTpGWncR9MpUzRnBzWKa1jk=; b=PLUPLUNf/aVptLMGGQPIl2yzvEWeYIL+xNTmIvoID5sU7yMsEEonlUis6/bbApn41kJAv3JV34kNJoGY1knBGyKyAG3oXLRAjZPWo18kd8GJGQKrMWjfiszExE5HRc4IkWuv/xQ/z7v+H9NvmJw5dR5PcHDjHsXj4hHScmvu6U4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=n3qOX9DS0g3tgJ46U5OukkutIFAioicunuadNfQoL9tGzx/0II+H28FrWMYvURR4OulKnxHXyd2JaW0pVB9HDkPLJ8kR3wp0KmKdu12c6D+u3yRvgPuLRgSKhuax5j2Qtb8f94u1DhqXPGYlrQsxdCgNISzSfBWfQ6lN/r6Bex0= Received: by 10.86.89.4 with SMTP id m4mr13256725fgb.45.1204392284907; Sat, 01 Mar 2008 09:24:44 -0800 (PST) Received: from ?192.168.1.103? ( [79.210.81.170]) by mx.google.com with ESMTPS id e11sm10136913fga.5.2008.03.01.09.24.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 01 Mar 2008 09:24:42 -0800 (PST) Message-ID: <47C99158.4000106@gmail.com> Date: Sat, 01 Mar 2008 18:24:40 +0100 User-Agent: Thunderbird 2.0.0.12 (X11/20080229) MIME-Version: 1.0 To: Peter Jeremy , freebsd-acpi@freebsd.org References: <20080220213200.BD12E4500F@ptavv.es.net> <47BCA0EA.4080508@gmail.com> <20080221083635.GI51095@server.vk2pj.dyndns.org> In-Reply-To: <20080221083635.GI51095@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Johannes Dieterich Cc: Subject: Re: [RFC] Patch to enable temperature ceiling in powerd 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, 01 Mar 2008 17:24:47 -0000 Hello everybody! To get back to this discussion (sorry, normal job kicked me quite a bit last week). Peter Jeremy wrote: > On Wed, Feb 20, 2008 at 05:06:41PM -0500, Daniel Eischen wrote: >> I'm having similar problems with an Intel STL2 Tupelo motherboard >> after upgrading to 7.0. > > I had problems with one TZ on my laptop occasionally reporting > nonsense values. I suspect it was actually a dry joint somewhere near > the sensor. The MB eventually failed and the new MB is OK. We had a > similar issue on a server at work - the vendor noticed that the system > was reporting an abnormally high temperature in one zone whilst > investigating an unrelated problem. We eventually decided it was a > faulty sensor and a replacement board fixed it. What I have now is the original hard drive (some 80 gig Fujitsu one) with a freshly installed Fedora 8 on it. I have been letting two instances of gnuchess playing against each other for a couple of hours (yes, I know... best stress test ever... ;-) ) which kept cpu usage at a nice 100 percent on both cores for all that time. proc/acpi/thermal_zones/THM1/temperature (and THM0) reported temperatures around 70 degrees, never over 72 for all that time. Lid was closed, fan worked (not very noisy even) and blew a good load of hot air out. I am tempted to say that my overheating problem is not hardware related. Only parts different were ath0 not working with Fedora and hard drive being not the 160 gig WD I am using for FreeBSD. > >> Only under load does the temperature >> shoot up, but I know the chip isn't getting hot and the fan >> is running - I've felt around in there and nothing was even >> close to the 117+C it was sensing. > > Apart from the actual CPU, most parts of a system have a fairly > significant thermal mass so a rapid change in temperature either > indicates a catastrophic failure or the temperature sensor isn't > really reporting the temperature of the relevant zone. > I totally agree with you, Peter. And either the hardware just fails under FreeBSD (or with ath0 and the other hard drive running) OR it is a FreeBSD problem. Everybody is invited to tell me how to stress test the system as brutal as possible to show that the problem is hardware related. Regards, Johannes