From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 4 23:53:44 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6561916ABC2 for ; Sun, 4 Jun 2006 23:53:44 +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 AA07E43D68 for ; Sun, 4 Jun 2006 23:53:30 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.6) with ESMTP id k54NuBcc053285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 4 Jun 2006 19:56:17 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-acpi@freebsd.org Date: Sun, 4 Jun 2006 19:53:44 -0400 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2061428.zxhYAkPlaC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606041953.53027.mistry.7@osu.edu> X-Spam-Status: No, score=-5.5 required=5.0 tests=ALL_TRUSTED,BAYES_50, MYFREEBSD2 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88.2/1512/Sun Jun 4 05:58:49 2006 on mail.united-ware.com X-Virus-Status: Clean Subject: ASRock K7Upgrade-880 with S3 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: Sun, 04 Jun 2006 23:53:47 -0000 --nextPart2061428.zxhYAkPlaC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I'm trying to get my desktop to STR (S3) and can't even get S3 to=20 semi-powered down state. 6.1-RELEASE-p1 I've updated the BIOS to the latest version. When I do an acpiconf -s=20 3 the suspend get all the way into the AcpiEnterSleepState function=20 and begins to write registers. The last line I see (with full ACPI=20 debugging enabled): heregs-0708 HwRegisterWrite : ----Entry Then the power light on the case starts to blink seeming to indicate=20 that it is in suspend, except I can still see output on the monitor=20 and the fans and harddrives are still running. Then when I press=20 the power button to try to bring the system back up it then displays: heregs-0708 HwRegisterWrite : ----Exit and then continues with a few more HwRegisterWrite and then exits the=20 AcpiEnterSleepState function and then does nothing. The system shows=20 no life of coming back. I then need to perform a cold boot, because=20 if I just hit the reset button the system doesn't restart to the=20 point where it gets to the BIOS screen. My acpidump output is at: http://am-productions.biz/docs/bigguy.asl I've fixed the errors in the asl and tried using that, but it showed=20 the same problem. http://am-productions.biz/docs/bigguy-fix.asl dmesg: http://am-productions.biz/docs/bigguy.dmesg Windows isn't installed on this system so I can't compare it with=20 that. I tried suspending with Knoppix (2006-06-01) and that worked a=20 bit better. It successfully shutoff the disks on suspend, but the=20 case fans and video card/monitor were still on. When you press the=20 power button again in knoppix it successfully brought the system back=20 to life. Getting it to the point of Knoppix would be a good start. S1 does work, but it doesn't shut anything down, so it's not really=20 useful. hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: S3 hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 5 hw.acpi.s4bios: 0 hw.acpi.verbose: 1 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% This is probably beyond hope, but I thought I'd ask first. :) =2D-=20 Anish Mistry --nextPart2061428.zxhYAkPlaC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEg3KQxqA5ziudZT0RAtNVAJ96wWt2jBcXUIUdErB4AGbCCkJGWgCgkvRT SWLwz69k4+uepO91gpkifvE= =e3nx -----END PGP SIGNATURE----- --nextPart2061428.zxhYAkPlaC-- From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 4 23:55:35 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A04A816A7C1 for ; Sun, 4 Jun 2006 23:55:35 +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 C452943D4C for ; Sun, 4 Jun 2006 23:55:34 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.6) with ESMTP id k54NwEOm053299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 4 Jun 2006 19:58:20 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-acpi@freebsd.org Date: Sun, 4 Jun 2006 19:55:56 -0400 User-Agent: KMail/1.9.1 References: <200606041953.53027.mistry.7@osu.edu> In-Reply-To: <200606041953.53027.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1368239.dL6tYifqgE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606041955.56720.mistry.7@osu.edu> X-Spam-Status: No, score=-5.5 required=5.0 tests=ALL_TRUSTED,BAYES_50, MYFREEBSD2 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88.2/1512/Sun Jun 4 05:58:49 2006 on mail.united-ware.com X-Virus-Status: Clean Subject: Re: ASRock K7Upgrade-880 with S3 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: Sun, 04 Jun 2006 23:55:37 -0000 --nextPart1368239.dL6tYifqgE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 04 June 2006 19:53, Anish Mistry wrote: > My acpidump output is at: > http://am-productions.biz/docs/bigguy.asl > I've fixed the errors in the asl and tried using that, but it > showed the same problem. > http://am-productions.biz/docs/bigguy-fix.asl I forgot to mention that when I do an acpidump -dt I see the following=20 message displayed: acpidump: RSDT entry 2 (sig OEMB) is corrupt =2D-=20 Anish Mistry --nextPart1368239.dL6tYifqgE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEg3MMxqA5ziudZT0RAtDhAJ43hEVUZG/tyA3am82LjTIhtz1UEACcDXhh F1LUN+bx5DTgc9DRaGnGMY8= =0/08 -----END PGP SIGNATURE----- --nextPart1368239.dL6tYifqgE-- From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 5 01:53:54 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BFAF16A629 for ; Mon, 5 Jun 2006 01:53:54 +0000 (UTC) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC13243D46 for ; Mon, 5 Jun 2006 01:53:53 +0000 (GMT) (envelope-from nate@root.org) Received: from [192.168.1.4] (n219077215102.netvigator.com [219.77.215.102]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k551rmqL030713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 4 Jun 2006 18:53:50 -0700 Message-ID: <44838E49.1060507@root.org> Date: Sun, 04 Jun 2006 18:52:09 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Anish Mistry References: <200606041953.53027.mistry.7@osu.edu> In-Reply-To: <200606041953.53027.mistry.7@osu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: ASRock K7Upgrade-880 with S3 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, 05 Jun 2006 01:53:54 -0000 Anish Mistry wrote: > I'm trying to get my desktop to STR (S3) and can't even get S3 to > semi-powered down state. 6.1-RELEASE-p1 > > I've updated the BIOS to the latest version. When I do an acpiconf -s > 3 the suspend get all the way into the AcpiEnterSleepState function > and begins to write registers. The last line I see (with full ACPI > debugging enabled): > heregs-0708 HwRegisterWrite : ----Entry > > Then the power light on the case starts to blink seeming to indicate > that it is in suspend, except I can still see output on the monitor > and the fans and harddrives are still running. Then when I press > the power button to try to bring the system back up it then displays: > heregs-0708 HwRegisterWrite : ----Exit > and then continues with a few more HwRegisterWrite and then exits the > AcpiEnterSleepState function and then does nothing. The system shows > no life of coming back. I then need to perform a cold boot, because > if I just hit the reset button the system doesn't restart to the > point where it gets to the BIOS screen. > > My acpidump output is at: > http://am-productions.biz/docs/bigguy.asl > I've fixed the errors in the asl and tried using that, but it showed > the same problem. > http://am-productions.biz/docs/bigguy-fix.asl > dmesg: > http://am-productions.biz/docs/bigguy.dmesg > > Windows isn't installed on this system so I can't compare it with > that. I tried suspending with Knoppix (2006-06-01) and that worked a > bit better. It successfully shutoff the disks on suspend, but the > case fans and video card/monitor were still on. When you press the > power button again in knoppix it successfully brought the system back > to life. Getting it to the point of Knoppix would be a good start. Try enabling the same acpi debugging prints on Linux (since they use acpi-ca also) and see if there are any diffs. Shutting disks off is the job of the ata driver, look into that. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 5 03:33:35 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CDF016A60F for ; Mon, 5 Jun 2006 03:33:35 +0000 (UTC) (envelope-from abuse@akavia.ru) Received: from smtp.spaceweb.ru (smtp.spaceweb.ru [217.170.76.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF6C443D72 for ; Mon, 5 Jun 2006 03:33:30 +0000 (GMT) (envelope-from abuse@akavia.ru) Received: from [62.33.174.250] (helo=admin.blg.akavia.ru) by smtp.spaceweb.ru with esmtp (Exim 4.60) (envelope-from ) id 1Fn5qI-0004hO-Ic for freebsd-acpi@freebsd.org; Mon, 05 Jun 2006 07:33:27 +0400 Date: Mon, 5 Jun 2006 13:32:01 +1000 From: Alexander Logvinov X-Mailer: The Bat! (v3.80.03) Professional Organization: AKA X-Priority: 3 (Normal) Message-ID: <1182686709.20060605133201@akavia.ru> To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Machine did not reboot X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Logvinov List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 03:33:37 -0000 Hello. I had FreeBSD 5.4. After entering 'shutdown -r now' the system hanged on: 'Shutting down ACPI' 'Rebooting' but did not reboot. Upgraded to 6.1, it didn't help. hw.acpi.disable_on_poweroff="1" has no effect. What should I do? Motherboard: Chaintech 7VJL with latest BIOS. # dmesg Copyright (c) 1992-2006 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 6.1-RELEASE-p1 #5: Fri Jun 2 11:59:37 YAKST 2006 user@akavia:/usr/obj/usr/src/sys/AKA ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 1800+ (1528.99-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0400800 real memory = 536805376 (511 MB) avail memory = 520134656 (496 MB) ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f on acpi0 pci0: on pcib0 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 skc0: port 0xc000-0xc0ff mem 0xe4020000-0xe4023fff irq 16 at device 9.0 on pci0 skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7) sk0: on skc0 sk0: Ethernet address: 00:0c:46:46:74:aa miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto ed0: port 0xc400-0xc41f irq 17 at device 10.0 on pci0 ed0: Ethernet address: 00:00:e8:dc:52:fc ed0: type RTL8029 (16 bit) ste0: port 0xc800-0xc87f irq 18 at device 11.0 on pci0 miibus1: on ste0 ukphy0: on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ste0: Ethernet address: 00:05:5d:7a:f0:ee pci0: at device 14.0 (no driver attached) uhci0: port 0xcc00-0xcc1f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd000-0xd01f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd400-0xd41f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: irq 21 at device 16.3 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: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd800-0xd80f at device 17.1 on pci0 ata0: on atapci0 ata1: on atapci0 vr0: port 0xdc00-0xdcff irq 23 at device 18.0 on pci0 miibus2: on vr0 ukphy1: on miibus2 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:50:70:22:53:8c pci0: at device 19.0 (no driver attached) acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc97ff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ucom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 2 Timecounter "TSC" frequency 1528986893 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding enabled, default to deny, logging limited to 100 packets/entry by default ad0: 76351MB at ata0-master UDMA100 acd0: CDROM at ata1-slave UDMA33 Trying to mount root from ufs:/dev/ad0s1a ext1: link state changed to UP -- WBR From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 5 11:02:46 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C20A116A41F for ; Mon, 5 Jun 2006 11:02:46 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8323D43D48 for ; Mon, 5 Jun 2006 11:02:46 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k55B2jMx010138 for ; Mon, 5 Jun 2006 11:02:45 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k55B2i8k010134 for freebsd-acpi@freebsd.org; Mon, 5 Jun 2006 11:02:44 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 5 Jun 2006 11:02:44 GMT Message-Id: <200606051102.k55B2i8k010134@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 05 Jun 2006 11:02:48 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2006/03/01] i386/93963 acpi [panic] [patch] ACPI Panic with some ACPI 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/22] i386/54756 acpi ACPI suspend/resume problem on CF-W2 lapt o [2003/08/17] i386/55661 acpi ACPI suspend/resume problem on ARMADA M70 o [2003/08/20] kern/55822 acpi No ACPI power off with SMP kernel o [2003/08/27] kern/56024 acpi ACPI suspend drains battery while in S3 o [2004/03/09] i386/64002 acpi acpi problem o [2004/05/27] i386/67273 acpi [hang] system hangs with acpi and Xfree o [2004/10/12] i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Arma o [2005/03/21] i386/79080 acpi acpi thermal changes freezes HP nx6110 o [2005/03/21] i386/79081 acpi ACPI suspend/resume not working on HP nx6 o [2005/04/28] i386/80426 acpi [APIC] [panic] 5.4-RC3 still panic when b o [2005/10/17] i386/87568 acpi [ACPI] [REGRESSION] 6.0-STABLE needs ACPI 11 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/05/28] kern/67309 acpi zzz reboot computer (ACPI S3) o [2004/07/29] i386/69750 acpi Boot without ACPI failed on ASUS L5 o [2004/11/11] i386/73822 acpi [request] add thermal support to ACPI o [2004/11/11] kern/73823 acpi [feature request] acpi / power-on by time f [2004/11/17] kern/74030 acpi Unplugging AC causes battery % to stay lo f [2005/12/24] kern/90871 acpi ACPI problems with ASUS A8N-VM-CSM o [2006/05/30] kern/98171 acpi [acpi] ACPI 1304 / 0501 errors on Acer 50 7 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 5 15:30:40 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61EB916A78D for ; Mon, 5 Jun 2006 15:30:40 +0000 (UTC) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 713FF43D45 for ; Mon, 5 Jun 2006 15:30:37 +0000 (GMT) (envelope-from nate@root.org) Received: from [192.168.1.4] (n219077215102.netvigator.com [219.77.215.102]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k55FTgqL009049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Jun 2006 08:29:46 -0700 Message-ID: <44844D7E.50909@root.org> Date: Mon, 05 Jun 2006 08:27:58 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Alexander Logvinov References: <1182686709.20060605133201@akavia.ru> In-Reply-To: <1182686709.20060605133201@akavia.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Machine did not reboot 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, 05 Jun 2006 15:30:45 -0000 Alexander Logvinov wrote: > Hello. > > I had FreeBSD 5.4. After entering 'shutdown -r now' the system hanged on: > 'Shutting down ACPI' > 'Rebooting' > but did not reboot. > Upgraded to 6.1, it didn't help. hw.acpi.disable_on_poweroff="1" has no effect. > What should I do? > > Motherboard: Chaintech 7VJL with latest BIOS. Try the reset_register method. I have MFC'd the patch to RELENG_6 so you can cvsup, recompile your acpi.ko, and test. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 5 18:34:57 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A57FD16B789 for ; Mon, 5 Jun 2006 18:34:57 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0ACF43D46 for ; Mon, 5 Jun 2006 18:34:56 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.6/8.13.1) with ESMTP id k55IYsAH074523; Mon, 5 Jun 2006 15:34:54 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: freebsd-acpi@freebsd.org Date: Mon, 5 Jun 2006 15:34:50 -0300 User-Agent: KMail/1.9.1 References: <1182686709.20060605133201@akavia.ru> <44844D7E.50909@root.org> In-Reply-To: <44844D7E.50909@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606051534.51449.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: Subject: Re: Machine did not reboot 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, 05 Jun 2006 18:35:00 -0000 On Monday 05 June 2006 12:27, Nate Lawson wrote: > > Try the reset_register method. I have MFC'd the patch to RELENG_6 so > you can cvsup, recompile your acpi.ko, and test. Nate, this patch is MB specific ou can possible help on any MB with this=20 particular problem? amd64 as well ? Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 5 18:52:20 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0337716A820 for ; Mon, 5 Jun 2006 18:52:20 +0000 (UTC) (envelope-from tuliosalvaro@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 183C843D49 for ; Mon, 5 Jun 2006 18:52:18 +0000 (GMT) (envelope-from tuliosalvaro@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so1539583uge for ; Mon, 05 Jun 2006 11:52:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=tieuXGw/1Cix56uFU3KfCk8gLjvP/Py+oSf2juSHHZtPj5OccimKts+SLHWkRf9acm8OVb1BYYIDvoqPR5yLQaCAJkWfxzMQRkQqHgyIjAajmDv9U2xGUXx5JjFUN8YwZ7Z5v9AyJUpc9sGejd1VC8nb1vlhcOUo904xCBYExxY= Received: by 10.67.89.5 with SMTP id r5mr3670578ugl; Mon, 05 Jun 2006 11:45:15 -0700 (PDT) Received: by 10.67.23.15 with HTTP; Mon, 5 Jun 2006 11:45:15 -0700 (PDT) Message-ID: Date: Mon, 5 Jun 2006 15:45:15 -0300 From: "Tulio Salvaro" To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: When I load acpi module, my HD doesn't load ... 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, 05 Jun 2006 18:52:23 -0000 Hi, I has a notebook toshiba M45-S355, It has HD SATA ... when I am booting the system with acpi module, the HD doesn't load and ths system doesn't mount root fs. I tried build the acpi.ko module with ACPI_DEBUG flag but when I load it on boot, It say: undefined reference to: AcpiDmDumpMethodInfo ... the code has this definition method and body method too. Is a problem of linker ??? The biggest problem is the processor without throttling ... Can somebody help ??? -- Tulio Salvaro GoogleTalk: tuliosalvaro@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 6 01:51:06 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC91716A75C for ; Tue, 6 Jun 2006 01:19:05 +0000 (UTC) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C94043D49 for ; Tue, 6 Jun 2006 01:19:05 +0000 (GMT) (envelope-from nate@root.org) Received: from [192.168.1.4] (n219077215102.netvigator.com [219.77.215.102]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k561IwqL020484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Jun 2006 18:19:00 -0700 Message-ID: <4484D795.9040203@root.org> Date: Mon, 05 Jun 2006 18:17:09 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: JoaoBR References: <1182686709.20060605133201@akavia.ru> <44844D7E.50909@root.org> <200606051534.51449.joao@matik.com.br> In-Reply-To: <200606051534.51449.joao@matik.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org Subject: Re: Machine did not reboot 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, 06 Jun 2006 01:51:06 -0000 JoaoBR wrote: > On Monday 05 June 2006 12:27, Nate Lawson wrote: > > >> Try the reset_register method. I have MFC'd the patch to RELENG_6 so >> you can cvsup, recompile your acpi.ko, and test. > > Nate, this patch is MB specific ou can possible help on any MB with this > particular problem? amd64 as well ? > > Joćo > Yes, you can see if it might help in the output from acpidump -t. Systems it will help have the RESET_REG flag set. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 6 01:58:54 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D14216D625 for ; Tue, 6 Jun 2006 01:27:05 +0000 (UTC) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBACE43D67 for ; Tue, 6 Jun 2006 01:26:56 +0000 (GMT) (envelope-from nate@root.org) Received: from [192.168.1.4] (n219077215102.netvigator.com [219.77.215.102]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k561QsqL020631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Jun 2006 18:26:55 -0700 Message-ID: <4484D97B.9060601@root.org> Date: Mon, 05 Jun 2006 18:25:15 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Tulio Salvaro References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: When I load acpi module, my HD doesn't load ... 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, 06 Jun 2006 01:58:54 -0000 Tulio Salvaro wrote: > Hi, > > I has a notebook toshiba M45-S355, It has HD SATA ... when I am booting > the system with acpi module, the HD doesn't load and ths system doesn't > mount root fs. > > I tried build the acpi.ko module with ACPI_DEBUG flag but when I load it > on boot, It say: undefined reference to: AcpiDmDumpMethodInfo ... the code > has this definition method and body method too. Is a problem of linker ??? > > The biggest problem is the processor without throttling ... > > Can somebody help ??? How about dmesg output with acpi loaded vs. without it loaded? You could do this by using the FreeSBIE distribution to get the dmesg without a hard drive. You have to recompile your kernel with options KDB as well when enabling ACPI_DEBUG. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 6 03:32:32 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E6AA16CA8D for ; Tue, 6 Jun 2006 02:46:37 +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 77E4F43D45 for ; Tue, 6 Jun 2006 02:46:36 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.6) with ESMTP id k562nNQN000706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jun 2006 22:49:29 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Nate Lawson Date: Mon, 5 Jun 2006 22:46:49 -0400 User-Agent: KMail/1.9.1 References: <200606041953.53027.mistry.7@osu.edu> <44838E49.1060507@root.org> In-Reply-To: <44838E49.1060507@root.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart574789191.C9uH4K2Ami"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606052246.57364.mistry.7@osu.edu> X-Spam-Status: No, score=-5.5 required=5.0 tests=ALL_TRUSTED,BAYES_50, MYFREEBSD3 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88.2/1514/Mon Jun 5 16:21:02 2006 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-acpi@freebsd.org Subject: Re: ASRock K7Upgrade-880 with S3 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, 06 Jun 2006 03:32:34 -0000 --nextPart574789191.C9uH4K2Ami Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 04 June 2006 21:52, Nate Lawson wrote: > Anish Mistry wrote: > > I'm trying to get my desktop to STR (S3) and can't even get S3 to > > semi-powered down state. 6.1-RELEASE-p1 > > > > I've updated the BIOS to the latest version. When I do an > > acpiconf -s 3 the suspend get all the way into the > > AcpiEnterSleepState function and begins to write registers. The > > last line I see (with full ACPI debugging enabled): > > heregs-0708 HwRegisterWrite : ----Entry > > > > Then the power light on the case starts to blink seeming to > > indicate that it is in suspend, except I can still see output on > > the monitor and the fans and harddrives are still running. Then > > when I press the power button to try to bring the system back up > > it then displays: heregs-0708 HwRegisterWrite : ----Exit > > and then continues with a few more HwRegisterWrite and then exits > > the AcpiEnterSleepState function and then does nothing. The > > system shows no life of coming back. I then need to perform a > > cold boot, because if I just hit the reset button the system > > doesn't restart to the point where it gets to the BIOS screen. > > > > My acpidump output is at: > > http://am-productions.biz/docs/bigguy.asl > > I've fixed the errors in the asl and tried using that, but it > > showed the same problem. > > http://am-productions.biz/docs/bigguy-fix.asl > > dmesg: > > http://am-productions.biz/docs/bigguy.dmesg > > > > Windows isn't installed on this system so I can't compare it with > > that. I tried suspending with Knoppix (2006-06-01) and that > > worked a bit better. It successfully shutoff the disks on > > suspend, but the case fans and video card/monitor were still on.=20 > > When you press the power button again in knoppix it successfully > > brought the system back to life. Getting it to the point of > > Knoppix would be a good start. > > Try enabling the same acpi debugging prints on Linux (since they > use acpi-ca also) and see if there are any diffs. After some searching I can't seem to figure out how to do this in=20 Linux. Any suggestions? =2D-=20 Anish Mistry --nextPart574789191.C9uH4K2Ami Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEhOyhxqA5ziudZT0RAs+uAJ43lVDd2PcUcPOh3S8I7MD6qO6JqwCeMKsF Y0EET/i8EQisK1npVBw1msQ= =tVW9 -----END PGP SIGNATURE----- --nextPart574789191.C9uH4K2Ami-- From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 6 05:30:45 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B01D16AC59 for ; Tue, 6 Jun 2006 05:19:10 +0000 (UTC) (envelope-from fkeinternet@FKEInternet.com) Received: from Huntington.FKEInternet.com (FKEinternet.net [206.135.8.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB31C43D49 for ; Tue, 6 Jun 2006 05:19:09 +0000 (GMT) (envelope-from fkeinternet@FKEInternet.com) Received: from Dozer.FKEInternet.com (office.fkeinternet.com [206.135.8.68]) by Huntington.FKEInternet.com (8.13.6/8.12.9) with ESMTP id k565J9Ct097192 for ; Tue, 6 Jun 2006 01:19:09 -0400 (EDT) (envelope-from fkeinternet@FKEInternet.com) Message-Id: <6.1.2.0.1.20060606011859.0b62f0a0@mail.FKEInternet.com> X-Sender: fkeinternet@mail.FKEInternet.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 06 Jun 2006 01:19:06 -0400 To: freebsd-acpi@freebsd.org From: Fred Koschara Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: FreeBSD 6.0, ThinkPad 600, dc0: watchdog timeout - 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: Tue, 06 Jun 2006 05:30:48 -0000 I just purchased another ThinkPad 600 and installed FreeBSD 6.0, expecting it would go as smoothly as had my previous installations of FreeBSD on my Web, database and nameservers, on the desktop machine on which I'm experimenting with FreeBSD programming, and on the Dell Latitude where FreeBSD is one of the 5 operating systems I have installed. The installation did, indeed, seem to go smoothly. However, network connectivity is an issue: Any time I try to do something that would connect to the network (ntpd checking for time servers, sendmail starting during the boot process, ftp, ping) I get dc0 watchdog timeout errors, and most of the time nothing else. When I ping the network gateway, nothing happens for several seconds, then ping reports response times of 8.77~, 7.77~, 6.77~, ..., 0.77~ seconds in a batch, then "goes to sleep" again, repeating the sequence. I made the mistake of trying to start Gnome with this problem occurring. When, over an hour later, I was able to *finally* get to where I could shut the desktop down gracefully, I resolved to not do *that* exercise again! This laptop came with two PCMCIA network cards - an IBM 10/100 EtherJet CardBus 32-bit adapter, and a 3Com 3C574-TX 10/100Base-TX 16-bit adapter. The EtherJet is the one I'm getting the dc0 watchdog timeout errors with. When I try the 3Com, the boot process reports that it's detected the card, but it doesn't make a network connection. I tried the D-Link DFE-690TXD I use all the time in my w98 ThinkPad. FreeBSD recognized the card, but did not attempt to configure it or make a network connection. I also tried a D-Link DWL-G630 AirPlus G wireless card, which FreeBSD didn't even know was there, as well as a D-Link DWL-AB650 AirPro A/B wireless card. FreeBSD acknowledged the presence of the AB650, but said there was no driver attached. The EtherJet works correctly with both w2K on my Lattitude, and under w98 on my other ThinkPad (once I downloaded the drivers). During the boot process, FreeBSD properly discovers the network card and seems to be configuring it, including negotiating the IP address with the DHCP server. Immediately after printing the MAC address, a bold text line is written saying "dc0: link state changed to DOWN" and it writes the two remaining lines ("media: Ethernet autoselect (none)" and "status: no carrier"). There have been times when another bold line was printed later saying "dc0: link state changed to UP", but the condition did not persist, because I was getting dc0: watchdog timeout errors before the boot process was done in those cases as well. I tried using ifconfig to force the EtherJet into 10Mbps mode, as well as full and half duplex, but none of those changes seem to have made any difference. I also added "media 100baseTX mediaopt full-duplex" to the ifconfig_dc0 line in rc.conf. This changed the reported "Ethernet autoselect (none)" to "Ethernet 100baseTX " as expected, but the "status: no carrier" keeps coming up. When I boot FreeBSD with ACPI disabled (option 2), it reports several unknown devices in the PCI PnP scan (not surprising) - and the EtherJet works correctly. (Gnome comes up quickly, also.) However, when I boot with ACPI enabled (option 1), the EtherJet cannot connect. I booted with verbose logging, and noticed a couple of things: There are 4 devices, in addition to the cardbus device, assigned to irq 9 (which is the irq being used for the network connection, from what I can see), and FreeBSD says the cardbus device is 16 bits, not 32 bits. The man dc(4) page says the dc%d: watchdog timeout error can happen if the device is unable to deliver interrupts for some reason, or if there is a problem with the network connection. If there was a problem with the network connection, I would expect to the lights on the switch (a D-Link DSS-8+) to not be showing a solid network connetion, but this isn't happening. When Gnome is starting, it also reports "No volume control elements and/or devices found." I thought this might be related to whether ACPI was active or not, but the same error message is displayed in both cases. I don't know if this is a related issue or not. uname -a reports "FreeBSD London.FKEinternet.com 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386" Please advise if any further information would be helpful in resolving this problem - should I send the verbose dmesg output? dmesg with and without ACPI, for comparison? Thanks for any suggestions and support! -- Fred Koschara ________________________________________________________________________ Ignorance can easily be cured by knowledge, stupidity is generally only cured by death... Truth and Falsehood were bathing. Falsehood came out of the water first and dressed herself in Truth's clothes. Truth, unwilling to put on the garments of Falsehood, went naked. (Author Unknown) The "war on terror" is a sham: There is no real protection against suicidal maniacs spurred on by creative madmen. In the end, the only outcomes will be the destruction of the American economy due to pouring a bankrupting stream of wealth into a bottomless pit, and the final destruction of personal liberty in the name of "security." (When was the last time you were asked for "Your papers, please?" - er, that is, "License and registration?") FKE Internet, Web hosting for space related businesses
Domain registration - $15.95/year, $29.95 for 2 years http://FKEinternet.com For private sector (commercial) space development, visit http://www.L5Development.com For your daily dose of art, try http://PhotoByFred.com L5 Software Development - "out of this world" sites and software http://www.L5Software.com How much did your last traffic ticket cost you? http://www.StopHighwayRobbery.com FredLines(tm), T-Shirts For the Thinking Mind(tm) http://www.FredLines-TShirts.com From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 7 00:17:50 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B32CA16D0A5 for ; Tue, 6 Jun 2006 23:41:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46BA643D46 for ; Tue, 6 Jun 2006 23:41:28 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id k56NfJkL074065; Tue, 6 Jun 2006 19:41:19 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Tue, 6 Jun 2006 19:41:04 -0400 User-Agent: KMail/1.6.2 References: <1182686709.20060605133201@akavia.ru> <44844D7E.50909@root.org> In-Reply-To: <44844D7E.50909@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200606061941.06244.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88/1516/Tue Jun 6 18:45:31 2006 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Alexander Logvinov Subject: Re: Machine did not reboot 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, 07 Jun 2006 00:17:51 -0000 On Monday 05 June 2006 11:27 am, Nate Lawson wrote: > Alexander Logvinov wrote: > > Hello. > > > > I had FreeBSD 5.4. After entering 'shutdown -r now' the system > > hanged on: 'Shutting down ACPI' > > 'Rebooting' > > but did not reboot. > > Upgraded to 6.1, it didn't help. hw.acpi.disable_on_poweroff="1" > > has no effect. What should I do? > > > > Motherboard: Chaintech 7VJL with latest BIOS. > > Try the reset_register method. I have MFC'd the patch to RELENG_6 > so you can cvsup, recompile your acpi.ko, and test. Nate, RB_AUTOBOOT is defined as 0 in sys/reboot.h. I don't think this test will ever work: if ((howto & RB_AUTOBOOT) != 0 && AcpiGbl_FADT->ResetRegSup) { Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 7 00:41:20 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B9BB16A933 for ; Wed, 7 Jun 2006 00:23:33 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 666BA43D46 for ; Wed, 7 Jun 2006 00:23:32 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id k570NB2O074783; Tue, 6 Jun 2006 20:23:11 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Nate Lawson Date: Tue, 6 Jun 2006 20:22:57 -0400 User-Agent: KMail/1.6.2 References: <1182686709.20060605133201@akavia.ru> <44844D7E.50909@root.org> <200606061941.06244.jkim@FreeBSD.org> In-Reply-To: <200606061941.06244.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_jxhhE/+KQrMaT0M" Message-Id: <200606062022.59336.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88/1516/Tue Jun 6 18:45:31 2006 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org Subject: Re: Machine did not reboot 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, 07 Jun 2006 00:41:21 -0000 --Boundary-00=_jxhhE/+KQrMaT0M Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday 06 June 2006 07:41 pm, Jung-uk Kim wrote: > On Monday 05 June 2006 11:27 am, Nate Lawson wrote: > > Alexander Logvinov wrote: > > > Hello. > > > > > > I had FreeBSD 5.4. After entering 'shutdown -r now' the system > > > hanged on: 'Shutting down ACPI' > > > 'Rebooting' > > > but did not reboot. > > > Upgraded to 6.1, it didn't help. > > > hw.acpi.disable_on_poweroff="1" has no effect. What should I > > > do? > > > > > > Motherboard: Chaintech 7VJL with latest BIOS. > > > > Try the reset_register method. I have MFC'd the patch to > > RELENG_6 so you can cvsup, recompile your acpi.ko, and test. > > Nate, > > RB_AUTOBOOT is defined as 0 in sys/reboot.h. I don't think this > test will ever work: > > if ((howto & RB_AUTOBOOT) != 0 && AcpiGbl_FADT->ResetRegSup) { It's little radical but what do you think about the attached patch? I don't think we have to call AcpiTerminate() to reboot at all. In fact, I have a box which does not reboot. Writing ACPI_DISABLE to SMI_CMD hangs the system and it does not support RESET_REG. :-( If I don't call AcpiTerminate(), everything's fine. Thanks, Jung-uk Kim --Boundary-00=_jxhhE/+KQrMaT0M Content-Type: text/plain; charset="iso-8859-1"; name="acpi_shutdown.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="acpi_shutdown.diff" --- sys/dev/acpica/acpi.c 6 Jun 2006 18:30:38 -0000 +++ sys/dev/acpica/acpi.c 7 Jun 2006 00:12:12 -0000 @@ -240,6 +240,12 @@ SYSCTL_INT(_debug_acpi, OID_AUTO, do_powerstate, CTLFLAG_RW, &acpi_do_powerstate, 1, "Turn off devices when suspending."); +/* Terminate ACPI when shutting down. */ +static int acpi_shutdown_terminate = 1; +TUNABLE_INT("debug.acpi.shutdown_terminate", &acpi_shutdown_terminate); +SYSCTL_INT(_debug_acpi, OID_AUTO, shutdown_terminate, CTLFLAG_RW, + &acpi_shutdown_terminate, 1, "Terminate ACPI when shutting down."); + /* Allow users to override quirks. */ TUNABLE_INT("debug.acpi.quirks", &acpi_quirks); @@ -1645,7 +1651,12 @@ DELAY(1000000); printf("ACPI power-off failed - timeout\n"); } - } else if ((howto & RB_AUTOBOOT) != 0 && AcpiGbl_FADT->ResetRegSup) { + } else if ((howto & RB_HALT) != 0) { + if (panicstr == NULL && acpi_shutdown_terminate) { + printf("Shutting down ACPI\n"); + AcpiTerminate(); + } + } else if (AcpiGbl_FADT->ResetRegSup) { status = AcpiHwLowLevelWrite( AcpiGbl_FADT->ResetRegister.RegisterBitWidth, AcpiGbl_FADT->ResetValue, &AcpiGbl_FADT->ResetRegister); @@ -1655,9 +1666,6 @@ DELAY(1000000); printf("ACPI reset failed - timeout\n"); } - } else if (panicstr == NULL) { - printf("Shutting down ACPI\n"); - AcpiTerminate(); } } --Boundary-00=_jxhhE/+KQrMaT0M-- From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 7 01:38:44 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4413316A7F4 for ; Wed, 7 Jun 2006 01:29:10 +0000 (UTC) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id E126743D45 for ; Wed, 7 Jun 2006 01:29:09 +0000 (GMT) (envelope-from nate@root.org) Received: from [192.168.1.4] (n219077215102.netvigator.com [219.77.215.102]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k571T6qL025996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Jun 2006 18:29:08 -0700 Message-ID: <4485429D.1030001@root.org> Date: Tue, 06 Jun 2006 01:53:49 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Anish Mistry References: <200606041953.53027.mistry.7@osu.edu> <44838E49.1060507@root.org> <200606052246.57364.mistry.7@osu.edu> In-Reply-To: <200606052246.57364.mistry.7@osu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: ASRock K7Upgrade-880 with S3 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, 07 Jun 2006 01:38:45 -0000 Anish Mistry wrote: > On Sunday 04 June 2006 21:52, Nate Lawson wrote: >> Anish Mistry wrote: >>> I'm trying to get my desktop to STR (S3) and can't even get S3 to >>> semi-powered down state. 6.1-RELEASE-p1 >>> >>> I've updated the BIOS to the latest version. When I do an >>> acpiconf -s 3 the suspend get all the way into the >>> AcpiEnterSleepState function and begins to write registers. The >>> last line I see (with full ACPI debugging enabled): >>> heregs-0708 HwRegisterWrite : ----Entry >>> >>> Then the power light on the case starts to blink seeming to >>> indicate that it is in suspend, except I can still see output on >>> the monitor and the fans and harddrives are still running. Then >>> when I press the power button to try to bring the system back up >>> it then displays: heregs-0708 HwRegisterWrite : ----Exit >>> and then continues with a few more HwRegisterWrite and then exits >>> the AcpiEnterSleepState function and then does nothing. The >>> system shows no life of coming back. I then need to perform a >>> cold boot, because if I just hit the reset button the system >>> doesn't restart to the point where it gets to the BIOS screen. >>> >>> My acpidump output is at: >>> http://am-productions.biz/docs/bigguy.asl >>> I've fixed the errors in the asl and tried using that, but it >>> showed the same problem. >>> http://am-productions.biz/docs/bigguy-fix.asl >>> dmesg: >>> http://am-productions.biz/docs/bigguy.dmesg >>> >>> Windows isn't installed on this system so I can't compare it with >>> that. I tried suspending with Knoppix (2006-06-01) and that >>> worked a bit better. It successfully shutoff the disks on >>> suspend, but the case fans and video card/monitor were still on. >>> When you press the power button again in knoppix it successfully >>> brought the system back to life. Getting it to the point of >>> Knoppix would be a good start. >> Try enabling the same acpi debugging prints on Linux (since they >> use acpi-ca also) and see if there are any diffs. > After some searching I can't seem to figure out how to do this in > Linux. Any suggestions? > ask on the linux list? ACPI Developers -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 7 05:44:30 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F9B316A4F2 for ; Wed, 7 Jun 2006 05:44:30 +0000 (UTC) (envelope-from abuse@akavia.ru) Received: from smtp.spaceweb.ru (smtp.spaceweb.ru [217.170.76.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4A9E43D4C for ; Wed, 7 Jun 2006 05:44:29 +0000 (GMT) (envelope-from abuse@akavia.ru) Received: from [62.33.174.250] (helo=admin.blg.akavia.ru) by smtp.spaceweb.ru with esmtp (Exim 4.60) (envelope-from ) id 1FnqqC-0006N5-6d for freebsd-acpi@freebsd.org; Wed, 07 Jun 2006 09:44:28 +0400 Date: Wed, 7 Jun 2006 15:44:24 +1000 From: Alexander Logvinov X-Mailer: The Bat! (v3.80.03) Professional Organization: AKA X-Priority: 3 (Normal) Message-ID: <121000959.20060607154424@akavia.ru> To: freebsd-acpi@freebsd.org In-Reply-To: <200606062022.59336.jkim@FreeBSD.org> References: <1182686709.20060605133201@akavia.ru> <44844D7E.50909@root.org> <200606061941.06244.jkim@FreeBSD.org> <200606062022.59336.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[2]: Machine did not reboot X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Logvinov List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 05:44:40 -0000 Hello. >> > > I had FreeBSD 5.4. After entering 'shutdown -r now' the system >> > > hanged on: 'Shutting down ACPI' >> > > 'Rebooting' >> > > but did not reboot. >> > > Upgraded to 6.1, it didn't help. >> > > hw.acpi.disable_on_poweroff="1" has no effect. What should I >> > > do? >> > > Motherboard: Chaintech 7VJL with latest BIOS. >> > Try the reset_register method. I have MFC'd the patch to >> > RELENG_6 so you can cvsup, recompile your acpi.ko, and test. It doesn't help. Because acpi_shutdown_final in function goes to else if (panicstr == NULL) { printf("Shutting down ACPI\n"); AcpiTerminate(); } and hangs up. >> RB_AUTOBOOT is defined as 0 in sys/reboot.h. I don't think this >> test will ever work: >> if ((howto & RB_AUTOBOOT) != 0 && AcpiGbl_FADT->ResetRegSup) { > It's little radical but what do you think about the attached patch? I > don't think we have to call AcpiTerminate() to reboot at all. In > fact, I have a box which does not reboot. Writing ACPI_DISABLE to > SMI_CMD hangs the system and it does not support RESET_REG. :-( If I > don't call AcpiTerminate(), everything's fine. I'll try this patch soon, thanks. -- WBR From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 7 13:32:17 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB08616B062 for ; Wed, 7 Jun 2006 12:45:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89F6E43D55 for ; Wed, 7 Jun 2006 12:45:16 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k57CjAbU068753; Wed, 7 Jun 2006 08:45:12 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Wed, 7 Jun 2006 08:08:55 -0400 User-Agent: KMail/1.9.1 References: <6.1.2.0.1.20060606011859.0b62f0a0@mail.FKEInternet.com> In-Reply-To: <6.1.2.0.1.20060606011859.0b62f0a0@mail.FKEInternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606070808.56332.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, 07 Jun 2006 08:45:12 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1517/Tue Jun 6 20:05:07 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Fred Koschara Subject: Re: FreeBSD 6.0, ThinkPad 600, dc0: watchdog timeout - 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: Wed, 07 Jun 2006 13:32:21 -0000 On Tuesday 06 June 2006 01:19, Fred Koschara wrote: > I just purchased another ThinkPad 600 and installed FreeBSD 6.0, expecting > it would go as smoothly as had my previous installations of FreeBSD on my > Web, database and nameservers, on the desktop machine on which I'm > experimenting with FreeBSD programming, and on the Dell Latitude where > FreeBSD is one of the 5 operating systems I have installed. The > installation did, indeed, seem to go smoothly. However, network > connectivity is an issue: Any time I try to do something that would > connect to the network (ntpd checking for time servers, sendmail starting > during the boot process, ftp, ping) I get dc0 watchdog timeout errors, and > most of the time nothing else. When I ping the network gateway, nothing > happens for several seconds, then ping reports response times of 8.77~, > 7.77~, 6.77~, ..., 0.77~ seconds in a batch, then "goes to sleep" again, > repeating the sequence. > > I made the mistake of trying to start Gnome with this problem > occurring. When, over an hour later, I was able to *finally* get to where > I could shut the desktop down gracefully, I resolved to not do *that* > exercise again! > > This laptop came with two PCMCIA network cards - an IBM 10/100 EtherJet > CardBus 32-bit adapter, and a 3Com 3C574-TX 10/100Base-TX 16-bit > adapter. The EtherJet is the one I'm getting the dc0 watchdog timeout > errors with. When I try the 3Com, the boot process reports that it's > detected the card, but it doesn't make a network connection. I tried the > D-Link DFE-690TXD I use all the time in my w98 ThinkPad. FreeBSD > recognized the card, but did not attempt to configure it or make a network > connection. I also tried a D-Link DWL-G630 AirPlus G wireless card, which > FreeBSD didn't even know was there, as well as a D-Link DWL-AB650 AirPro > A/B wireless card. FreeBSD acknowledged the presence of the AB650, but > said there was no driver attached. > > The EtherJet works correctly with both w2K on my Lattitude, and under w98 > on my other ThinkPad (once I downloaded the drivers). > > During the boot process, FreeBSD properly discovers the network card and > seems to be configuring it, including negotiating the IP address with the > DHCP server. Immediately after printing the MAC address, a bold text line > is written saying "dc0: link state changed to DOWN" and it writes the two > remaining lines ("media: Ethernet autoselect (none)" and "status: no > carrier"). There have been times when another bold line was printed later > saying "dc0: link state changed to UP", but the condition did not persist, > because I was getting dc0: watchdog timeout errors before the boot process > was done in those cases as well. > > I tried using ifconfig to force the EtherJet into 10Mbps mode, as well as > full and half duplex, but none of those changes seem to have made any > difference. I also added "media 100baseTX mediaopt full-duplex" to the > ifconfig_dc0 line in rc.conf. This changed the reported "Ethernet > autoselect (none)" to "Ethernet 100baseTX " as expected, but > the "status: no carrier" keeps coming up. > > When I boot FreeBSD with ACPI disabled (option 2), it reports several > unknown devices in the PCI PnP scan (not surprising) - and the EtherJet > works correctly. (Gnome comes up quickly, also.) However, when I boot > with ACPI enabled (option 1), the EtherJet cannot connect. I booted with > verbose logging, and noticed a couple of things: There are 4 devices, in > addition to the cardbus device, assigned to irq 9 (which is the irq being > used for the network connection, from what I can see), and FreeBSD says the > cardbus device is 16 bits, not 32 bits. > > The man dc(4) page says the dc%d: watchdog timeout error can happen if the > device is unable to deliver interrupts for some reason, or if there is a > problem with the network connection. If there was a problem with the > network connection, I would expect to the lights on the switch (a D-Link > DSS-8+) to not be showing a solid network connetion, but this isn't happening. > > When Gnome is starting, it also reports "No volume control elements and/or > devices found." I thought this might be related to whether ACPI was active > or not, but the same error message is displayed in both cases. I don't > know if this is a related issue or not. > > uname -a reports > "FreeBSD London.FKEinternet.com 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC > 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386" > > Please advise if any further information would be helpful in resolving this > problem - should I send the verbose dmesg output? dmesg with and without > ACPI, for comparison? > > Thanks for any suggestions and support! > > -- Fred Koschara Please provide verbose dmesg's for the ACPI and non-ACPI cases and please. Preferably upload them somewhere and provide the URLs since the mailing lists often drop attachments. Thanks! -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 7 21:35:22 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68A3B16B844 for ; Wed, 7 Jun 2006 19:24:28 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id C089743D49 for ; Wed, 7 Jun 2006 19:24:27 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id k57JOJ4G005133; Wed, 7 Jun 2006 15:24:22 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Alexander Logvinov Date: Wed, 7 Jun 2006 15:24:04 -0400 User-Agent: KMail/1.6.2 References: <1182686709.20060605133201@akavia.ru> <200606062022.59336.jkim@FreeBSD.org> <121000959.20060607154424@akavia.ru> In-Reply-To: <121000959.20060607154424@akavia.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_XfyhEZz3nBeaHyx" Message-Id: <200606071524.07284.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88/1518/Wed Jun 7 09:10:04 2006 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org, "Moore, Robert" Subject: Re: Re[2]: Machine did not reboot 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, 07 Jun 2006 21:35:23 -0000 --Boundary-00=_XfyhEZz3nBeaHyx Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 07 June 2006 01:44 am, Alexander Logvinov wrote: > Hello. > > >> > > I had FreeBSD 5.4. After entering 'shutdown -r now' the > >> > > system hanged on: 'Shutting down ACPI' > >> > > 'Rebooting' > >> > > but did not reboot. > >> > > Upgraded to 6.1, it didn't help. > >> > > hw.acpi.disable_on_poweroff="1" has no effect. What should I > >> > > do? > >> > > Motherboard: Chaintech 7VJL with latest BIOS. > >> > > >> > Try the reset_register method. I have MFC'd the patch to > >> > RELENG_6 so you can cvsup, recompile your acpi.ko, and test. > > It doesn't help. Because acpi_shutdown_final in function goes to > > else if (panicstr == NULL) { > printf("Shutting down ACPI\n"); > AcpiTerminate(); > } > > and hangs up. > > >> RB_AUTOBOOT is defined as 0 in sys/reboot.h. I don't think this > >> test will ever work: > >> if ((howto & RB_AUTOBOOT) != 0 && > >> AcpiGbl_FADT->ResetRegSup) { > > > > It's little radical but what do you think about the attached > > patch? I don't think we have to call AcpiTerminate() to reboot > > at all. In fact, I have a box which does not reboot. Writing > > ACPI_DISABLE to SMI_CMD hangs the system and it does not support > > RESET_REG. :-( If I don't call AcpiTerminate(), everything's > > fine. > > I'll try this patch soon, thanks. I don't know what ACPI spec. says (I guess I'll have to look it up) but Linux doesn't seem to use it except for ACPI init failure case. Now I have another evil hack (attached). It will help rebooting without RESET_REG support and/or with broken BIOS. Basically, it just bypasses AcpiDisable(), which may cause hang when ACPI_DISABLE through SMI_CMD is issued. Thanks, Jung-uk Kim --Boundary-00=_XfyhEZz3nBeaHyx Content-Type: text/plain; charset="iso-8859-1"; name="acpi_shutdown.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="acpi_shutdown.diff" --- sys/dev/acpica/acpi.c 6 Jun 2006 18:30:38 -0000 +++ sys/dev/acpica/acpi.c 7 Jun 2006 19:08:27 -0000 @@ -240,6 +240,12 @@ SYSCTL_INT(_debug_acpi, OID_AUTO, do_powerstate, CTLFLAG_RW, &acpi_do_powerstate, 1, "Turn off devices when suspending."); +/* Disable ACPI when shutting down. */ +static int acpi_do_disable = 0; +TUNABLE_INT("debug.acpi.do_disable", &acpi_do_disable); +SYSCTL_INT(_debug_acpi, OID_AUTO, do_disable, CTLFLAG_RW, + &acpi_do_disable, 0, "Disable ACPI when shutting down."); + /* Allow users to override quirks. */ TUNABLE_INT("debug.acpi.quirks", &acpi_quirks); @@ -1645,7 +1651,7 @@ DELAY(1000000); printf("ACPI power-off failed - timeout\n"); } - } else if ((howto & RB_AUTOBOOT) != 0 && AcpiGbl_FADT->ResetRegSup) { + } else if ((howto & RB_HALT) == 0 && AcpiGbl_FADT->ResetRegSup) { status = AcpiHwLowLevelWrite( AcpiGbl_FADT->ResetRegister.RegisterBitWidth, AcpiGbl_FADT->ResetValue, &AcpiGbl_FADT->ResetRegister); @@ -1656,6 +1662,9 @@ printf("ACPI reset failed - timeout\n"); } } else if (panicstr == NULL) { + /* XXX Evil hack to bypass AcpiDisable(). */ + if (!acpi_do_disable) + AcpiGbl_OriginalMode = ACPI_SYS_MODE_ACPI; printf("Shutting down ACPI\n"); AcpiTerminate(); } --Boundary-00=_XfyhEZz3nBeaHyx-- From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 7 23:51:37 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B2F5170A74 for ; Wed, 7 Jun 2006 21:21:38 +0000 (UTC) (envelope-from sepotvin@videotron.ca) Received: from tomts45-srv.bellnexxia.net (tomts45.bellnexxia.net [209.226.175.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5115F43D55 for ; Wed, 7 Jun 2006 21:21:37 +0000 (GMT) (envelope-from sepotvin@videotron.ca) Received: from mail.telcobridges.com ([67.70.237.76]) by tomts45-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060607212134.NEVW17057.tomts45-srv.bellnexxia.net@mail.telcobridges.com> for ; Wed, 7 Jun 2006 17:21:34 -0400 Received: from [192.168.0.107] (modemcable237.137-80-70.mc.videotron.ca [70.80.137.237]) (authenticated bits=0) by mail.telcobridges.com (8.13.3/8.13.3) with ESMTP id k57LLX7S077677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Jun 2006 17:21:33 -0400 (EDT) (envelope-from sepotvin@videotron.ca) Message-ID: <44874358.6050608@videotron.ca> Date: Wed, 07 Jun 2006 17:21:28 -0400 From: "Stephane E. Potvin" User-Agent: Thunderbird 1.5.0.4 (X11/20060605) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org Content-Type: multipart/mixed; boundary="------------020609000000060304070901" Cc: Subject: [patch] Support for asymetrical per-cpu Cx states 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, 07 Jun 2006 23:51:37 -0000 This is a multi-part message in MIME format. --------------020609000000060304070901 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit What started as a quick check why my laptop was not giving me Cx states higher than C1 turned out in a major rework of the way the acpi_cpu driver works. The attached patch makes the following modifications to the driver: - Support for asymetrical and per-cpu Cx states. This is done by parsing the _CST packages for each cpu and tracking all the states individually, on a per-cpu basis. - Support to revert to generic FADT/P_BLK based Cx control if the _CST package are not present on all cpus. In that case, the new driver will still support per-cpu Cx state handling. The driver will determine the highest Cx level that can be supported by all the cpus and configure the available Cx state based on that. - Fixed the case where multiple cpus in the system share the same registers for Cx state handling. To do that, I added a new flag parameter to the acpi_PkgGas and acpi_bus_alloc_gas functions that enable the caller to add the RF_SHAREABLE flag. This will probably fix the case where enabling the HT core would remove all Cx states (except C1), but I have no mean to check it at this time. I've not added this flag to the other callers in the tree but I guess that some of them could use this flag when multiple cpus are present. - I also found out that for Core Duo cpus, both cores seems to be taken out of C3 state when any one of the cores need to transition out. This broke the short sleep detection logic. I disabled it if there are more than one cpu in the system for now as it fixed it in my case. I guess that proper quirks handling will be required to fix this for known non working systems. - Added support to control cx_lowest on a per-cpu basis. I also implemented a generic cx_lowest to enable changing cx_lowest for all cpus with a single sysctl and for backward compatibility. The value returned on read is kind of meaningless (is there an easy way to have a write-only sysctl?) I've not done the same for the cx_supported case as I was not sure which way to handle it in case all supported Cx states were not symmetrical. Sample output for the new sysctl: hw.acpi.cpu.0.cx_supported: C1/1 C2/1 C3/57 hw.acpi.cpu.0.cx_lowest: C3 hw.acpi.cpu.0.cx_usage: 0.00% 43.16% 56.83% hw.acpi.cpu.1.cx_supported: C1/1 C2/1 C3/57 hw.acpi.cpu.1.cx_lowest: C3 hw.acpi.cpu.1.cx_usage: 0.00% 45.65% 54.34% hw.acpi.cpu.cx_lowest: C3 I would appreciate any feedback, positive or negative, on this :) Steph --------------020609000000060304070901 Content-Type: text/x-patch; name="acpi_cpu.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_cpu.diff" Index: etc/rc.d/power_profile =================================================================== RCS file: /home/FreeBSD/ncvs/src/etc/rc.d/power_profile,v retrieving revision 1.9 diff -u -r1.9 power_profile --- etc/rc.d/power_profile 21 Dec 2005 01:19:20 -0000 1.9 +++ etc/rc.d/power_profile 7 Jun 2006 21:16:12 -0000 @@ -76,7 +76,7 @@ # Set the various sysctls based on the profile's values. node="hw.acpi.cpu.cx_lowest" highest_value="C1" -lowest_value="`(sysctl -n hw.acpi.cpu.cx_supported | \ +lowest_value="`(sysctl -n hw.acpi.cpu.0.cx_supported | \ awk '{ print "C" split($0, a) }' -) 2> /dev/null`" eval value=\$${profile}_cx_lowest sysctl_set Index: sys/dev/acpica/acpi.c =================================================================== RCS file: /home/FreeBSD/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.224 diff -u -r1.224 acpi.c --- sys/dev/acpica/acpi.c 16 May 2006 14:36:22 -0000 1.224 +++ sys/dev/acpica/acpi.c 7 Jun 2006 20:50:37 -0000 @@ -1106,7 +1106,7 @@ /* Allocate an IO port or memory resource, given its GAS. */ int acpi_bus_alloc_gas(device_t dev, int *type, int *rid, ACPI_GENERIC_ADDRESS *gas, - struct resource **res) + struct resource **res, u_int flags) { int error, res_type; @@ -1139,7 +1139,7 @@ bus_set_resource(dev, res_type, *rid, gas->Address, gas->RegisterBitWidth / 8); - *res = bus_alloc_resource_any(dev, res_type, rid, RF_ACTIVE); + *res = bus_alloc_resource_any(dev, res_type, rid, RF_ACTIVE | flags); if (*res != NULL) { *type = res_type; error = 0; Index: sys/dev/acpica/acpi_cpu.c =================================================================== RCS file: /home/FreeBSD/ncvs/src/sys/dev/acpica/acpi_cpu.c,v retrieving revision 1.59 diff -u -r1.59 acpi_cpu.c --- sys/dev/acpica/acpi_cpu.c 25 Oct 2005 21:15:47 -0000 1.59 +++ sys/dev/acpica/acpi_cpu.c 7 Jun 2006 20:50:37 -0000 @@ -51,9 +51,6 @@ /* * Support for ACPI Processor devices, including C[1-3] sleep states. - * - * TODO: implement scans of all CPUs to be sure all Cx states are - * equivalent. */ /* Hooks for the ACPI CA debugging infrastructure */ @@ -80,6 +77,16 @@ int cpu_cx_count; /* Number of valid Cx states. */ int cpu_prev_sleep;/* Last idle sleep duration. */ int cpu_features; /* Child driver supported features. */ + /* Runtime state. */ + int cpu_non_c3; /* Index of lowest non-C3 state. */ + int cpu_short_slp; /* Count of < 1us sleeps. */ + u_int cpu_cx_stats[MAX_CX_STATES];/* Cx usage history. */ + /* Values for sysctl. */ + struct sysctl_ctx_list acpi_cpu_sysctl_ctx; + struct sysctl_oid *acpi_cpu_sysctl_tree; + int cpu_cx_lowest; + char cpu_cx_supported[64]; + int cpu_rid; }; struct acpi_cpu_device { @@ -110,20 +117,17 @@ /* Platform hardware resource information. */ static uint32_t cpu_smi_cmd; /* Value to write to SMI_CMD. */ static uint8_t cpu_cst_cnt; /* Indicate we are _CST aware. */ -static int cpu_rid; /* Driver-wide resource id. */ static int cpu_quirks; /* Indicate any hardware bugs. */ /* Runtime state. */ +static int cpu_disable_idle; /* Disable idle function */ static int cpu_cx_count; /* Number of valid states */ -static int cpu_non_c3; /* Index of lowest non-C3 state. */ -static int cpu_short_slp; /* Count of < 1us sleeps. */ -static u_int cpu_cx_stats[MAX_CX_STATES];/* Cx usage history. */ /* Values for sysctl. */ static struct sysctl_ctx_list acpi_cpu_sysctl_ctx; static struct sysctl_oid *acpi_cpu_sysctl_tree; +static int cpu_cx_generic; static int cpu_cx_lowest; -static char cpu_cx_supported[64]; static device_t *cpu_devices; static int cpu_ndevices; @@ -140,15 +144,17 @@ static int acpi_cpu_read_ivar(device_t dev, device_t child, int index, uintptr_t *result); static int acpi_cpu_shutdown(device_t dev); -static int acpi_cpu_cx_probe(struct acpi_cpu_softc *sc); +static void acpi_cpu_cx_probe(struct acpi_cpu_softc *sc); +static void acpi_cpu_generic_cx_probe(struct acpi_cpu_softc *sc); static int acpi_cpu_cx_cst(struct acpi_cpu_softc *sc); static void acpi_cpu_startup(void *arg); -static void acpi_cpu_startup_cx(void); +static void acpi_cpu_startup_cx(struct acpi_cpu_softc *sc); static void acpi_cpu_idle(void); static void acpi_cpu_notify(ACPI_HANDLE h, UINT32 notify, void *context); -static int acpi_cpu_quirks(struct acpi_cpu_softc *sc); +static int acpi_cpu_quirks(void); static int acpi_cpu_usage_sysctl(SYSCTL_HANDLER_ARGS); static int acpi_cpu_cx_lowest_sysctl(SYSCTL_HANDLER_ARGS); +static int acpi_cpu_global_cx_lowest_sysctl(SYSCTL_HANDLER_ARGS); static device_method_t acpi_cpu_methods[] = { /* Device interface */ @@ -255,9 +261,10 @@ struct acpi_softc *acpi_sc; ACPI_STATUS status; u_int features; - int cpu_id, drv_count, i; + int cpu_id, drv_count, i, dev_id; driver_t **drivers; uint32_t cap_set[3]; + char cpu_num[8]; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -265,6 +272,7 @@ sc->cpu_dev = dev; sc->cpu_handle = acpi_get_handle(dev); cpu_id = acpi_get_magic(dev); + dev_id = device_get_unit(dev); cpu_softc[cpu_id] = sc; pcpu_data = pcpu_find(cpu_id); pcpu_data->pc_device = dev; @@ -288,10 +296,29 @@ ACPI_DEBUG_PRINT((ACPI_DB_INFO, "acpi_cpu%d: P_BLK at %#x/%d\n", device_get_unit(dev), sc->cpu_p_blk, sc->cpu_p_blk_len)); + /* + * If this is the first cpu we attach, create and initialize the generic + * resources that will be used by all cpu devices. + */ acpi_sc = acpi_device_get_parent_softc(dev); - sysctl_ctx_init(&acpi_cpu_sysctl_ctx); - acpi_cpu_sysctl_tree = SYSCTL_ADD_NODE(&acpi_cpu_sysctl_ctx, - SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO, "cpu", + if (dev_id == 0) { + /* Assume we won't be using generic Cx mode by default */ + cpu_cx_generic = 0; + + /* Install root sysctl tree */ + sysctl_ctx_init(&acpi_cpu_sysctl_ctx); + acpi_cpu_sysctl_tree = SYSCTL_ADD_NODE(&acpi_cpu_sysctl_ctx, + SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO, "cpu", + CTLFLAG_RD, 0, ""); + + /* Queue post cpu-probing task handler */ + AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, NULL); + } + + snprintf(cpu_num, sizeof(cpu_num), "%d", dev_id); + sysctl_ctx_init(&sc->acpi_cpu_sysctl_ctx); + sc->acpi_cpu_sysctl_tree = SYSCTL_ADD_NODE(&sc->acpi_cpu_sysctl_ctx, + SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), OID_AUTO, cpu_num, CTLFLAG_RD, 0, ""); /* @@ -327,17 +354,8 @@ AcpiEvaluateObject(sc->cpu_handle, "_PDC", &arglist, NULL); } - /* - * Probe for Cx state support. If it isn't present, free up unused - * resources. - */ - if (acpi_cpu_cx_probe(sc) == 0) { - status = AcpiInstallNotifyHandler(sc->cpu_handle, ACPI_DEVICE_NOTIFY, - acpi_cpu_notify, sc); - if (device_get_unit(dev) == 0) - AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, NULL); - } else - sysctl_ctx_free(&acpi_cpu_sysctl_ctx); + /* Probe for Cx state support. */ + acpi_cpu_cx_probe(sc); /* Finally, call identify and probe/attach for child devices. */ bus_generic_probe(dev); @@ -440,7 +458,7 @@ bus_generic_shutdown(dev); /* Disable any entry to the idle function. */ - cpu_cx_count = 0; + cpu_disable_idle = 1; /* Signal and wait for all processors to exit acpi_cpu_idle(). */ smp_rendezvous(NULL, NULL, NULL, NULL); @@ -448,105 +466,101 @@ return_VALUE (0); } -static int +static void acpi_cpu_cx_probe(struct acpi_cpu_softc *sc) { - ACPI_GENERIC_ADDRESS gas; - struct acpi_cx *cx_ptr; - int error; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + /* Use initial sleep value of 1 sec. to start with lowest idle state. */ + sc->cpu_prev_sleep = 1000000; + sc->cpu_cx_lowest = 0; + /* - * Bus mastering arbitration control is needed to keep caches coherent - * while sleeping in C3. If it's not present but a working flush cache - * instruction is present, flush the caches before entering C3 instead. - * Otherwise, just disable C3 completely. + * Check for the ACPI 2.0 _CST sleep states object. If we can't find + * any, we'll revert to generic FADT/P_BLK Cx control method which will + * be handled by acpi_cpu_startup. We need to defer to after having + * probed all the cpus in the system before probing for generic Cx + * states as we may already have found cpus with valid _CST packages */ - if (AcpiGbl_FADT->V1_Pm2CntBlk == 0 || AcpiGbl_FADT->Pm2CntLen == 0) { - if (AcpiGbl_FADT->WbInvd && AcpiGbl_FADT->WbInvdFlush == 0) { - cpu_quirks |= CPU_QUIRK_NO_BM_CTRL; - ACPI_DEBUG_PRINT((ACPI_DB_INFO, - "acpi_cpu%d: no BM control, using flush cache method\n", - device_get_unit(sc->cpu_dev))); - } else { - cpu_quirks |= CPU_QUIRK_NO_C3; - ACPI_DEBUG_PRINT((ACPI_DB_INFO, - "acpi_cpu%d: no BM control, C3 not available\n", - device_get_unit(sc->cpu_dev))); - } + if (!cpu_cx_generic && acpi_cpu_cx_cst(sc) != 0) { + /* + * We were unable to find a _CST package for this cpu or there + * was an error parsing it. Switch back to generic mode. + */ + cpu_cx_generic = 1; + device_printf(sc->cpu_dev, "Switching to generic Cx mode\n"); } /* - * First, check for the ACPI 2.0 _CST sleep states object. - * If not usable, fall back to the P_BLK's P_LVL2 and P_LVL3. + * TODO: _CSD Package should be checked here. */ +} + +static void +acpi_cpu_generic_cx_probe(struct acpi_cpu_softc *sc) +{ + ACPI_GENERIC_ADDRESS gas; + struct acpi_cx *cx_ptr; + sc->cpu_cx_count = 0; - error = acpi_cpu_cx_cst(sc); - if (error != 0) { - cx_ptr = sc->cpu_cx_states; - - /* C1 has been required since just after ACPI 1.0 */ - cx_ptr->type = ACPI_STATE_C1; - cx_ptr->trans_lat = 0; - cpu_non_c3 = 0; - cx_ptr++; - sc->cpu_cx_count++; - - /* - * The spec says P_BLK must be 6 bytes long. However, some systems - * use it to indicate a fractional set of features present so we - * take 5 as C2. Some may also have a value of 7 to indicate - * another C3 but most use _CST for this (as required) and having - * "only" C1-C3 is not a hardship. - */ - if (sc->cpu_p_blk_len < 5) - goto done; + cx_ptr = sc->cpu_cx_states; + + /* Use initial sleep value of 1 sec. to start with lowest idle state. */ + sc->cpu_prev_sleep = 1000000; + + /* C1 has been required since just after ACPI 1.0 */ + cx_ptr->type = ACPI_STATE_C1; + cx_ptr->trans_lat = 0; + cx_ptr++; + sc->cpu_cx_count++; + + /* + * The spec says P_BLK must be 6 bytes long. However, some systems + * use it to indicate a fractional set of features present so we + * take 5 as C2. Some may also have a value of 7 to indicate + * another C3 but most use _CST for this (as required) and having + * "only" C1-C3 is not a hardship. + */ + if (sc->cpu_p_blk_len < 5) + return; - /* Validate and allocate resources for C2 (P_LVL2). */ - gas.AddressSpaceId = ACPI_ADR_SPACE_SYSTEM_IO; - gas.RegisterBitWidth = 8; - if (AcpiGbl_FADT->Plvl2Lat <= 100) { - gas.Address = sc->cpu_p_blk + 4; - acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &cpu_rid, &gas, - &cx_ptr->p_lvlx); - if (cx_ptr->p_lvlx != NULL) { - cpu_rid++; + /* Validate and allocate resources for C2 (P_LVL2). */ + gas.AddressSpaceId = ACPI_ADR_SPACE_SYSTEM_IO; + gas.RegisterBitWidth = 8; + if (AcpiGbl_FADT->Plvl2Lat <= 100) { + gas.Address = sc->cpu_p_blk + 4; + acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid, &gas, + &cx_ptr->p_lvlx, RF_SHAREABLE); + if (cx_ptr->p_lvlx != NULL) { + sc->cpu_rid++; cx_ptr->type = ACPI_STATE_C2; cx_ptr->trans_lat = AcpiGbl_FADT->Plvl2Lat; - cpu_non_c3 = 1; cx_ptr++; sc->cpu_cx_count++; - } } - if (sc->cpu_p_blk_len < 6) - goto done; + } + if (sc->cpu_p_blk_len < 6) + return; - /* Validate and allocate resources for C3 (P_LVL3). */ - if (AcpiGbl_FADT->Plvl3Lat <= 1000 && - (cpu_quirks & CPU_QUIRK_NO_C3) == 0) { - gas.Address = sc->cpu_p_blk + 5; - acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &cpu_rid, &gas, - &cx_ptr->p_lvlx); - if (cx_ptr->p_lvlx != NULL) { - cpu_rid++; + /* Validate and allocate resources for C3 (P_LVL3). */ + if (AcpiGbl_FADT->Plvl3Lat <= 1000) { + gas.Address = sc->cpu_p_blk + 5; + acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid, &gas, + &cx_ptr->p_lvlx, RF_SHAREABLE); + if (cx_ptr->p_lvlx != NULL) { + sc->cpu_rid++; cx_ptr->type = ACPI_STATE_C3; cx_ptr->trans_lat = AcpiGbl_FADT->Plvl3Lat; cx_ptr++; sc->cpu_cx_count++; - } } } -done: - /* If no valid registers were found, don't attach. */ - if (sc->cpu_cx_count == 0) - return (ENXIO); + /* Update the largest cx_count seen so far */ + if (sc->cpu_cx_count > cpu_cx_count) + cpu_cx_count = sc->cpu_cx_count; - /* Use initial sleep value of 1 sec. to start with lowest idle state. */ - sc->cpu_prev_sleep = 1000000; - - return (0); + return; } /* @@ -570,8 +584,10 @@ buf.Pointer = NULL; buf.Length = ACPI_ALLOCATE_BUFFER; status = AcpiEvaluateObject(sc->cpu_handle, "_CST", NULL, &buf); - if (ACPI_FAILURE(status)) + if (ACPI_FAILURE(status)) { + device_printf(sc->cpu_dev, "Unable to find _CST method\n"); return (ENXIO); + } /* _CST is a package with a count and at least one Cx package. */ top = (ACPI_OBJECT *)buf.Pointer; @@ -603,11 +619,13 @@ device_printf(sc->cpu_dev, "skipping invalid Cx state package\n"); continue; } + device_printf(sc->cpu_dev, "type = %d, trans_lat = %d, power = %d\n", + cx_ptr->type, cx_ptr->trans_lat, cx_ptr->power); /* Validate the state to see if we should use it. */ switch (cx_ptr->type) { case ACPI_STATE_C1: - cpu_non_c3 = i; + sc->cpu_non_c3 = i; cx_ptr++; sc->cpu_cx_count++; continue; @@ -618,7 +636,7 @@ device_get_unit(sc->cpu_dev), i)); continue; } - cpu_non_c3 = i; + sc->cpu_non_c3 = i; break; case ACPI_STATE_C3: default: @@ -642,10 +660,31 @@ #endif /* Allocate the control register for C2 or C3. */ - acpi_PkgGas(sc->cpu_dev, pkg, 0, &cx_ptr->res_type, &cpu_rid, - &cx_ptr->p_lvlx); + { + ACPI_GENERIC_ADDRESS gas; + ACPI_OBJECT *obj; + + obj = &pkg->Package.Elements[0]; + if (obj == NULL || obj->Type != ACPI_TYPE_BUFFER || + obj->Buffer.Length < sizeof(ACPI_GENERIC_ADDRESS) + 3) + { + device_printf(sc->cpu_dev, "Invalid Gas\n"); + } + else + { + memcpy(&gas, obj->Buffer.Pointer + 3, sizeof(gas)); + device_printf(sc->cpu_dev, "gas = %08x\n", (uint32_t) obj->Buffer.Pointer); + device_printf(sc->cpu_dev, "AddressSpaceId = %02x\n", gas.AddressSpaceId); + device_printf(sc->cpu_dev, "RegisterBitWidth = %02x\n", gas.RegisterBitWidth); + device_printf(sc->cpu_dev, "RegisterBidOffset = %02x\n", gas.RegisterBitOffset); + device_printf(sc->cpu_dev, "Address = %016llx\n", gas.Address); + } + } + + acpi_PkgGas(sc->cpu_dev, pkg, 0, &cx_ptr->res_type, &sc->cpu_rid, + &cx_ptr->p_lvlx, RF_SHAREABLE); if (cx_ptr->p_lvlx) { - cpu_rid++; + sc->cpu_rid++; ACPI_DEBUG_PRINT((ACPI_DB_INFO, "acpi_cpu%d: Got C%d - %d latency\n", device_get_unit(sc->cpu_dev), cx_ptr->type, @@ -666,81 +705,121 @@ acpi_cpu_startup(void *arg) { struct acpi_cpu_softc *sc; - int count, i; + int i; /* Get set of CPU devices */ devclass_get_devices(acpi_cpu_devclass, &cpu_devices, &cpu_ndevices); - /* Check for quirks via the first CPU device. */ - sc = device_get_softc(cpu_devices[0]); - acpi_cpu_quirks(sc); - /* - * Make sure all the processors' Cx counts match. We should probably - * also check the contents of each. However, no known systems have - * non-matching Cx counts so we'll deal with this later. + * Setup any quirks that might necessary now that we have probed + * all the CPUs */ - count = MAX_CX_STATES; - for (i = 0; i < cpu_ndevices; i++) { - sc = device_get_softc(cpu_devices[i]); - count = min(sc->cpu_cx_count, count); + acpi_cpu_quirks(); + + cpu_cx_count = 0; + if (cpu_cx_generic) { + /* + * We are using generic Cx mode, probe for available Cx states + * for all processors. + */ + for (i = 0; i < cpu_ndevices; i++) { + sc = device_get_softc(cpu_devices[i]); + acpi_cpu_generic_cx_probe(sc); + } + + /* + * Find the highest Cx state common to all CPUs + * in the system, taking quirks into account. + */ + for (i = 0; i < cpu_ndevices; i++) { + sc = device_get_softc(cpu_devices[i]); + if (sc->cpu_cx_count < cpu_cx_count) + cpu_cx_count = sc->cpu_cx_count; + } + } else { + /* + * We are using _CST mode, remove C3 state if necessary. + * Update the largest Cx state supported in the global cpu_cx_count. + * It will be used in the Globa Cx sysctl handler. + * As we now know for sure that we will be using _CST mode + * install our notify handler. + */ + for (i = 0; i < cpu_ndevices; i++) { + sc = device_get_softc(cpu_devices[i]); + if (cpu_quirks && CPU_QUIRK_NO_C3) { + sc->cpu_cx_count = sc->cpu_non_c3 + 1; + } + if (sc->cpu_cx_count > cpu_cx_count) + cpu_cx_count = sc->cpu_cx_count; + AcpiInstallNotifyHandler(sc->cpu_handle, + ACPI_DEVICE_NOTIFY, acpi_cpu_notify, sc); + } } - cpu_cx_count = count; /* Perform Cx final initialization. */ - sc = device_get_softc(cpu_devices[0]); - if (cpu_cx_count > 0) - acpi_cpu_startup_cx(); + for (i = 0; i < cpu_ndevices; i++) { + sc = device_get_softc(cpu_devices[i]); + acpi_cpu_startup_cx(sc); + } + + /* Add a sysctl handler to handle global Cx lowest setting */ + SYSCTL_ADD_PROC(&acpi_cpu_sysctl_ctx, + SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), + OID_AUTO, "cx_lowest", CTLTYPE_STRING | CTLFLAG_RW, + NULL, 0, acpi_cpu_global_cx_lowest_sysctl, "A", + "Global lowest Cx sleep state to use"); + + /* Take over idling from cpu_idle_default(). */ + cpu_cx_lowest = 0; + cpu_disable_idle = 0; + cpu_idle_hook = acpi_cpu_idle; } static void -acpi_cpu_startup_cx() +acpi_cpu_startup_cx(struct acpi_cpu_softc *sc) { - struct acpi_cpu_softc *sc; struct sbuf sb; int i; /* - * Set up the list of Cx states, eliminating C3 states by truncating - * cpu_cx_count if quirks indicate C3 is not usable. + * Set up the list of Cx states */ - sc = device_get_softc(cpu_devices[0]); - sbuf_new(&sb, cpu_cx_supported, sizeof(cpu_cx_supported), SBUF_FIXEDLEN); - for (i = 0; i < cpu_cx_count; i++) { - if ((cpu_quirks & CPU_QUIRK_NO_C3) == 0 || - sc->cpu_cx_states[i].type != ACPI_STATE_C3) - sbuf_printf(&sb, "C%d/%d ", i + 1, sc->cpu_cx_states[i].trans_lat); - else - cpu_cx_count = i; + sc->cpu_non_c3 = 0; + sbuf_new(&sb, sc->cpu_cx_supported, sizeof(sc->cpu_cx_supported), + SBUF_FIXEDLEN); + for (i = 0; i < sc->cpu_cx_count; i++) { + sbuf_printf(&sb, "C%d/%d ", i + 1, sc->cpu_cx_states[i].trans_lat); + if (sc->cpu_cx_states[i].type < ACPI_STATE_C3) + sc->cpu_non_c3 = i; } + sbuf_trim(&sb); sbuf_finish(&sb); - SYSCTL_ADD_STRING(&acpi_cpu_sysctl_ctx, - SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), - OID_AUTO, "cx_supported", CTLFLAG_RD, cpu_cx_supported, - 0, "Cx/microsecond values for supported Cx states"); - SYSCTL_ADD_PROC(&acpi_cpu_sysctl_ctx, - SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), + SYSCTL_ADD_STRING(&sc->acpi_cpu_sysctl_ctx, + SYSCTL_CHILDREN(sc->acpi_cpu_sysctl_tree), + OID_AUTO, "cx_supported", CTLFLAG_RD, + sc->cpu_cx_supported, 0, + "Cx/microsecond values for supported Cx states"); + SYSCTL_ADD_PROC(&sc->acpi_cpu_sysctl_ctx, + SYSCTL_CHILDREN(sc->acpi_cpu_sysctl_tree), OID_AUTO, "cx_lowest", CTLTYPE_STRING | CTLFLAG_RW, - NULL, 0, acpi_cpu_cx_lowest_sysctl, "A", + (void *)sc, 0, acpi_cpu_cx_lowest_sysctl, "A", "lowest Cx sleep state to use"); - SYSCTL_ADD_PROC(&acpi_cpu_sysctl_ctx, - SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), + SYSCTL_ADD_PROC(&sc->acpi_cpu_sysctl_ctx, + SYSCTL_CHILDREN(sc->acpi_cpu_sysctl_tree), OID_AUTO, "cx_usage", CTLTYPE_STRING | CTLFLAG_RD, - NULL, 0, acpi_cpu_usage_sysctl, "A", + (void *)sc, 0, acpi_cpu_usage_sysctl, "A", "percent usage for each Cx state"); #ifdef notyet /* Signal platform that we can handle _CST notification. */ - if (cpu_cst_cnt != 0) { + if (!cpu_cx_generic) { ACPI_LOCK(acpi); AcpiOsWritePort(cpu_smi_cmd, cpu_cst_cnt, 8); ACPI_UNLOCK(acpi); } #endif - /* Take over idling from cpu_idle_default(). */ - cpu_idle_hook = acpi_cpu_idle; } /* @@ -758,7 +837,7 @@ int bm_active, cx_next_idx, i; /* If disabled, return immediately. */ - if (cpu_cx_count == 0) { + if (cpu_disable_idle != 0) { ACPI_ENABLE_IRQS(); return; } @@ -779,28 +858,34 @@ * find the lowest state that has a latency less than or equal to * the length of our last sleep. */ - cx_next_idx = cpu_cx_lowest; + cx_next_idx = sc->cpu_cx_lowest; if (sc->cpu_prev_sleep < 100) { /* * If we sleep too short all the time, this system may not implement * C2/3 correctly (i.e. reads return immediately). In this case, * back off and use the next higher level. + * It seems that when you have a dual core cpu (like the Intel Core Duo) + * that both cores will get out of C3 state as soon as one of them + * requires it. This breaks the sleep detection logic as the sleep + * counter is local to each cpu. Disable the sleep logic for now as a + * workaround if there's more than one CPU. The right fix would probably + * be to add quirks for system that don't really support C3 state. */ - if (sc->cpu_prev_sleep <= 1) { - cpu_short_slp++; - if (cpu_short_slp == 1000 && cpu_cx_lowest != 0) { - if (cpu_non_c3 == cpu_cx_lowest && cpu_non_c3 != 0) - cpu_non_c3--; - cpu_cx_lowest--; - cpu_short_slp = 0; + if (mp_ncpus < 2 && sc->cpu_prev_sleep <= 1) { + sc->cpu_short_slp++; + if (sc->cpu_short_slp == 1000 && sc->cpu_cx_lowest != 0) { + if (sc->cpu_non_c3 == sc->cpu_cx_lowest && sc->cpu_non_c3 != 0) + sc->cpu_non_c3--; + sc->cpu_cx_lowest--; + sc->cpu_short_slp = 0; device_printf(sc->cpu_dev, "too many short sleeps, backing off to C%d\n", - cpu_cx_lowest + 1); + sc->cpu_cx_lowest + 1); } } else - cpu_short_slp = 0; + sc->cpu_short_slp = 0; - for (i = cpu_cx_lowest; i >= 0; i--) + for (i = sc->cpu_cx_lowest; i >= 0; i--) if (sc->cpu_cx_states[i].trans_lat <= sc->cpu_prev_sleep) { cx_next_idx = i; break; @@ -819,13 +904,13 @@ if (bm_active != 0) { AcpiSetRegister(ACPI_BITREG_BUS_MASTER_STATUS, 1, ACPI_MTX_DO_NOT_LOCK); - cx_next_idx = min(cx_next_idx, cpu_non_c3); + cx_next_idx = min(cx_next_idx, sc->cpu_non_c3); } } /* Select the next state and update statistics. */ cx_next = &sc->cpu_cx_states[cx_next_idx]; - cpu_cx_stats[cx_next_idx]++; + sc->cpu_cx_stats[cx_next_idx]++; KASSERT(cx_next->type != ACPI_STATE_C0, ("acpi_cpu_idle: C0 sleep")); /* @@ -901,15 +986,35 @@ } static int -acpi_cpu_quirks(struct acpi_cpu_softc *sc) +acpi_cpu_quirks(void) { device_t acpi_dev; /* - * C3 on multiple CPUs requires using the expensive flush cache - * instruction. + * Bus mastering arbitration control is needed to keep caches coherent + * while sleeping in C3. If it's not present but a working flush cache + * instruction is present, flush the caches before entering C3 instead. + * Otherwise, just disable C3 completely. */ - if (mp_ncpus > 1) + if (AcpiGbl_FADT->V1_Pm2CntBlk == 0 || AcpiGbl_FADT->Pm2CntLen == 0) { + if (AcpiGbl_FADT->WbInvd && AcpiGbl_FADT->WbInvdFlush == 0) { + cpu_quirks |= CPU_QUIRK_NO_BM_CTRL; + ACPI_DEBUG_PRINT((ACPI_DB_INFO, + "acpi_cpu%d: no BM control, using flush cache method\n", + device_get_unit(sc->cpu_dev))); + } else { + cpu_quirks |= CPU_QUIRK_NO_C3; + ACPI_DEBUG_PRINT((ACPI_DB_INFO, + "acpi_cpu%d: no BM control, C3 not available\n", + device_get_unit(sc->cpu_dev))); + } + } + + /* + * If we are using generic Cx mode, C3 on multiple CPUs requires using + * the expensive flush cache instruction. + */ + if (cpu_cx_generic && mp_ncpus > 1) cpu_quirks |= CPU_QUIRK_NO_BM_CTRL; /* Look for various quirks of the PIIX4 part. */ @@ -943,18 +1048,20 @@ static int acpi_cpu_usage_sysctl(SYSCTL_HANDLER_ARGS) { + struct acpi_cpu_softc *sc; struct sbuf sb; char buf[128]; int i; uintmax_t fract, sum, whole; + sc = (struct acpi_cpu_softc *) arg1; sum = 0; - for (i = 0; i < cpu_cx_count; i++) - sum += cpu_cx_stats[i]; + for (i = 0; i < sc->cpu_cx_count; i++) + sum += sc->cpu_cx_stats[i]; sbuf_new(&sb, buf, sizeof(buf), SBUF_FIXEDLEN); - for (i = 0; i < cpu_cx_count; i++) { + for (i = 0; i < sc->cpu_cx_count; i++) { if (sum > 0) { - whole = (uintmax_t)cpu_cx_stats[i] * 100; + whole = (uintmax_t)sc->cpu_cx_stats[i] * 100; fract = (whole % sum) * 100; sbuf_printf(&sb, "%u.%02u%% ", (u_int)(whole / sum), (u_int)(fract / sum)); @@ -976,32 +1083,74 @@ char state[8]; int val, error, i; - sc = device_get_softc(cpu_devices[0]); - snprintf(state, sizeof(state), "C%d", cpu_cx_lowest + 1); + sc = (struct acpi_cpu_softc *) arg1; + snprintf(state, sizeof(state), "C%d", sc->cpu_cx_lowest + 1); error = sysctl_handle_string(oidp, state, sizeof(state), req); if (error != 0 || req->newptr == NULL) return (error); if (strlen(state) < 2 || toupper(state[0]) != 'C') return (EINVAL); val = (int) strtol(state + 1, NULL, 10) - 1; - if (val < 0 || val > cpu_cx_count - 1) + if (val < 0 || val > sc->cpu_cx_count - 1) return (EINVAL); ACPI_SERIAL_BEGIN(cpu); - cpu_cx_lowest = val; + sc->cpu_cx_lowest = val; /* If not disabling, cache the new lowest non-C3 state. */ - cpu_non_c3 = 0; - for (i = cpu_cx_lowest; i >= 0; i--) { + sc->cpu_non_c3 = 0; + for (i = sc->cpu_cx_lowest; i >= 0; i--) { if (sc->cpu_cx_states[i].type < ACPI_STATE_C3) { - cpu_non_c3 = i; + sc->cpu_non_c3 = i; break; } } /* Reset the statistics counters. */ - bzero(cpu_cx_stats, sizeof(cpu_cx_stats)); + bzero(sc->cpu_cx_stats, sizeof(sc->cpu_cx_stats)); + ACPI_SERIAL_END(cpu); + + return (0); +} + +static int +acpi_cpu_global_cx_lowest_sysctl(SYSCTL_HANDLER_ARGS) +{ + struct acpi_cpu_softc *sc; + char state[8]; + int val, error, i, j; + + snprintf(state, sizeof(state), "C%d", cpu_cx_lowest + 1); + error = sysctl_handle_string(oidp, state, sizeof(state), req); + if (error != 0 || req->newptr == NULL) + return (error); + if (strlen(state) < 2 || toupper(state[0]) != 'C') + return (EINVAL); + val = (int) strtol(state + 1, NULL, 10) - 1; + if (val < 0 || val > cpu_cx_count - 1) + return (EINVAL); + + cpu_cx_lowest = val; + + /* + * Update the new lowest useable Cx state for all CPUs + */ + ACPI_SERIAL_BEGIN(cpu); + for (i = 0; i < cpu_ndevices; i++) { + sc = device_get_softc(cpu_devices[i]); + sc->cpu_cx_lowest = cpu_cx_lowest; + sc->cpu_non_c3 = 0; + for (j = sc->cpu_cx_lowest; j >= 0; j++) { + if (sc->cpu_cx_states[i].type < ACPI_STATE_C3) { + sc->cpu_non_c3 = i; + break; + } + } + /* Reset the statistics counters. */ + bzero(sc->cpu_cx_stats, sizeof(sc->cpu_cx_stats)); + } ACPI_SERIAL_END(cpu); return (0); } + Index: sys/dev/acpica/acpi_package.c =================================================================== RCS file: /home/FreeBSD/ncvs/src/sys/dev/acpica/acpi_package.c,v retrieving revision 1.8 diff -u -r1.8 acpi_package.c --- sys/dev/acpica/acpi_package.c 11 Sep 2005 18:39:01 -0000 1.8 +++ sys/dev/acpica/acpi_package.c 7 Jun 2006 20:50:37 -0000 @@ -104,7 +104,7 @@ int acpi_PkgGas(device_t dev, ACPI_OBJECT *res, int idx, int *type, int *rid, - struct resource **dst) + struct resource **dst, u_int flags) { ACPI_GENERIC_ADDRESS gas; ACPI_OBJECT *obj; @@ -116,7 +116,7 @@ memcpy(&gas, obj->Buffer.Pointer + 3, sizeof(gas)); - return (acpi_bus_alloc_gas(dev, type, rid, &gas, dst)); + return (acpi_bus_alloc_gas(dev, type, rid, &gas, dst, flags)); } ACPI_HANDLE Index: sys/dev/acpica/acpi_perf.c =================================================================== RCS file: /home/FreeBSD/ncvs/src/sys/dev/acpica/acpi_perf.c,v retrieving revision 1.23 diff -u -r1.23 acpi_perf.c --- sys/dev/acpica/acpi_perf.c 12 Dec 2005 11:15:20 -0000 1.23 +++ sys/dev/acpica/acpi_perf.c 7 Jun 2006 20:50:37 -0000 @@ -191,7 +191,7 @@ pkg = (ACPI_OBJECT *)buf.Pointer; if (ACPI_PKG_VALID(pkg, 2)) { rid = 0; - error = acpi_PkgGas(dev, pkg, 0, &type, &rid, &res); + error = acpi_PkgGas(dev, pkg, 0, &type, &rid, &res, 0); switch (error) { case 0: bus_release_resource(dev, type, rid, res); @@ -323,7 +323,7 @@ } error = acpi_PkgGas(sc->dev, pkg, 0, &sc->perf_ctrl_type, &sc->px_rid, - &sc->perf_ctrl); + &sc->perf_ctrl, 0); if (error) { /* * If the register is of type FFixedHW, we can only return @@ -339,7 +339,7 @@ sc->px_rid++; error = acpi_PkgGas(sc->dev, pkg, 1, &sc->perf_sts_type, &sc->px_rid, - &sc->perf_status); + &sc->perf_status, 0); if (error) { if (error == EOPNOTSUPP) { sc->info_only = TRUE; Index: sys/dev/acpica/acpi_throttle.c =================================================================== RCS file: /home/FreeBSD/ncvs/src/sys/dev/acpica/acpi_throttle.c,v retrieving revision 1.9 diff -u -r1.9 acpi_throttle.c --- sys/dev/acpica/acpi_throttle.c 21 Feb 2006 03:15:26 -0000 1.9 +++ sys/dev/acpica/acpi_throttle.c 7 Jun 2006 20:50:37 -0000 @@ -278,7 +278,7 @@ } memcpy(&gas, obj.Buffer.Pointer + 3, sizeof(gas)); acpi_bus_alloc_gas(sc->cpu_dev, &sc->cpu_p_type, &thr_rid, - &gas, &sc->cpu_p_cnt); + &gas, &sc->cpu_p_cnt, 0); if (sc->cpu_p_cnt != NULL && bootverbose) { device_printf(sc->cpu_dev, "P_CNT from _PTC %#jx\n", gas.Address); @@ -298,7 +298,7 @@ gas.AddressSpaceId = ACPI_ADR_SPACE_SYSTEM_IO; gas.RegisterBitWidth = 32; acpi_bus_alloc_gas(sc->cpu_dev, &sc->cpu_p_type, &thr_rid, - &gas, &sc->cpu_p_cnt); + &gas, &sc->cpu_p_cnt, 0); if (sc->cpu_p_cnt != NULL) { if (bootverbose) device_printf(sc->cpu_dev, Index: sys/dev/acpica/acpivar.h =================================================================== RCS file: /home/FreeBSD/ncvs/src/sys/dev/acpica/acpivar.h,v retrieving revision 1.100 diff -u -r1.100 acpivar.h --- sys/dev/acpica/acpivar.h 6 Dec 2005 14:47:28 -0000 1.100 +++ sys/dev/acpica/acpivar.h 7 Jun 2006 20:50:37 -0000 @@ -311,7 +311,8 @@ void acpi_UserNotify(const char *subsystem, ACPI_HANDLE h, uint8_t notify); int acpi_bus_alloc_gas(device_t dev, int *type, int *rid, - ACPI_GENERIC_ADDRESS *gas, struct resource **res); + ACPI_GENERIC_ADDRESS *gas, struct resource **res, + u_int flags); struct acpi_parse_resource_set { void (*set_init)(device_t dev, void *arg, void **context); @@ -417,7 +418,7 @@ int acpi_PkgInt32(ACPI_OBJECT *res, int idx, uint32_t *dst); int acpi_PkgStr(ACPI_OBJECT *res, int idx, void *dst, size_t size); int acpi_PkgGas(device_t dev, ACPI_OBJECT *res, int idx, int *type, - int *rid, struct resource **dst); + int *rid, struct resource **dst, u_int flags); ACPI_HANDLE acpi_GetReference(ACPI_HANDLE scope, ACPI_OBJECT *obj); /* Default number of task queue threads to start. */ --------------020609000000060304070901-- From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 8 02:10:22 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71B0716A64D for ; Thu, 8 Jun 2006 00:03:15 +0000 (UTC) (envelope-from sepotvin@videotron.ca) Received: from tomts33-srv.bellnexxia.net (tomts33.bellnexxia.net [209.226.175.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CAB243D4C for ; Thu, 8 Jun 2006 00:03:12 +0000 (GMT) (envelope-from sepotvin@videotron.ca) Received: from mail.telcobridges.com ([67.70.237.76]) by tomts33-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060608000310.PRMU13120.tomts33-srv.bellnexxia.net@mail.telcobridges.com> for ; Wed, 7 Jun 2006 20:03:10 -0400 Received: from [192.168.0.107] (modemcable237.137-80-70.mc.videotron.ca [70.80.137.237]) (authenticated bits=0) by mail.telcobridges.com (8.13.3/8.13.3) with ESMTP id k58038V9004756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Jun 2006 20:03:09 -0400 (EDT) (envelope-from sepotvin@videotron.ca) Message-ID: <44876932.9000108@videotron.ca> Date: Wed, 07 Jun 2006 20:02:58 -0400 From: "Stephane E. Potvin" User-Agent: Thunderbird 1.5.0.4 (X11/20060605) MIME-Version: 1.0 References: <44874358.6050608@videotron.ca> In-Reply-To: <44874358.6050608@videotron.ca> Content-Type: multipart/mixed; boundary="------------080305070803060308000602" Cc: freebsd-acpi@FreeBSD.org Subject: Re: [patch] Support for asymetrical per-cpu Cx states 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, 08 Jun 2006 02:10:24 -0000 This is a multi-part message in MIME format. --------------080305070803060308000602 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Stephane E. Potvin wrote: > What started as a quick check why my laptop was not giving me Cx states > higher than C1 turned out in a major rework of the way the acpi_cpu > driver works. > > The attached patch makes the following modifications to the driver: > > - Support for asymetrical and per-cpu Cx states. This is done by parsing > the _CST packages for each cpu and tracking all the states individually, > on a per-cpu basis. > > - Support to revert to generic FADT/P_BLK based Cx control if the _CST > package are not present on all cpus. In that case, the new driver will > still support per-cpu Cx state handling. The driver will determine the > highest Cx level that can be supported by all the cpus and configure the > available Cx state based on that. > > - Fixed the case where multiple cpus in the system share the same > registers for Cx state handling. To do that, I added a new flag > parameter to the acpi_PkgGas and acpi_bus_alloc_gas functions that > enable the caller to add the RF_SHAREABLE flag. This will probably fix > the case where enabling the HT core would remove all Cx states (except > C1), but I have no mean to check it at this time. I've not added this > flag to the other callers in the tree but I guess that some of them > could use this flag when multiple cpus are present. > > - I also found out that for Core Duo cpus, both cores seems to be taken > out of C3 state when any one of the cores need to transition out. This > broke the short sleep detection logic. I disabled it if there are more > than one cpu in the system for now as it fixed it in my case. I guess > that proper quirks handling will be required to fix this for known non > working systems. > > - Added support to control cx_lowest on a per-cpu basis. I also > implemented a generic cx_lowest to enable changing cx_lowest for all > cpus with a single sysctl and for backward compatibility. The value > returned on read is kind of meaningless (is there an easy way to have a > write-only sysctl?) I've not done the same for the cx_supported case as > I was not sure which way to handle it in case all supported Cx states > were not symmetrical. Sample output for the new sysctl: > > hw.acpi.cpu.0.cx_supported: C1/1 C2/1 C3/57 > hw.acpi.cpu.0.cx_lowest: C3 > hw.acpi.cpu.0.cx_usage: 0.00% 43.16% 56.83% > hw.acpi.cpu.1.cx_supported: C1/1 C2/1 C3/57 > hw.acpi.cpu.1.cx_lowest: C3 > hw.acpi.cpu.1.cx_usage: 0.00% 45.65% 54.34% > hw.acpi.cpu.cx_lowest: C3 > > I would appreciate any feedback, positive or negative, on this :) I inadvertently attached a version of the patch that still has some debugging cruft in my previous message. Here's an updated version that should be more clean. Steph --------------080305070803060308000602 Content-Type: text/x-patch; name="acpi_cpu.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_cpu.diff" Index: etc/rc.d/power_profile =================================================================== RCS file: /home/FreeBSD/ncvs/src/etc/rc.d/power_profile,v retrieving revision 1.9 diff -u -r1.9 power_profile --- etc/rc.d/power_profile 21 Dec 2005 01:19:20 -0000 1.9 +++ etc/rc.d/power_profile 7 Jun 2006 21:16:12 -0000 @@ -76,7 +76,7 @@ # Set the various sysctls based on the profile's values. node="hw.acpi.cpu.cx_lowest" highest_value="C1" -lowest_value="`(sysctl -n hw.acpi.cpu.cx_supported | \ +lowest_value="`(sysctl -n hw.acpi.cpu.0.cx_supported | \ awk '{ print "C" split($0, a) }' -) 2> /dev/null`" eval value=\$${profile}_cx_lowest sysctl_set Index: sys/dev/acpica/acpi.c =================================================================== RCS file: /home/FreeBSD/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.224 diff -u -r1.224 acpi.c --- sys/dev/acpica/acpi.c 16 May 2006 14:36:22 -0000 1.224 +++ sys/dev/acpica/acpi.c 7 Jun 2006 20:50:37 -0000 @@ -1106,7 +1106,7 @@ /* Allocate an IO port or memory resource, given its GAS. */ int acpi_bus_alloc_gas(device_t dev, int *type, int *rid, ACPI_GENERIC_ADDRESS *gas, - struct resource **res) + struct resource **res, u_int flags) { int error, res_type; @@ -1139,7 +1139,7 @@ bus_set_resource(dev, res_type, *rid, gas->Address, gas->RegisterBitWidth / 8); - *res = bus_alloc_resource_any(dev, res_type, rid, RF_ACTIVE); + *res = bus_alloc_resource_any(dev, res_type, rid, RF_ACTIVE | flags); if (*res != NULL) { *type = res_type; error = 0; Index: sys/dev/acpica/acpi_cpu.c =================================================================== RCS file: /home/FreeBSD/ncvs/src/sys/dev/acpica/acpi_cpu.c,v retrieving revision 1.59 diff -u -r1.59 acpi_cpu.c --- sys/dev/acpica/acpi_cpu.c 25 Oct 2005 21:15:47 -0000 1.59 +++ sys/dev/acpica/acpi_cpu.c 7 Jun 2006 23:58:14 -0000 @@ -51,9 +51,6 @@ /* * Support for ACPI Processor devices, including C[1-3] sleep states. - * - * TODO: implement scans of all CPUs to be sure all Cx states are - * equivalent. */ /* Hooks for the ACPI CA debugging infrastructure */ @@ -80,6 +77,16 @@ int cpu_cx_count; /* Number of valid Cx states. */ int cpu_prev_sleep;/* Last idle sleep duration. */ int cpu_features; /* Child driver supported features. */ + /* Runtime state. */ + int cpu_non_c3; /* Index of lowest non-C3 state. */ + int cpu_short_slp; /* Count of < 1us sleeps. */ + u_int cpu_cx_stats[MAX_CX_STATES];/* Cx usage history. */ + /* Values for sysctl. */ + struct sysctl_ctx_list acpi_cpu_sysctl_ctx; + struct sysctl_oid *acpi_cpu_sysctl_tree; + int cpu_cx_lowest; + char cpu_cx_supported[64]; + int cpu_rid; }; struct acpi_cpu_device { @@ -110,20 +117,17 @@ /* Platform hardware resource information. */ static uint32_t cpu_smi_cmd; /* Value to write to SMI_CMD. */ static uint8_t cpu_cst_cnt; /* Indicate we are _CST aware. */ -static int cpu_rid; /* Driver-wide resource id. */ static int cpu_quirks; /* Indicate any hardware bugs. */ /* Runtime state. */ +static int cpu_disable_idle; /* Disable idle function */ static int cpu_cx_count; /* Number of valid states */ -static int cpu_non_c3; /* Index of lowest non-C3 state. */ -static int cpu_short_slp; /* Count of < 1us sleeps. */ -static u_int cpu_cx_stats[MAX_CX_STATES];/* Cx usage history. */ /* Values for sysctl. */ static struct sysctl_ctx_list acpi_cpu_sysctl_ctx; static struct sysctl_oid *acpi_cpu_sysctl_tree; +static int cpu_cx_generic; static int cpu_cx_lowest; -static char cpu_cx_supported[64]; static device_t *cpu_devices; static int cpu_ndevices; @@ -140,15 +144,17 @@ static int acpi_cpu_read_ivar(device_t dev, device_t child, int index, uintptr_t *result); static int acpi_cpu_shutdown(device_t dev); -static int acpi_cpu_cx_probe(struct acpi_cpu_softc *sc); +static void acpi_cpu_cx_probe(struct acpi_cpu_softc *sc); +static void acpi_cpu_generic_cx_probe(struct acpi_cpu_softc *sc); static int acpi_cpu_cx_cst(struct acpi_cpu_softc *sc); static void acpi_cpu_startup(void *arg); -static void acpi_cpu_startup_cx(void); +static void acpi_cpu_startup_cx(struct acpi_cpu_softc *sc); static void acpi_cpu_idle(void); static void acpi_cpu_notify(ACPI_HANDLE h, UINT32 notify, void *context); -static int acpi_cpu_quirks(struct acpi_cpu_softc *sc); +static int acpi_cpu_quirks(void); static int acpi_cpu_usage_sysctl(SYSCTL_HANDLER_ARGS); static int acpi_cpu_cx_lowest_sysctl(SYSCTL_HANDLER_ARGS); +static int acpi_cpu_global_cx_lowest_sysctl(SYSCTL_HANDLER_ARGS); static device_method_t acpi_cpu_methods[] = { /* Device interface */ @@ -255,9 +261,10 @@ struct acpi_softc *acpi_sc; ACPI_STATUS status; u_int features; - int cpu_id, drv_count, i; + int cpu_id, drv_count, i, dev_id; driver_t **drivers; uint32_t cap_set[3]; + char cpu_num[8]; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -265,6 +272,7 @@ sc->cpu_dev = dev; sc->cpu_handle = acpi_get_handle(dev); cpu_id = acpi_get_magic(dev); + dev_id = device_get_unit(dev); cpu_softc[cpu_id] = sc; pcpu_data = pcpu_find(cpu_id); pcpu_data->pc_device = dev; @@ -288,10 +296,29 @@ ACPI_DEBUG_PRINT((ACPI_DB_INFO, "acpi_cpu%d: P_BLK at %#x/%d\n", device_get_unit(dev), sc->cpu_p_blk, sc->cpu_p_blk_len)); + /* + * If this is the first cpu we attach, create and initialize the generic + * resources that will be used by all cpu devices. + */ acpi_sc = acpi_device_get_parent_softc(dev); - sysctl_ctx_init(&acpi_cpu_sysctl_ctx); - acpi_cpu_sysctl_tree = SYSCTL_ADD_NODE(&acpi_cpu_sysctl_ctx, - SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO, "cpu", + if (dev_id == 0) { + /* Assume we won't be using generic Cx mode by default */ + cpu_cx_generic = 0; + + /* Install root sysctl tree */ + sysctl_ctx_init(&acpi_cpu_sysctl_ctx); + acpi_cpu_sysctl_tree = SYSCTL_ADD_NODE(&acpi_cpu_sysctl_ctx, + SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO, "cpu", + CTLFLAG_RD, 0, ""); + + /* Queue post cpu-probing task handler */ + AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, NULL); + } + + snprintf(cpu_num, sizeof(cpu_num), "%d", dev_id); + sysctl_ctx_init(&sc->acpi_cpu_sysctl_ctx); + sc->acpi_cpu_sysctl_tree = SYSCTL_ADD_NODE(&sc->acpi_cpu_sysctl_ctx, + SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), OID_AUTO, cpu_num, CTLFLAG_RD, 0, ""); /* @@ -327,17 +354,8 @@ AcpiEvaluateObject(sc->cpu_handle, "_PDC", &arglist, NULL); } - /* - * Probe for Cx state support. If it isn't present, free up unused - * resources. - */ - if (acpi_cpu_cx_probe(sc) == 0) { - status = AcpiInstallNotifyHandler(sc->cpu_handle, ACPI_DEVICE_NOTIFY, - acpi_cpu_notify, sc); - if (device_get_unit(dev) == 0) - AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, NULL); - } else - sysctl_ctx_free(&acpi_cpu_sysctl_ctx); + /* Probe for Cx state support. */ + acpi_cpu_cx_probe(sc); /* Finally, call identify and probe/attach for child devices. */ bus_generic_probe(dev); @@ -440,7 +458,7 @@ bus_generic_shutdown(dev); /* Disable any entry to the idle function. */ - cpu_cx_count = 0; + cpu_disable_idle = 1; /* Signal and wait for all processors to exit acpi_cpu_idle(). */ smp_rendezvous(NULL, NULL, NULL, NULL); @@ -448,105 +466,101 @@ return_VALUE (0); } -static int +static void acpi_cpu_cx_probe(struct acpi_cpu_softc *sc) { - ACPI_GENERIC_ADDRESS gas; - struct acpi_cx *cx_ptr; - int error; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + /* Use initial sleep value of 1 sec. to start with lowest idle state. */ + sc->cpu_prev_sleep = 1000000; + sc->cpu_cx_lowest = 0; + /* - * Bus mastering arbitration control is needed to keep caches coherent - * while sleeping in C3. If it's not present but a working flush cache - * instruction is present, flush the caches before entering C3 instead. - * Otherwise, just disable C3 completely. + * Check for the ACPI 2.0 _CST sleep states object. If we can't find + * any, we'll revert to generic FADT/P_BLK Cx control method which will + * be handled by acpi_cpu_startup. We need to defer to after having + * probed all the cpus in the system before probing for generic Cx + * states as we may already have found cpus with valid _CST packages */ - if (AcpiGbl_FADT->V1_Pm2CntBlk == 0 || AcpiGbl_FADT->Pm2CntLen == 0) { - if (AcpiGbl_FADT->WbInvd && AcpiGbl_FADT->WbInvdFlush == 0) { - cpu_quirks |= CPU_QUIRK_NO_BM_CTRL; - ACPI_DEBUG_PRINT((ACPI_DB_INFO, - "acpi_cpu%d: no BM control, using flush cache method\n", - device_get_unit(sc->cpu_dev))); - } else { - cpu_quirks |= CPU_QUIRK_NO_C3; - ACPI_DEBUG_PRINT((ACPI_DB_INFO, - "acpi_cpu%d: no BM control, C3 not available\n", - device_get_unit(sc->cpu_dev))); - } + if (!cpu_cx_generic && acpi_cpu_cx_cst(sc) != 0) { + /* + * We were unable to find a _CST package for this cpu or there + * was an error parsing it. Switch back to generic mode. + */ + cpu_cx_generic = 1; + device_printf(sc->cpu_dev, "Switching to generic Cx mode\n"); } /* - * First, check for the ACPI 2.0 _CST sleep states object. - * If not usable, fall back to the P_BLK's P_LVL2 and P_LVL3. + * TODO: _CSD Package should be checked here. */ +} + +static void +acpi_cpu_generic_cx_probe(struct acpi_cpu_softc *sc) +{ + ACPI_GENERIC_ADDRESS gas; + struct acpi_cx *cx_ptr; + sc->cpu_cx_count = 0; - error = acpi_cpu_cx_cst(sc); - if (error != 0) { - cx_ptr = sc->cpu_cx_states; - - /* C1 has been required since just after ACPI 1.0 */ - cx_ptr->type = ACPI_STATE_C1; - cx_ptr->trans_lat = 0; - cpu_non_c3 = 0; - cx_ptr++; - sc->cpu_cx_count++; - - /* - * The spec says P_BLK must be 6 bytes long. However, some systems - * use it to indicate a fractional set of features present so we - * take 5 as C2. Some may also have a value of 7 to indicate - * another C3 but most use _CST for this (as required) and having - * "only" C1-C3 is not a hardship. - */ - if (sc->cpu_p_blk_len < 5) - goto done; + cx_ptr = sc->cpu_cx_states; + + /* Use initial sleep value of 1 sec. to start with lowest idle state. */ + sc->cpu_prev_sleep = 1000000; + + /* C1 has been required since just after ACPI 1.0 */ + cx_ptr->type = ACPI_STATE_C1; + cx_ptr->trans_lat = 0; + cx_ptr++; + sc->cpu_cx_count++; + + /* + * The spec says P_BLK must be 6 bytes long. However, some systems + * use it to indicate a fractional set of features present so we + * take 5 as C2. Some may also have a value of 7 to indicate + * another C3 but most use _CST for this (as required) and having + * "only" C1-C3 is not a hardship. + */ + if (sc->cpu_p_blk_len < 5) + return; - /* Validate and allocate resources for C2 (P_LVL2). */ - gas.AddressSpaceId = ACPI_ADR_SPACE_SYSTEM_IO; - gas.RegisterBitWidth = 8; - if (AcpiGbl_FADT->Plvl2Lat <= 100) { - gas.Address = sc->cpu_p_blk + 4; - acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &cpu_rid, &gas, - &cx_ptr->p_lvlx); - if (cx_ptr->p_lvlx != NULL) { - cpu_rid++; + /* Validate and allocate resources for C2 (P_LVL2). */ + gas.AddressSpaceId = ACPI_ADR_SPACE_SYSTEM_IO; + gas.RegisterBitWidth = 8; + if (AcpiGbl_FADT->Plvl2Lat <= 100) { + gas.Address = sc->cpu_p_blk + 4; + acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid, &gas, + &cx_ptr->p_lvlx, RF_SHAREABLE); + if (cx_ptr->p_lvlx != NULL) { + sc->cpu_rid++; cx_ptr->type = ACPI_STATE_C2; cx_ptr->trans_lat = AcpiGbl_FADT->Plvl2Lat; - cpu_non_c3 = 1; cx_ptr++; sc->cpu_cx_count++; - } } - if (sc->cpu_p_blk_len < 6) - goto done; + } + if (sc->cpu_p_blk_len < 6) + return; - /* Validate and allocate resources for C3 (P_LVL3). */ - if (AcpiGbl_FADT->Plvl3Lat <= 1000 && - (cpu_quirks & CPU_QUIRK_NO_C3) == 0) { - gas.Address = sc->cpu_p_blk + 5; - acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &cpu_rid, &gas, - &cx_ptr->p_lvlx); - if (cx_ptr->p_lvlx != NULL) { - cpu_rid++; + /* Validate and allocate resources for C3 (P_LVL3). */ + if (AcpiGbl_FADT->Plvl3Lat <= 1000) { + gas.Address = sc->cpu_p_blk + 5; + acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid, &gas, + &cx_ptr->p_lvlx, RF_SHAREABLE); + if (cx_ptr->p_lvlx != NULL) { + sc->cpu_rid++; cx_ptr->type = ACPI_STATE_C3; cx_ptr->trans_lat = AcpiGbl_FADT->Plvl3Lat; cx_ptr++; sc->cpu_cx_count++; - } } } -done: - /* If no valid registers were found, don't attach. */ - if (sc->cpu_cx_count == 0) - return (ENXIO); - - /* Use initial sleep value of 1 sec. to start with lowest idle state. */ - sc->cpu_prev_sleep = 1000000; + /* Update the largest cx_count seen so far */ + if (sc->cpu_cx_count > cpu_cx_count) + cpu_cx_count = sc->cpu_cx_count; - return (0); + return; } /* @@ -570,8 +584,10 @@ buf.Pointer = NULL; buf.Length = ACPI_ALLOCATE_BUFFER; status = AcpiEvaluateObject(sc->cpu_handle, "_CST", NULL, &buf); - if (ACPI_FAILURE(status)) + if (ACPI_FAILURE(status)) { + device_printf(sc->cpu_dev, "Unable to find _CST method\n"); return (ENXIO); + } /* _CST is a package with a count and at least one Cx package. */ top = (ACPI_OBJECT *)buf.Pointer; @@ -607,7 +623,7 @@ /* Validate the state to see if we should use it. */ switch (cx_ptr->type) { case ACPI_STATE_C1: - cpu_non_c3 = i; + sc->cpu_non_c3 = i; cx_ptr++; sc->cpu_cx_count++; continue; @@ -618,7 +634,7 @@ device_get_unit(sc->cpu_dev), i)); continue; } - cpu_non_c3 = i; + sc->cpu_non_c3 = i; break; case ACPI_STATE_C3: default: @@ -642,10 +658,10 @@ #endif /* Allocate the control register for C2 or C3. */ - acpi_PkgGas(sc->cpu_dev, pkg, 0, &cx_ptr->res_type, &cpu_rid, - &cx_ptr->p_lvlx); + acpi_PkgGas(sc->cpu_dev, pkg, 0, &cx_ptr->res_type, &sc->cpu_rid, + &cx_ptr->p_lvlx, RF_SHAREABLE); if (cx_ptr->p_lvlx) { - cpu_rid++; + sc->cpu_rid++; ACPI_DEBUG_PRINT((ACPI_DB_INFO, "acpi_cpu%d: Got C%d - %d latency\n", device_get_unit(sc->cpu_dev), cx_ptr->type, @@ -666,81 +682,121 @@ acpi_cpu_startup(void *arg) { struct acpi_cpu_softc *sc; - int count, i; + int i; /* Get set of CPU devices */ devclass_get_devices(acpi_cpu_devclass, &cpu_devices, &cpu_ndevices); - /* Check for quirks via the first CPU device. */ - sc = device_get_softc(cpu_devices[0]); - acpi_cpu_quirks(sc); - /* - * Make sure all the processors' Cx counts match. We should probably - * also check the contents of each. However, no known systems have - * non-matching Cx counts so we'll deal with this later. + * Setup any quirks that might necessary now that we have probed + * all the CPUs */ - count = MAX_CX_STATES; - for (i = 0; i < cpu_ndevices; i++) { - sc = device_get_softc(cpu_devices[i]); - count = min(sc->cpu_cx_count, count); + acpi_cpu_quirks(); + + cpu_cx_count = 0; + if (cpu_cx_generic) { + /* + * We are using generic Cx mode, probe for available Cx states + * for all processors. + */ + for (i = 0; i < cpu_ndevices; i++) { + sc = device_get_softc(cpu_devices[i]); + acpi_cpu_generic_cx_probe(sc); + } + + /* + * Find the highest Cx state common to all CPUs + * in the system, taking quirks into account. + */ + for (i = 0; i < cpu_ndevices; i++) { + sc = device_get_softc(cpu_devices[i]); + if (sc->cpu_cx_count < cpu_cx_count) + cpu_cx_count = sc->cpu_cx_count; + } + } else { + /* + * We are using _CST mode, remove C3 state if necessary. + * Update the largest Cx state supported in the global cpu_cx_count. + * It will be used in the Globa Cx sysctl handler. + * As we now know for sure that we will be using _CST mode + * install our notify handler. + */ + for (i = 0; i < cpu_ndevices; i++) { + sc = device_get_softc(cpu_devices[i]); + if (cpu_quirks && CPU_QUIRK_NO_C3) { + sc->cpu_cx_count = sc->cpu_non_c3 + 1; + } + if (sc->cpu_cx_count > cpu_cx_count) + cpu_cx_count = sc->cpu_cx_count; + AcpiInstallNotifyHandler(sc->cpu_handle, + ACPI_DEVICE_NOTIFY, acpi_cpu_notify, sc); + } } - cpu_cx_count = count; /* Perform Cx final initialization. */ - sc = device_get_softc(cpu_devices[0]); - if (cpu_cx_count > 0) - acpi_cpu_startup_cx(); + for (i = 0; i < cpu_ndevices; i++) { + sc = device_get_softc(cpu_devices[i]); + acpi_cpu_startup_cx(sc); + } + + /* Add a sysctl handler to handle global Cx lowest setting */ + SYSCTL_ADD_PROC(&acpi_cpu_sysctl_ctx, + SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), + OID_AUTO, "cx_lowest", CTLTYPE_STRING | CTLFLAG_RW, + NULL, 0, acpi_cpu_global_cx_lowest_sysctl, "A", + "Global lowest Cx sleep state to use"); + + /* Take over idling from cpu_idle_default(). */ + cpu_cx_lowest = 0; + cpu_disable_idle = 0; + cpu_idle_hook = acpi_cpu_idle; } static void -acpi_cpu_startup_cx() +acpi_cpu_startup_cx(struct acpi_cpu_softc *sc) { - struct acpi_cpu_softc *sc; struct sbuf sb; int i; /* - * Set up the list of Cx states, eliminating C3 states by truncating - * cpu_cx_count if quirks indicate C3 is not usable. + * Set up the list of Cx states */ - sc = device_get_softc(cpu_devices[0]); - sbuf_new(&sb, cpu_cx_supported, sizeof(cpu_cx_supported), SBUF_FIXEDLEN); - for (i = 0; i < cpu_cx_count; i++) { - if ((cpu_quirks & CPU_QUIRK_NO_C3) == 0 || - sc->cpu_cx_states[i].type != ACPI_STATE_C3) - sbuf_printf(&sb, "C%d/%d ", i + 1, sc->cpu_cx_states[i].trans_lat); - else - cpu_cx_count = i; + sc->cpu_non_c3 = 0; + sbuf_new(&sb, sc->cpu_cx_supported, sizeof(sc->cpu_cx_supported), + SBUF_FIXEDLEN); + for (i = 0; i < sc->cpu_cx_count; i++) { + sbuf_printf(&sb, "C%d/%d ", i + 1, sc->cpu_cx_states[i].trans_lat); + if (sc->cpu_cx_states[i].type < ACPI_STATE_C3) + sc->cpu_non_c3 = i; } + sbuf_trim(&sb); sbuf_finish(&sb); - SYSCTL_ADD_STRING(&acpi_cpu_sysctl_ctx, - SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), - OID_AUTO, "cx_supported", CTLFLAG_RD, cpu_cx_supported, - 0, "Cx/microsecond values for supported Cx states"); - SYSCTL_ADD_PROC(&acpi_cpu_sysctl_ctx, - SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), + SYSCTL_ADD_STRING(&sc->acpi_cpu_sysctl_ctx, + SYSCTL_CHILDREN(sc->acpi_cpu_sysctl_tree), + OID_AUTO, "cx_supported", CTLFLAG_RD, + sc->cpu_cx_supported, 0, + "Cx/microsecond values for supported Cx states"); + SYSCTL_ADD_PROC(&sc->acpi_cpu_sysctl_ctx, + SYSCTL_CHILDREN(sc->acpi_cpu_sysctl_tree), OID_AUTO, "cx_lowest", CTLTYPE_STRING | CTLFLAG_RW, - NULL, 0, acpi_cpu_cx_lowest_sysctl, "A", + (void *)sc, 0, acpi_cpu_cx_lowest_sysctl, "A", "lowest Cx sleep state to use"); - SYSCTL_ADD_PROC(&acpi_cpu_sysctl_ctx, - SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), + SYSCTL_ADD_PROC(&sc->acpi_cpu_sysctl_ctx, + SYSCTL_CHILDREN(sc->acpi_cpu_sysctl_tree), OID_AUTO, "cx_usage", CTLTYPE_STRING | CTLFLAG_RD, - NULL, 0, acpi_cpu_usage_sysctl, "A", + (void *)sc, 0, acpi_cpu_usage_sysctl, "A", "percent usage for each Cx state"); #ifdef notyet /* Signal platform that we can handle _CST notification. */ - if (cpu_cst_cnt != 0) { + if (!cpu_cx_generic) { ACPI_LOCK(acpi); AcpiOsWritePort(cpu_smi_cmd, cpu_cst_cnt, 8); ACPI_UNLOCK(acpi); } #endif - /* Take over idling from cpu_idle_default(). */ - cpu_idle_hook = acpi_cpu_idle; } /* @@ -758,7 +814,7 @@ int bm_active, cx_next_idx, i; /* If disabled, return immediately. */ - if (cpu_cx_count == 0) { + if (cpu_disable_idle != 0) { ACPI_ENABLE_IRQS(); return; } @@ -779,28 +835,34 @@ * find the lowest state that has a latency less than or equal to * the length of our last sleep. */ - cx_next_idx = cpu_cx_lowest; + cx_next_idx = sc->cpu_cx_lowest; if (sc->cpu_prev_sleep < 100) { /* * If we sleep too short all the time, this system may not implement * C2/3 correctly (i.e. reads return immediately). In this case, * back off and use the next higher level. + * It seems that when you have a dual core cpu (like the Intel Core Duo) + * that both cores will get out of C3 state as soon as one of them + * requires it. This breaks the sleep detection logic as the sleep + * counter is local to each cpu. Disable the sleep logic for now as a + * workaround if there's more than one CPU. The right fix would probably + * be to add quirks for system that don't really support C3 state. */ - if (sc->cpu_prev_sleep <= 1) { - cpu_short_slp++; - if (cpu_short_slp == 1000 && cpu_cx_lowest != 0) { - if (cpu_non_c3 == cpu_cx_lowest && cpu_non_c3 != 0) - cpu_non_c3--; - cpu_cx_lowest--; - cpu_short_slp = 0; + if (mp_ncpus < 2 && sc->cpu_prev_sleep <= 1) { + sc->cpu_short_slp++; + if (sc->cpu_short_slp == 1000 && sc->cpu_cx_lowest != 0) { + if (sc->cpu_non_c3 == sc->cpu_cx_lowest && sc->cpu_non_c3 != 0) + sc->cpu_non_c3--; + sc->cpu_cx_lowest--; + sc->cpu_short_slp = 0; device_printf(sc->cpu_dev, "too many short sleeps, backing off to C%d\n", - cpu_cx_lowest + 1); + sc->cpu_cx_lowest + 1); } } else - cpu_short_slp = 0; + sc->cpu_short_slp = 0; - for (i = cpu_cx_lowest; i >= 0; i--) + for (i = sc->cpu_cx_lowest; i >= 0; i--) if (sc->cpu_cx_states[i].trans_lat <= sc->cpu_prev_sleep) { cx_next_idx = i; break; @@ -819,13 +881,13 @@ if (bm_active != 0) { AcpiSetRegister(ACPI_BITREG_BUS_MASTER_STATUS, 1, ACPI_MTX_DO_NOT_LOCK); - cx_next_idx = min(cx_next_idx, cpu_non_c3); + cx_next_idx = min(cx_next_idx, sc->cpu_non_c3); } } /* Select the next state and update statistics. */ cx_next = &sc->cpu_cx_states[cx_next_idx]; - cpu_cx_stats[cx_next_idx]++; + sc->cpu_cx_stats[cx_next_idx]++; KASSERT(cx_next->type != ACPI_STATE_C0, ("acpi_cpu_idle: C0 sleep")); /* @@ -901,15 +963,35 @@ } static int -acpi_cpu_quirks(struct acpi_cpu_softc *sc) +acpi_cpu_quirks(void) { device_t acpi_dev; /* - * C3 on multiple CPUs requires using the expensive flush cache - * instruction. + * Bus mastering arbitration control is needed to keep caches coherent + * while sleeping in C3. If it's not present but a working flush cache + * instruction is present, flush the caches before entering C3 instead. + * Otherwise, just disable C3 completely. */ - if (mp_ncpus > 1) + if (AcpiGbl_FADT->V1_Pm2CntBlk == 0 || AcpiGbl_FADT->Pm2CntLen == 0) { + if (AcpiGbl_FADT->WbInvd && AcpiGbl_FADT->WbInvdFlush == 0) { + cpu_quirks |= CPU_QUIRK_NO_BM_CTRL; + ACPI_DEBUG_PRINT((ACPI_DB_INFO, + "acpi_cpu%d: no BM control, using flush cache method\n", + device_get_unit(sc->cpu_dev))); + } else { + cpu_quirks |= CPU_QUIRK_NO_C3; + ACPI_DEBUG_PRINT((ACPI_DB_INFO, + "acpi_cpu%d: no BM control, C3 not available\n", + device_get_unit(sc->cpu_dev))); + } + } + + /* + * If we are using generic Cx mode, C3 on multiple CPUs requires using + * the expensive flush cache instruction. + */ + if (cpu_cx_generic && mp_ncpus > 1) cpu_quirks |= CPU_QUIRK_NO_BM_CTRL; /* Look for various quirks of the PIIX4 part. */ @@ -943,18 +1025,20 @@ static int acpi_cpu_usage_sysctl(SYSCTL_HANDLER_ARGS) { + struct acpi_cpu_softc *sc; struct sbuf sb; char buf[128]; int i; uintmax_t fract, sum, whole; + sc = (struct acpi_cpu_softc *) arg1; sum = 0; - for (i = 0; i < cpu_cx_count; i++) - sum += cpu_cx_stats[i]; + for (i = 0; i < sc->cpu_cx_count; i++) + sum += sc->cpu_cx_stats[i]; sbuf_new(&sb, buf, sizeof(buf), SBUF_FIXEDLEN); - for (i = 0; i < cpu_cx_count; i++) { + for (i = 0; i < sc->cpu_cx_count; i++) { if (sum > 0) { - whole = (uintmax_t)cpu_cx_stats[i] * 100; + whole = (uintmax_t)sc->cpu_cx_stats[i] * 100; fract = (whole % sum) * 100; sbuf_printf(&sb, "%u.%02u%% ", (u_int)(whole / sum), (u_int)(fract / sum)); @@ -976,32 +1060,74 @@ char state[8]; int val, error, i; - sc = device_get_softc(cpu_devices[0]); - snprintf(state, sizeof(state), "C%d", cpu_cx_lowest + 1); + sc = (struct acpi_cpu_softc *) arg1; + snprintf(state, sizeof(state), "C%d", sc->cpu_cx_lowest + 1); error = sysctl_handle_string(oidp, state, sizeof(state), req); if (error != 0 || req->newptr == NULL) return (error); if (strlen(state) < 2 || toupper(state[0]) != 'C') return (EINVAL); val = (int) strtol(state + 1, NULL, 10) - 1; - if (val < 0 || val > cpu_cx_count - 1) + if (val < 0 || val > sc->cpu_cx_count - 1) return (EINVAL); ACPI_SERIAL_BEGIN(cpu); - cpu_cx_lowest = val; + sc->cpu_cx_lowest = val; /* If not disabling, cache the new lowest non-C3 state. */ - cpu_non_c3 = 0; - for (i = cpu_cx_lowest; i >= 0; i--) { + sc->cpu_non_c3 = 0; + for (i = sc->cpu_cx_lowest; i >= 0; i--) { if (sc->cpu_cx_states[i].type < ACPI_STATE_C3) { - cpu_non_c3 = i; + sc->cpu_non_c3 = i; break; } } /* Reset the statistics counters. */ - bzero(cpu_cx_stats, sizeof(cpu_cx_stats)); + bzero(sc->cpu_cx_stats, sizeof(sc->cpu_cx_stats)); + ACPI_SERIAL_END(cpu); + + return (0); +} + +static int +acpi_cpu_global_cx_lowest_sysctl(SYSCTL_HANDLER_ARGS) +{ + struct acpi_cpu_softc *sc; + char state[8]; + int val, error, i, j; + + snprintf(state, sizeof(state), "C%d", cpu_cx_lowest + 1); + error = sysctl_handle_string(oidp, state, sizeof(state), req); + if (error != 0 || req->newptr == NULL) + return (error); + if (strlen(state) < 2 || toupper(state[0]) != 'C') + return (EINVAL); + val = (int) strtol(state + 1, NULL, 10) - 1; + if (val < 0 || val > cpu_cx_count - 1) + return (EINVAL); + + cpu_cx_lowest = val; + + /* + * Update the new lowest useable Cx state for all CPUs + */ + ACPI_SERIAL_BEGIN(cpu); + for (i = 0; i < cpu_ndevices; i++) { + sc = device_get_softc(cpu_devices[i]); + sc->cpu_cx_lowest = cpu_cx_lowest; + sc->cpu_non_c3 = 0; + for (j = sc->cpu_cx_lowest; j >= 0; j++) { + if (sc->cpu_cx_states[i].type < ACPI_STATE_C3) { + sc->cpu_non_c3 = i; + break; + } + } + /* Reset the statistics counters. */ + bzero(sc->cpu_cx_stats, sizeof(sc->cpu_cx_stats)); + } ACPI_SERIAL_END(cpu); return (0); } + Index: sys/dev/acpica/acpi_package.c =================================================================== RCS file: /home/FreeBSD/ncvs/src/sys/dev/acpica/acpi_package.c,v retrieving revision 1.8 diff -u -r1.8 acpi_package.c --- sys/dev/acpica/acpi_package.c 11 Sep 2005 18:39:01 -0000 1.8 +++ sys/dev/acpica/acpi_package.c 7 Jun 2006 20:50:37 -0000 @@ -104,7 +104,7 @@ int acpi_PkgGas(device_t dev, ACPI_OBJECT *res, int idx, int *type, int *rid, - struct resource **dst) + struct resource **dst, u_int flags) { ACPI_GENERIC_ADDRESS gas; ACPI_OBJECT *obj; @@ -116,7 +116,7 @@ memcpy(&gas, obj->Buffer.Pointer + 3, sizeof(gas)); - return (acpi_bus_alloc_gas(dev, type, rid, &gas, dst)); + return (acpi_bus_alloc_gas(dev, type, rid, &gas, dst, flags)); } ACPI_HANDLE Index: sys/dev/acpica/acpi_perf.c =================================================================== RCS file: /home/FreeBSD/ncvs/src/sys/dev/acpica/acpi_perf.c,v retrieving revision 1.23 diff -u -r1.23 acpi_perf.c --- sys/dev/acpica/acpi_perf.c 12 Dec 2005 11:15:20 -0000 1.23 +++ sys/dev/acpica/acpi_perf.c 7 Jun 2006 20:50:37 -0000 @@ -191,7 +191,7 @@ pkg = (ACPI_OBJECT *)buf.Pointer; if (ACPI_PKG_VALID(pkg, 2)) { rid = 0; - error = acpi_PkgGas(dev, pkg, 0, &type, &rid, &res); + error = acpi_PkgGas(dev, pkg, 0, &type, &rid, &res, 0); switch (error) { case 0: bus_release_resource(dev, type, rid, res); @@ -323,7 +323,7 @@ } error = acpi_PkgGas(sc->dev, pkg, 0, &sc->perf_ctrl_type, &sc->px_rid, - &sc->perf_ctrl); + &sc->perf_ctrl, 0); if (error) { /* * If the register is of type FFixedHW, we can only return @@ -339,7 +339,7 @@ sc->px_rid++; error = acpi_PkgGas(sc->dev, pkg, 1, &sc->perf_sts_type, &sc->px_rid, - &sc->perf_status); + &sc->perf_status, 0); if (error) { if (error == EOPNOTSUPP) { sc->info_only = TRUE; Index: sys/dev/acpica/acpi_throttle.c =================================================================== RCS file: /home/FreeBSD/ncvs/src/sys/dev/acpica/acpi_throttle.c,v retrieving revision 1.9 diff -u -r1.9 acpi_throttle.c --- sys/dev/acpica/acpi_throttle.c 21 Feb 2006 03:15:26 -0000 1.9 +++ sys/dev/acpica/acpi_throttle.c 7 Jun 2006 20:50:37 -0000 @@ -278,7 +278,7 @@ } memcpy(&gas, obj.Buffer.Pointer + 3, sizeof(gas)); acpi_bus_alloc_gas(sc->cpu_dev, &sc->cpu_p_type, &thr_rid, - &gas, &sc->cpu_p_cnt); + &gas, &sc->cpu_p_cnt, 0); if (sc->cpu_p_cnt != NULL && bootverbose) { device_printf(sc->cpu_dev, "P_CNT from _PTC %#jx\n", gas.Address); @@ -298,7 +298,7 @@ gas.AddressSpaceId = ACPI_ADR_SPACE_SYSTEM_IO; gas.RegisterBitWidth = 32; acpi_bus_alloc_gas(sc->cpu_dev, &sc->cpu_p_type, &thr_rid, - &gas, &sc->cpu_p_cnt); + &gas, &sc->cpu_p_cnt, 0); if (sc->cpu_p_cnt != NULL) { if (bootverbose) device_printf(sc->cpu_dev, Index: sys/dev/acpica/acpivar.h =================================================================== RCS file: /home/FreeBSD/ncvs/src/sys/dev/acpica/acpivar.h,v retrieving revision 1.100 diff -u -r1.100 acpivar.h --- sys/dev/acpica/acpivar.h 6 Dec 2005 14:47:28 -0000 1.100 +++ sys/dev/acpica/acpivar.h 7 Jun 2006 20:50:37 -0000 @@ -311,7 +311,8 @@ void acpi_UserNotify(const char *subsystem, ACPI_HANDLE h, uint8_t notify); int acpi_bus_alloc_gas(device_t dev, int *type, int *rid, - ACPI_GENERIC_ADDRESS *gas, struct resource **res); + ACPI_GENERIC_ADDRESS *gas, struct resource **res, + u_int flags); struct acpi_parse_resource_set { void (*set_init)(device_t dev, void *arg, void **context); @@ -417,7 +418,7 @@ int acpi_PkgInt32(ACPI_OBJECT *res, int idx, uint32_t *dst); int acpi_PkgStr(ACPI_OBJECT *res, int idx, void *dst, size_t size); int acpi_PkgGas(device_t dev, ACPI_OBJECT *res, int idx, int *type, - int *rid, struct resource **dst); + int *rid, struct resource **dst, u_int flags); ACPI_HANDLE acpi_GetReference(ACPI_HANDLE scope, ACPI_OBJECT *obj); /* Default number of task queue threads to start. */ --------------080305070803060308000602-- From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 8 13:36:31 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 858E01701C3; Thu, 8 Jun 2006 11:22:04 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BA0843D70; Thu, 8 Jun 2006 11:22:02 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.6/8.13.6/NinthNine) with ESMTP id k54B8YMv087631; Sun, 4 Jun 2006 20:08:35 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 4 Jun 2006 20:08:34 +0900 From: Norikatsu Shigemura To: freebsd-mobile@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-acpi@FreeBSD.org Message-Id: <20060604200834.8db4782c.nork@FreeBSD.org> X-Mailer: Sylpheed version 2.2.5 (GTK+ 2.8.18; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Sun, 04 Jun 2006 20:08:35 +0900 (JST) Cc: Subject: FYI: Panasonic Toughbook CF-R4 can suspend/resume 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, 08 Jun 2006 13:36:31 -0000 I confirmed 3rd generation CF-R4 (Panasonic Toughbook/ Let's Note series, 2006 Spring Model) can suspend/resume:-) with following settings. Add to /boot/loader.conf - - - - - - - - - - - - - - - - hint.apic.0.disabled="1" hint.psm.0.flags="0x2000" - - - - - - - - - - - - - - - - And, mita-san (mita@FreeBSD.org) has CF-W4 (3rd generation). It can suspend/resume:-), too. But Ume-san (ume@) has CF-R4(1st generation), it cannot suspend/resume:-(. Takahashi-san(nyan@) has CF-R3, same too:-(. I read /usr/src/sys/i386/i386/io_apic.c, and I'm suprised following code: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #define TODO printf("%s: not implemented!\n", __func__) static void ioapic_suspend(struct intsrc *isrc) { TODO; } static void ioapic_resume(struct intsrc *isrc) { ioapic_program_intpin((struct ioapic_intsrc *)isrc); } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hum.................... From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 8 17:53:12 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A2C516F9A9 for ; Thu, 8 Jun 2006 16:06:19 +0000 (UTC) (envelope-from atkin901@yahoo.com) Received: from web34101.mail.mud.yahoo.com (web34101.mail.mud.yahoo.com [66.163.178.99]) by mx1.FreeBSD.org (Postfix) with SMTP id E7A0A43D49 for ; Thu, 8 Jun 2006 16:06:18 +0000 (GMT) (envelope-from atkin901@yahoo.com) Received: (qmail 6905 invoked by uid 60001); 8 Jun 2006 16:06:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=myNALfQtWcB5ddLMxG58v1S3mCQ1cGkDvjNPbDUUM+JaOUTX0cQjwd/Tw3Ld03zevEm/PH65JdLnxTSGowADPYtP+k++aThlELxkuEauh6+55YUSDbLCnlj0ATZQBQFJdWSHyVahTb/D+HwPBWcz2AeuSXaq/I9adeySFst59ek= ; Message-ID: <20060608160617.6903.qmail@web34101.mail.mud.yahoo.com> Received: from [205.229.151.151] by web34101.mail.mud.yahoo.com via HTTP; Thu, 08 Jun 2006 09:06:17 PDT Date: Thu, 8 Jun 2006 09:06:17 -0700 (PDT) From: Mark Atkinson To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: hard hang on Current with acpi on MSI MS-9618 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, 08 Jun 2006 17:53:14 -0000 With current from this morning 6/8/2006, I have a hard hang booting this MSI motherboard MS-9618 with ACPI enabled. This Mboard is part of MSI's PI-103 series which is what pogo-linux ships as there webware 1185 boxes. I cannot even break to debugger when the hang occurs, I have ALT_BREAK_TO_DEBUGGER defined since I'm on serial console. The systems boots ands runs w/o acpi.ko loaded, however I was having problems with using both em0 and em1 built ins on the motherboard and thought that loading acpi support would help. As a further note, I had the same hang with -current from like 50 days ago ~ 4/13/2006 This is Intel E7230 + ICH7R board. boot -v output: GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009f800 SMAP type=02 base=000000000009f800 len=0000000000000800 SMAP type=02 base=00000000000dc000 len=0000000000024000 SMAP type=01 base=0000000000100000 len=000000003fd90000 SMAP type=03 base=000000003fe90000 len=000000000000d000 SMAP type=04 base=000000003fe9d000 len=0000000000063000 SMAP type=02 base=000000003ff00000 len=0000000000100000 SMAP type=02 base=00000000fec00000 len=0000000000010000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ff000000 len=0000000001000000 Copyright (c) 1992-2006 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 7.0-CURRENT #1: Thu Jun 8 08:11:00 PDT 2006 root@pogo-1.f5test.net:/usr/obj/usr/src/sys/POGO WARNING: WITNESS option enabled, expect reduced performance. Using 32 colors for the VM-PQ tuning (1024, 8) Preloaded elf kernel "/boot/kernel/kernel" at 0xc0cdb000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0cdb1ac. MP Configuration Table version 1.4 found at 0xc009fda1 Table 'FACP' at 0x3fe9cda9 Table 'ASF!' at 0x3fe9ce1d Table 'SPCR' at 0x3fe9cee4 Table 'MCFG' at 0x3fe9cf34 Table 'APIC' at 0x3fe9cf70 MADT: Found table at 0x3fe9cf70 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) INTR: Adding local APIC 0 as a target ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193206 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3192014816 Hz CPU: Intel(R) Pentium(R) D CPU 3.20GHz (3192.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf44 Stepping = 4 Features=0xbfebfbff Features2=0x649d AMD Features=0x20100000 Cores per package: 2 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 16 KB, 8-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 1 MB, 8-way set associative, sectored cache, 64 byte line size L2 cache: 1024 kbytes, 8-way associative, 64 bytes/line real memory = 1072234496 (1022 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001028000 - 0x000000003ec55fff, 1036181504 bytes (252974 pages) avail memory = 1035837440 (987 MB) INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f6190 bios32: Entry = 0xfd480 (c00fd480) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd480+0x34c pnpbios: Found PnP BIOS data at 0xc00f6220 pnpbios: Entry = f0000:aa1f Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Jun 8 2006 08:10:46) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000fa20 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27788086) pcibios: BIOS version 2.10 AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: Power Button (fixed) AcpiOsDerivePciId: bus 0 dev 0 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 3 10 11 14 15 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 3 10 11 14 15 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 10 11 14 15 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 10 11 14 15 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 10 11 14 15 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 10 11 14 15 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 3 10 11 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 3 10 11 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 3 10 11 14 15 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x1010 cpu1: on acpi0 acpi_perf1: on cpu1 acpi_perf1: failed in PERF_STATUS attach device_attach: acpi_perf1 attach returned 6 acpi_perf1: on cpu1 acpi_perf1: failed in PERF_STATUS attach device_attach: acpi_perf1 attach returned 6 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x2778, revid=0x81 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2779, revid=0x81 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0100, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d0, revid=0x01 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27e0, revid=0x01 bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27e2, revid=0x01 bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27c8, revid=0x01 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type 4, range 32, base 00003000, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x01 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 00003020, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x01 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type 4, range 32, base 00003040, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x01 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 map[20]: type 4, range 32, base 00003060, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x01 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base d8500000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xe1 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x01 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 000030a0, size 4, enabled found-> vendor=0x8086, dev=0x27c0, revid=0x01 bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 000030e8, size 3, enabled map[14]: type 4, range 32, base 000030dc, size 2, enabled map[18]: type 4, range 32, base 000030e0, size 3, enabled map[1c]: type 4, range 32, base 000030d8, size 2, enabled map[20]: type 4, range 32, base 000030b0, size 4, enabled map[24]: type 1, range 32, base d8500400, size 10, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27da, revid=0x01 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0101, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 00001100, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 pcib1: irq 16 at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: memory decode 0x0-0x0 pcib1: prefetched decode 0x0-0x0 pci1: on pcib1 pci1: physical bus=1 pcib2: irq 17 at device 28.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: memory decode 0x0-0x0 pcib2: prefetched decode 0x0-0x0 pci2: on pcib2 pci2: physical bus=2 pcib3: irq 17 at device 28.4 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x4000-0x4fff pcib3: memory decode 0xd8000000-0xd80fffff pcib3: prefetched decode 0xfff00000-0xfffff pci3: on pcib3 pci3: physical bus=3 found-> vendor=0x8086, dev=0x108b, revid=0x03 bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base d8000000, size 17, enabled pcib3: (null) requested memory range 0xd8000000-0xd801ffff: good map[18]: type 4, range 32, base 00004000, size 5, enabled pcib3: (null) requested I/O range 0x4000-0x401f: in range pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 em0: port 0x4000-0x401f mem 0xd8000000-0xd801ffff irq 16 at device 0.0 on pci3 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8000000 em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0x4000 em0: bpf attached em0: Ethernet address: 00:13:d3:fe:04:f2 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 em0: [FAST] pcib4: irq 16 at device 28.5 on pci0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x5000-0x5fff pcib4: memory decode 0xd8100000-0xd81fffff pcib4: prefetched decode 0xfff00000-0xfffff pci4: on pcib4 pci4: physical bus=4 found-> vendor=0x8086, dev=0x108b, revid=0x00 bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base d8100000, size 17, enabled pcib4: (null) requested memory range 0xd8100000-0xd811ffff: good map[18]: type 4, range 32, base 00005000, size 5, enabled pcib4: (null) requested I/O range 0x5000-0x501f: in range pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 17 em1: port 0x5000-0x501f mem 0xd8100000-0xd811ffff irq 17 at device 0.0 on pci4 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8100000 em1: Reserved 0x20 bytes for rid 0x18 type 4 at 0x5000 em1: bpf attached em1: Ethernet address: 00:13:d3:fe:04:f3 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 50 em1: [FAST] uhci0: port 0x3000-0x301f irq 23 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3000 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 51 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3020-0x303f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3020 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 52 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3040 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 53 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3060-0x307f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3060 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd8500000-0xd85003ff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8500000 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib5: at device 30.0 on pci0 pcib5: secondary bus 10 pcib5: subordinate bus 10 pcib5: I/O decode 0x6000-0x6fff pcib5: memory decode 0xd8200000-0xd82fffff pcib5: prefetched decode 0xd0000000-0xd7ffffff pcib5: Subtractively decoded bridge. pci10: on pcib5 pci10: physical bus=10 found-> vendor=0x1002, dev=0x5159, revid=0x00 bus=10, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0387, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base d0000000, size 27, enabled pcib5: (null) requested memory range 0xd0000000-0xd7ffffff: good map[14]: type 4, range 32, base 00006000, size 8, enabled pcib5: (null) requested I/O range 0x6000-0x60ff: in range map[18]: type 1, range 32, base d8200000, size 16, enabled pcib5: (null) requested memory range 0xd8200000-0xd820ffff: good pcib5: matched entry for 10.0.INTA pcib5: slot 0 INTA hardwired to IRQ 16 vgapci0: port 0x6000-0x60ff mem 0xd0000000-0xd7ffffff,0xd8200000-0xd820ffff irq 16 at device 0.0 on pci10 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30a0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=51 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x4 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 55 ata1: [MPSAFE] atapci1: port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xd8500400-0xd85007ff irq 19 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30b0 atapci1: [MPSAFE] atapci1: Reserved 0x400 bytes for rid 0x24 type 3 at 0xd8500400 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x30e8 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x30dc ata2: reset tp1 mask=03 ostat0=7f ostat1=7f ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat1=0x7f err=0xff lsb=0xff msb=0xff ata2: reset tp2 stat0=ff stat1=ff devices=0x0 ata2: [MPSAFE] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x30e0 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x30d8 ata3: reset tp1 mask=03 ostat0=50 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: [MPSAFE] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 sio0: irq maps: 0x4c21 0x4c29 0x4c21 0x4c21 sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A, console ioapic0: routing intpin 3 (ISA IRQ 3) to vector 56 sio0: [FAST] sio1: irq maps: 0x4c21 0x4c31 0x4c21 0x4c21 sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio1: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 sio1: [FAST] psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] psm0: current command byte:0067 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xdc000-0xdffff,0xe0000-0xe17ff pnpid ORM0000 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 99750466 hz Timecounter "TSC" frequency 3192014816 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. em0: Link is up 1000 Mbps Full Duplex em0: link state changed to UP ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on ICH7 chip acd0: setting UDMA33 on ICH7 chip acd0: CDRW drive at ata0 as master acd0: 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 76319MB at ata3-master SATA150 ad6: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad6 ad6: Intel check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 INTR: Assigning IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 1 to local APIC 0 INTR: Assigning IRQ 3 to local APIC 1 ioapic0: Assigning ISA IRQ 3 to local APIC 1 INTR: Assigning IRQ 4 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 0 INTR: Assigning IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 1 INTR: Assigning IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 0 INTR: Assigning IRQ 15 to local APIC 1 ioapic0: Assigning ISA IRQ 15 to local APIC 1 INTR: Assigning IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 16 to local APIC 0 INTR: Assigning IRQ 17 to local APIC 1 ioapic0: Assigning PCI IRQ 17 to local APIC 1 INTR: Assigning IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 0 INTR: Assigning IRQ 19 to local APIC 1 ioapic0: Assigning PCI IRQ 19 to local APIC 1 INTR: Assigning IRQ 23 to local APIC 0 ioapic0: Assigning PCI IRQ 23 to local APIC 0 Trying to mount root from ufs:/dev/ad6s1a start_init: trying /sbin/init **** HARD HANGS HERE **** Mark Atkinson atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 8 19:51:06 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FC1A170089 for ; Thu, 8 Jun 2006 18:22:47 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1CD043D55 for ; Thu, 8 Jun 2006 18:22:44 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA11457; Thu, 08 Jun 2006 21:22:38 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <44886AED.5070801@icyb.net.ua> Date: Thu, 08 Jun 2006 21:22:37 +0300 From: Andriy Gapon User-Agent: Thunderbird 1.5.0.2 (X11/20060512) MIME-Version: 1.0 To: Nate Lawson References: <4475C74C.2080204@icyb.net.ua> <447708E6.7010205@root.org> In-Reply-To: <447708E6.7010205@root.org> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: nforce2 cpufreq 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, 08 Jun 2006 20:36:33 -0000 on 26/05/2006 16:55 Nate Lawson said the following: > Andriy Gapon wrote: [snip] >> Anyway, my MB is based on nForce2 chipset and I found out that Linux has >> cpufreq-nforce2 module that works in their cpufreq framework: >> http://www.hasw.net/linux/ >> [snip] > > It's really easy to do. Just see the sys/dev/cpufreq/ichss.c file. > Nate and all, I have a pleasure to announce first public release of FreeBSD nf2fsb cpufreq driver. It is based on cpufreq-nforce2 Linux driver mentioned above for FSB frequency control and on atxp1 Linux driver for core voltage control. Thanks for both to Sebastian Witt! The source code can be found here: http://oddity-e.topspin.kiev.ua/cgi-bin/cvsweb.cgi/nf2fsb/ How-to for *Linux* drivers can be found here: http://forums.gentoo.org/viewtopic-t-273047-highlight-atxp.html This driver works stable and solid for me, but I still would qualify it as alpha quality because of many issues that I am not sure about. This is perhaps an under-qualification, but you are warned. So I'd say that at this point it is intended only for those who like to hack software and play with hardware. That's why I do not provide any compilation and installation instructions :-) Only one hint: this driver uses SMBus to access ATXP1 chip, so you definitely need SMBus to work. I am using nfsmb driver found in CURRENT (it is by Ruslan Ermilov) with one change - instead of PCIR_BAR(4) and PCIR_BAR(5) I have 0x50 and 0x54. BTW, nfsmb compiles and works on 6.1 like charm. My SMBus controller is: nfsmb0@pci0:1:1: class=0x0c0500 card=0x1c02147b chip=0x006410de You need to make sure that nfsmb is loaded before cpufreq. If you decide to try this driver please do read the code, at least the comments marked with XXX. Do not forget "AS-IS" disclaimer as well :-) I would appreciate all feedback: trouble and success reports, comments, suggestions and patches. Naming suggestions are welcome too, there is something about "nf2fsb" that doesn't feel right. At the end some "screenshots" (powerd is running): $ dmesg | tail -3 nf2fsb0: on cpu0 nf2fsb0: FSB is at 166MHz, CPU is at 1830MHz, frequency multiplier is 11.0 nf2fsb0: ATXP1 was found on smbus0, core volatge will be changed along with FSB speed $ sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 1826/-1 1650/-1 1463/-1 $ sysctl dev.cpu.0.freq dev.cpu.0.freq: 1463 $ mbmon -c 1 Temp.= 29.0, 41.0, 0.0; Rot.= 2393, 1767, 0 Vcore = 1.46, 2.62; Volt. = 3.28, 5.05, 11.86, -11.71, -4.90 My system is NF7 and Athlon XP 2500+. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 8 21:28:51 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FC1A170089 for ; Thu, 8 Jun 2006 18:22:47 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1CD043D55 for ; Thu, 8 Jun 2006 18:22:44 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA11457; Thu, 08 Jun 2006 21:22:38 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <44886AED.5070801@icyb.net.ua> Date: Thu, 08 Jun 2006 21:22:37 +0300 From: Andriy Gapon User-Agent: Thunderbird 1.5.0.2 (X11/20060512) MIME-Version: 1.0 To: Nate Lawson References: <4475C74C.2080204@icyb.net.ua> <447708E6.7010205@root.org> In-Reply-To: <447708E6.7010205@root.org> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: nforce2 cpufreq 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, 08 Jun 2006 21:28:51 -0000 on 26/05/2006 16:55 Nate Lawson said the following: > Andriy Gapon wrote: [snip] >> Anyway, my MB is based on nForce2 chipset and I found out that Linux has >> cpufreq-nforce2 module that works in their cpufreq framework: >> http://www.hasw.net/linux/ >> [snip] > > It's really easy to do. Just see the sys/dev/cpufreq/ichss.c file. > Nate and all, I have a pleasure to announce first public release of FreeBSD nf2fsb cpufreq driver. It is based on cpufreq-nforce2 Linux driver mentioned above for FSB frequency control and on atxp1 Linux driver for core voltage control. Thanks for both to Sebastian Witt! The source code can be found here: http://oddity-e.topspin.kiev.ua/cgi-bin/cvsweb.cgi/nf2fsb/ How-to for *Linux* drivers can be found here: http://forums.gentoo.org/viewtopic-t-273047-highlight-atxp.html This driver works stable and solid for me, but I still would qualify it as alpha quality because of many issues that I am not sure about. This is perhaps an under-qualification, but you are warned. So I'd say that at this point it is intended only for those who like to hack software and play with hardware. That's why I do not provide any compilation and installation instructions :-) Only one hint: this driver uses SMBus to access ATXP1 chip, so you definitely need SMBus to work. I am using nfsmb driver found in CURRENT (it is by Ruslan Ermilov) with one change - instead of PCIR_BAR(4) and PCIR_BAR(5) I have 0x50 and 0x54. BTW, nfsmb compiles and works on 6.1 like charm. My SMBus controller is: nfsmb0@pci0:1:1: class=0x0c0500 card=0x1c02147b chip=0x006410de You need to make sure that nfsmb is loaded before cpufreq. If you decide to try this driver please do read the code, at least the comments marked with XXX. Do not forget "AS-IS" disclaimer as well :-) I would appreciate all feedback: trouble and success reports, comments, suggestions and patches. Naming suggestions are welcome too, there is something about "nf2fsb" that doesn't feel right. At the end some "screenshots" (powerd is running): $ dmesg | tail -3 nf2fsb0: on cpu0 nf2fsb0: FSB is at 166MHz, CPU is at 1830MHz, frequency multiplier is 11.0 nf2fsb0: ATXP1 was found on smbus0, core volatge will be changed along with FSB speed $ sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 1826/-1 1650/-1 1463/-1 $ sysctl dev.cpu.0.freq dev.cpu.0.freq: 1463 $ mbmon -c 1 Temp.= 29.0, 41.0, 0.0; Rot.= 2393, 1767, 0 Vcore = 1.46, 2.62; Volt. = 3.28, 5.05, 11.86, -11.71, -4.90 My system is NF7 and Athlon XP 2500+. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 9 09:51:03 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 964EC16A41A; Fri, 9 Jun 2006 09:51:03 +0000 (UTC) (envelope-from lkoeller@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41FE243D72; Fri, 9 Jun 2006 09:51:03 +0000 (GMT) (envelope-from lkoeller@FreeBSD.org) Received: from freefall.freebsd.org (lkoeller@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k599p31h017534; Fri, 9 Jun 2006 09:51:03 GMT (envelope-from lkoeller@freefall.freebsd.org) Received: (from lkoeller@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k599p3hI017533; Fri, 9 Jun 2006 09:51:03 GMT (envelope-from lkoeller) Date: Fri, 9 Jun 2006 09:51:03 +0000 From: Lars Koeller To: freebsd-acpi@freebsd.org, freebsd-bugs@freebsd.org Message-ID: <20060609095103.GA15857@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: lkoeller@freebsd.org, lars.koeller@uni-bielefeld.de Subject: Bug Report kern/98694 (please help) 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, 09 Jun 2006 09:51:03 -0000 Dear experts, please can you have a look at the bug report mentioned above? We have seven machines of this type running, serving more than 30.000 users with spam and virus scanning. I just updated the bug report. We have s short timeline, cause the new infrastructure in our data center should be go online soon. No we hit this bug/problem in FBSD 5.4/5.5. Sophos only supports FBSD 5 now, so we have no posibility to play around with 6.1. It would be very nice if someone could give us som support, to fix the problem. Many thanks and best regards Lars From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 9 12:54:23 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE94716A419; Fri, 9 Jun 2006 12:54:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50E7443D73; Fri, 9 Jun 2006 12:54:23 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k59CsKuh086886; Fri, 9 Jun 2006 08:54:21 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Fri, 9 Jun 2006 08:20:33 -0400 User-Agent: KMail/1.9.1 References: <20060604200834.8db4782c.nork@FreeBSD.org> In-Reply-To: <20060604200834.8db4782c.nork@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606090820.33793.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, 09 Jun 2006 08:54:21 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1523/Fri Jun 9 03:10:10 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Norikatsu Shigemura Subject: Re: FYI: Panasonic Toughbook CF-R4 can suspend/resume 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, 09 Jun 2006 12:54:24 -0000 On Sunday 04 June 2006 07:08, Norikatsu Shigemura wrote: > I confirmed 3rd generation CF-R4 (Panasonic Toughbook/ > Let's Note series, 2006 Spring Model) can suspend/resume:-) > with following settings. > > Add to /boot/loader.conf > - - - - - - - - - - - - - - - - > hint.apic.0.disabled="1" > hint.psm.0.flags="0x2000" > - - - - - - - - - - - - - - - - Does it work if you don't disable APIC? > And, mita-san (mita@FreeBSD.org) has CF-W4 (3rd > generation). It can suspend/resume:-), too. But Ume-san > (ume@) has CF-R4(1st generation), it cannot suspend/resume:-(. > Takahashi-san(nyan@) has CF-R3, same too:-(. > > I read /usr/src/sys/i386/i386/io_apic.c, and I'm suprised > following code: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > #define TODO printf("%s: not implemented!\n", __func__) > > static void > ioapic_suspend(struct intsrc *isrc) > { > TODO; > } > > static void > ioapic_resume(struct intsrc *isrc) > { > ioapic_program_intpin((struct ioapic_intsrc *)isrc); > } > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Hum.................... It's actually implemented. However, the atpic isn't being reinitialized on resume and that's probably the problem. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 9 12:54:24 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A24116A41F; Fri, 9 Jun 2006 12:54:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2FF043D79; Fri, 9 Jun 2006 12:54:23 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k59CsKui086886; Fri, 9 Jun 2006 08:54:22 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Fri, 9 Jun 2006 08:33:11 -0400 User-Agent: KMail/1.9.1 References: <20060609095103.GA15857@freefall.freebsd.org> In-Reply-To: <20060609095103.GA15857@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606090833.12159.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, 09 Jun 2006 08:54:23 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1523/Fri Jun 9 03:10:10 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Lars Koeller , lars.koeller@uni-bielefeld.de Subject: Re: Bug Report kern/98694 (please help) 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, 09 Jun 2006 12:54:24 -0000 On Friday 09 June 2006 05:51, Lars Koeller wrote: > > Dear experts, > > please can you have a look at the bug report mentioned above? > > We have seven machines of this type running, serving more > than 30.000 users with spam and virus scanning. I just updated the > bug report. > > We have s short timeline, cause the new infrastructure in our data center > should be go online soon. No we hit this bug/problem in FBSD 5.4/5.5. > > Sophos only supports FBSD 5 now, so we have no posibility to play around > with 6.1. > > It would be very nice if someone could give us som support, to fix the problem. > > Many thanks and best regards The clock handling changes in 6 that would fix your problem are too big to backport to 5.x I'm afraid. I can look at your panic in the non-ACPI case if you can capture a dmesg with ACPI disabled (including the panic messages) over a serial console. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 9 14:09:30 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B87116A41F; Fri, 9 Jun 2006 14:09:30 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E96A943D72; Fri, 9 Jun 2006 14:09:29 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k59E9S4j089225; Fri, 9 Jun 2006 09:09:29 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44898121.1020909@centtech.com> Date: Fri, 09 Jun 2006 09:09:37 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.2 (X11/20060506) MIME-Version: 1.0 To: Lars Koeller References: <20060609095103.GA15857@freefall.freebsd.org> <200606090833.12159.jhb@freebsd.org> In-Reply-To: <200606090833.12159.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1523/Fri Jun 9 02:10:10 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-acpi@freebsd.org Subject: Re: Bug Report kern/98694 (please help) 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, 09 Jun 2006 14:09:30 -0000 John Baldwin wrote: > On Friday 09 June 2006 05:51, Lars Koeller wrote: >> Dear experts, >> >> please can you have a look at the bug report mentioned above? >> >> We have seven machines of this type running, serving more >> than 30.000 users with spam and virus scanning. I just updated the >> bug report. >> >> We have s short timeline, cause the new infrastructure in our data center >> should be go online soon. No we hit this bug/problem in FBSD 5.4/5.5. >> >> Sophos only supports FBSD 5 now, so we have no posibility to play around >> with 6.1. >> >> It would be very nice if someone could give us som support, to fix the > problem. >> Many thanks and best regards > > The clock handling changes in 6 that would fix your problem are too big to > backport to 5.x I'm afraid. I can look at your panic in the non-ACPI case if > you can capture a dmesg with ACPI disabled (including the panic messages) > over a serial console. I think sophos works fine with 6.1 with the compat5x stuff - Lars, have you given it a try? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 9 14:44:10 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8AA316A4A7; Fri, 9 Jun 2006 14:44:10 +0000 (UTC) (envelope-from lars.koeller@uni-bielefeld.de) Received: from smtp-relay1.uni-bielefeld.de (smtp-relay1.uni-bielefeld.de [129.70.4.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id F284543D73; Fri, 9 Jun 2006 14:44:08 +0000 (GMT) (envelope-from lars.koeller@uni-bielefeld.de) Received: from pmxchannel-daemon.mail1.hrz.uni-bielefeld.de by mail1.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 2.09 (built Nov 18 2005)) id <0J0L0090BKUYTR@mail1.hrz.uni-bielefeld.de>; Fri, 09 Jun 2006 16:42:34 +0200 (MEST) Received: from rayadm.hrz.uni-bielefeld.de ([129.70.202.15]) by mail1.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 2.09 (built Nov 18 2005)) with ESMTPP id <0J0L00JLDKUX2Z@mail1.hrz.uni-bielefeld.de>; Fri, 09 Jun 2006 16:42:33 +0200 (MEST) Received: from rayadm.hrz.uni-bielefeld.de (lkoeller@localhost) by rayadm.hrz.uni-bielefeld.de (8.11.7p2+Sun/8.11.7) with ESMTP id k59EgWT14574; Fri, 09 Jun 2006 16:42:33 +0200 (MEST) Date: Fri, 09 Jun 2006 16:42:32 +0200 From: Lars =?iso-8859-1?Q?K=F6ller?= X-Face: eCcoCV}FjV*O{6>[1$XP/e%]TJhEw2MF33dFh)^HM7Gfd=[/(4+0a$~ Sender: lars.koeller@uni-bielefeld.de To: John Baldwin Message-id: <200606091442.k59EgWT14574@rayadm.hrz.uni-bielefeld.de> MIME-version: 1.0 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Level: X-UniBi-Spam-Level: , 7% X-UniBi-Spam-Rules: __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_24 0 X-UniBi-Deliver: Tag X-UniBi-EnvFrom: lars.koeller@uni-bielefeld.de X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.9.71432, vscan3.hrz.uni-bielefeld.de Cc: freebsd-acpi@freebsd.org, Lars Koeller , lars.koeller@uni-bielefeld.de Subject: Re: Bug Report kern/98694 (please help) 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, 09 Jun 2006 14:44:10 -0000 ---------- Hi John, thanks for your help! In reply to John Baldwin who wrote: > > Sophos only supports FBSD 5 now, so we have no posibility to play around > > with 6.1. > > > > It would be very nice if someone could give us som support, to fix the > problem. > > > > Many thanks and best regards > > The clock handling changes in 6 that would fix your problem are too big to > backport to 5.x I'm afraid. I can look at your panic in the non-ACPI case if O.k. as stated above, it's not an option for us cause of the sophos support. No hotfix possible? ;-) > you can capture a dmesg with ACPI disabled (including the panic messages) > over a serial console. No problem comming soon ...... Copyright (c) 1992-2006 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 5.5-RELEASE-p1 #3: Tue Jun 6 15:52:17 CEST 2006 root@pmx2.hrz.uni-bielefeld.de:/opt/tmp/obj/usr/src/sys/PMX Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2400.10-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 2147483648 (2048 MB) avail memory = 2095943680 (1998 MB) MPTable: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 6 cpu1 (AP): APIC ID: 0 ioapic0: Assuming intbase of 0 ioapic1: Assuming intbase of 16 ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard cpu1 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: at device 4.0 (no driver attached) atapci0: port 0x1400-0x140f,0x376,0x170-0x 177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ohci0: mem 0xf8021000-0xf8021fff irq 9 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered isab0: at device 15.3 on pci0 isa0: on isab0 pcib3: pcibus 3 on motherboard pci3: on pcib3 asr0: mem 0xfc000000-0xfdffffff,0xfb000000-0xfbfffff f,0xfa500000-0xfa5fffff irq 24 at device 8.0 on pci3 asr0: ADAPTEC 2010S FW Rev. FS11, 2 channel, 256 CCBs, Protocol I2O pcib4: pcibus 4 on motherboard pir0: on motherboard $PIR: BIOS IRQ 24 for 3.8.INTA is not valid for link 0x18 pci4: on pcib4 Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 06 instruction pointer = 0x58:0x3a73 stack pointer = 0x10:0xeda frame pointer = 0x10:0xf16 code segment = base 0xc00f0000, limit 0xffff, type 0x1b = DPL 0, pres 1, def32 0, gran 0 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 9 panic: general protection fault cpuid = 0 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Have a nice weekend Lars From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 9 16:34:29 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11F5716A4E0 for ; Fri, 9 Jun 2006 16:34:29 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE5A443D70 for ; Fri, 9 Jun 2006 16:34:27 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA00690; Fri, 09 Jun 2006 19:34:25 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4489A310.4050202@icyb.net.ua> Date: Fri, 09 Jun 2006 19:34:24 +0300 From: Andriy Gapon User-Agent: Thunderbird 1.5.0.2 (X11/20060512) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, Nate Lawson Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: Subject: cpufreq and lapic timer 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, 09 Jun 2006 16:34:29 -0000 Nate, guys, in 6.1 we by default use LAPIC timer now and I wonder what can affect its frequency. The reason I am asking is that it seems that it starts to work slower if I use my nf2fsb cpufreq driver and change FSB (and thus CPU_ frequency. Some data: $ date ; sleep 300 ; date Fri 9 Jun 2006 19:16:41 EEST Fri 9 Jun 2006 19:22:55 EEST $ bc scale=5 300 / 374 .80213 133 / 166 .80120 I.e. it seems that LAPIC timer runs slower by the same factor that frequency is changed. Any recommendations ? ideas ? Thank you. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 9 22:33:23 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 501EC16A41B for ; Fri, 9 Jun 2006 22:33:23 +0000 (UTC) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E443F43D73 for ; Fri, 9 Jun 2006 22:33:20 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5E35D72DA2; Fri, 9 Jun 2006 15:31:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5C49872DA1; Fri, 9 Jun 2006 15:31:54 -0700 (PDT) Date: Fri, 9 Jun 2006 15:31:54 -0700 (PDT) From: Doug White To: Fred Koschara In-Reply-To: <6.1.2.0.1.20060606011859.0b62f0a0@mail.FKEInternet.com> Message-ID: <20060609152626.U60598@carver.gumbysoft.com> References: <6.1.2.0.1.20060606011859.0b62f0a0@mail.FKEInternet.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org Subject: Re: FreeBSD 6.0, ThinkPad 600, dc0: watchdog timeout - 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: Fri, 09 Jun 2006 22:33:23 -0000 On Tue, 6 Jun 2006, Fred Koschara wrote: > I just purchased another ThinkPad 600 and installed FreeBSD 6.0, expecting it > would go as smoothly as had my previous installations of FreeBSD on my Web, > database and nameservers, on the desktop machine on which I'm experimenting > with FreeBSD programming, and on the Dell Latitude where FreeBSD is one of > the 5 operating systems I have installed. The TP600s require some special hacks to get going. I have a 600E that I put 6.1 on a couple of weeks ago and needed to do the following: 1. Update to the latest BIOS and embedded controller firmware. 2. Boot into DOS with the PS2.EXE tool and disable all of the devices you aren't using. Make sure at least 3 IRQs are assigned to PCI (I have 9, 10, and 11 assigned). 3. Add 'hw.cbb.memory=0xd8000' to /boot/loader.conf. Boot with that and it should work even with ACPI. If you search around you might find a suggestion to add a bunch of hw.pci.link type loader.conf tunables. I haven't found this to be necessary if there are sufficient resources available. The only casualty appears to be sound, but I can live without that. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 10 00:29:05 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A399C16A41F for ; Sat, 10 Jun 2006 00:29:05 +0000 (UTC) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF3F043D73 for ; Sat, 10 Jun 2006 00:29:04 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (ppp-71-139-110-14.dsl.snfc21.pacbell.net [71.139.110.14]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k5A0SwqL001022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Jun 2006 17:28:59 -0700 Message-ID: <448A11E6.7040508@root.org> Date: Fri, 09 Jun 2006 17:27:18 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Doug White References: <6.1.2.0.1.20060606011859.0b62f0a0@mail.FKEInternet.com> <20060609152626.U60598@carver.gumbysoft.com> In-Reply-To: <20060609152626.U60598@carver.gumbysoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Fred Koschara Subject: Re: FreeBSD 6.0, ThinkPad 600, dc0: watchdog timeout - 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: Sat, 10 Jun 2006 00:29:05 -0000 Doug White wrote: > On Tue, 6 Jun 2006, Fred Koschara wrote: > >> I just purchased another ThinkPad 600 and installed FreeBSD 6.0, >> expecting it would go as smoothly as had my previous installations of >> FreeBSD on my Web, database and nameservers, on the desktop machine on >> which I'm experimenting with FreeBSD programming, and on the Dell >> Latitude where FreeBSD is one of the 5 operating systems I have >> installed. Thanks for providing your experience, Doug. > The TP600s require some special hacks to get going. I have a 600E that I > put 6.1 on a couple of weeks ago and needed to do the following: > > 1. Update to the latest BIOS and embedded controller firmware. This is ALWAYS #1 on the list of solutions, don't submit a complaint until you've done this. > 2. Boot into DOS with the PS2.EXE tool and disable all of the devices > you aren't using. Make sure at least 3 IRQs are assigned to PCI (I have > 9, 10, and 11 assigned). 3. Add 'hw.cbb.memory=0xd8000' to > /boot/loader.conf. You probably just have to disable the 2ndary ATA bus (the one on the docking station). Or maybe acpi_dock (only in -current) would help. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 10 16:34:17 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE3A616A4C9 for ; Sat, 10 Jun 2006 16:34:17 +0000 (UTC) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40CA544AB4 for ; Sat, 10 Jun 2006 08:27:01 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (ppp-71-139-110-14.dsl.snfc21.pacbell.net [71.139.110.14]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k5A8QnqL009053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Jun 2006 01:26:55 -0700 Message-ID: <448A81E4.8080303@root.org> Date: Sat, 10 Jun 2006 01:25:08 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: "Stephane E. Potvin" References: <44874358.6050608@videotron.ca> <44876932.9000108@videotron.ca> In-Reply-To: <44876932.9000108@videotron.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: [patch] Support for asymetrical per-cpu Cx states 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, 10 Jun 2006 16:34:18 -0000 Stephane E. Potvin wrote: > Stephane E. Potvin wrote: >> What started as a quick check why my laptop was not giving me Cx states >> higher than C1 turned out in a major rework of the way the acpi_cpu >> driver works. Thanks for this effort! I will review and get back to you. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 10 17:48:08 2006 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25FE616A479; Sat, 10 Jun 2006 17:48:08 +0000 (UTC) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7CDB48376; Sat, 10 Jun 2006 17:45:27 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (ppp-71-139-110-14.dsl.snfc21.pacbell.net [71.139.110.14]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k5AHjQqL014504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Jun 2006 10:45:26 -0700 Message-ID: <448B04D0.1040302@root.org> Date: Sat, 10 Jun 2006 10:43:44 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org Subject: resume changes, please test 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, 10 Jun 2006 17:48:08 -0000 I've committed some overall minor changes to the resume assembly code as a result of a code review. Please test to be sure nothing was broken, and perhaps something got improved along the way. Now there is also a tunable/sysctl "debug.acpi.resume_beep". Setting it to 1 will beep the pc speaker very early in resume so we can figure out if hangs on resume are a driver or acpi problem. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 10 20:09:39 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 443A016A478 for ; Sat, 10 Jun 2006 20:09:39 +0000 (UTC) (envelope-from gjukema@jukeware.com) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC16E43F76 for ; Sat, 10 Jun 2006 20:08:39 +0000 (GMT) (envelope-from gjukema@jukeware.com) Received: from pd4mr1so.prod.shaw.ca (pd4mr1so-qfe3.prod.shaw.ca [10.0.141.212]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0N00MJ2UMFW0E0@l-daemon> for freebsd-acpi@freebsd.org; Sat, 10 Jun 2006 14:08:39 -0600 (MDT) Received: from pn2ml9so.prod.shaw.ca ([10.0.121.7]) by pd4mr1so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0N00IQMUMFQQI0@pd4mr1so.prod.shaw.ca> for freebsd-acpi@freebsd.org; Sat, 10 Jun 2006 14:08:39 -0600 (MDT) Received: from [192.168.0.5] ([24.67.104.42]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0N0020UUMEJN60@l-daemon> for freebsd-acpi@freebsd.org; Sat, 10 Jun 2006 14:08:39 -0600 (MDT) Date: Sat, 10 Jun 2006 13:04:31 -0700 From: Geoff To: freebsd-acpi@freebsd.org Message-id: <448B25CF.40900@jukeware.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit User-Agent: Thunderbird 1.5.0.2 (X11/20060510) Subject: Acer Aspire 3620 - battery life, power management 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, 10 Jun 2006 20:09:39 -0000 Hi all, I'm trying to get my battery life to work, as well as other power management stuff like auto-shutdown/suspend, etc. I've been searching for a while, and read through http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html. I looked for a BIOS update, and there wasn't one on the Asus website for my notebook. I'm running FreeBSD 6.1-RELEASE (installed via PCBSD). Output of uname -a : FreeBSD PCBSD.localhost 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Mon May 22 08:46:45 PDT 2006 boot@PCBSD.localhost:/usr/obj/usr/src/sys/GENERIC i386 Here's the output from acpconf -i0: Design capacity: 0 mWh Last full capacity: 0 mWh Technology: primary (non-rechargeable) Design voltage: 0 mV Capacity (warn): 0 mWh Capacity (low): 0 mWh Low/warn granularity: 0 mWh Warn/full granularity: 0 mWh Model number: Serial number: Type: OEM info: State: not present Voltage: 12576 mV I've uploaded the file from acpidump, dmesg.boot and the output from compiling iasl to : http://www.jukeware.com/acer_aspire_3620.tar I get these messages all the time (included in the dmesg.boot also): ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPCB.EC0_.BAT0._STA] (Node 0xc477c900), AE_NO_HARDWARE_RESPONSE ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.LPCB.EC0_.BAT0._STA] (Node 0xc477c900), AE_NO_HARDWARE_RESPONSE Anyway, it would be great if there was a work-around patch that I could apply to my asl file that could get the battery and power management stuff working, similar to http://lists.freebsd.org/mailman/htdig/freebsd-acpi/2005-November/002193.html. Please let me know if there is anything I can do to help solve this. Thank very much for your help, Geoff From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 10 20:36:02 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6668C16AED7; Sat, 10 Jun 2006 20:36:02 +0000 (UTC) (envelope-from fkeinternet@FKEInternet.com) Received: from Huntington.FKEInternet.com (ns1.fkeinternet.com [206.135.8.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E555845A43; Sat, 10 Jun 2006 10:26:20 +0000 (GMT) (envelope-from fkeinternet@FKEInternet.com) Received: from Dozer.FKEInternet.com (office.fkeinternet.com [206.135.8.68]) by Huntington.FKEInternet.com (8.13.6/8.12.9) with ESMTP id k5AAQJro008578; Sat, 10 Jun 2006 06:26:19 -0400 (EDT) (envelope-from fkeinternet@FKEInternet.com) Message-Id: <6.1.2.0.1.20060610061002.03b4ca30@mail.FKEInternet.com> X-Sender: fkeinternet@mail.FKEInternet.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 10 Jun 2006 06:26:18 -0400 To: John Baldwin , freebsd-acpi@freebsd.org From: Fred Koschara In-Reply-To: <200606070808.56332.jhb@freebsd.org> References: <6.1.2.0.1.20060606011859.0b62f0a0@mail.FKEInternet.com> <200606070808.56332.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: FreeBSD 6.0, ThinkPad 600, dc0: watchdog timeout - 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: Sat, 10 Jun 2006 20:36:03 -0000 Hello John -- I captured the dmesg output for ACPI, no boot fix no ACPI, no boot fix ACPI, boot fixed no ACPI, boot fixed The files are at http://fkeinternet.com/support/ where you will find a link= =20 to 20060607.London.FKEinternet.com.ThinkPad600.dmesg.files.tar.gz which=20 contains the debugging information. In each case, I also included the=20 corresponding loader.conf file, similarly named so it will be obvious which= =20 one is which. FYI, my immediate problem was relieved by information I received from Bj=F6r= n=20 K=F6nig on the freebsd-questions mail list. He wrote: >Hello, > >I had a Thinkpad 600 and a lot of problems too, especially with networking= =20 >and the cardbus. It received the impression that the chipset of the 600 is= =20 >totally broken. The revisited successor 600E doesn't make so much trouble= =20 >at all. > >Add the following lines to /boot/loader.conf, restart and see what=20 >happens. These lines solved some of my problems regarding unreliable=20 >networking. > > hw.cbb.start_memory=3D0xd8000 > hw.pci.link.LNKA.irq=3D11 > hw.pci.link.LNKB.irq=3D11 > hw.pci.link.LNKC.irq=3D11 > hw.pci.link.LNKD.irq=3D11 > >Regards >Bj=F6rn Even though I am now able to get my ThinkPad to boot FreeBSD 6.1 (I=20 upgraded after solving the boot issue), I am posting this information in=20 the hopes that the contribution will help support FreeBSD on a wider range= =20 of hardware. I think FreeBSD is an excellent operating system, and will do= =20 what I can, when I can, to further its development. -- Fred Koschara At 08:08 AM 6/7/2006, John Baldwin wrote: >Please provide verbose dmesg's for the ACPI and non-ACPI cases and please. >Preferably upload them somewhere and provide the URLs since the mailing= lists >often drop attachments. Thanks! > >-- >John Baldwin >_______________________________________________ >On Tuesday 06 June 2006 01:19, Fred Koschara wrote: > > I just purchased another ThinkPad 600 and installed FreeBSD 6.0, > > When I boot FreeBSD with ACPI disabled (option 2), it reports several > > unknown devices in the PCI PnP scan (not surprising) - and the EtherJet > > works correctly. (Gnome comes up quickly, also.) However, when I boot > > with ACPI enabled (option 1), the EtherJet cannot connect. I booted= with > > verbose logging, and noticed a couple of things: There are 4 devices,= in > > addition to the cardbus device, assigned to irq 9 (which is the irq= being > > used for the network connection, from what I can see), and FreeBSD says= =20 > the > > cardbus device is 16 bits, not 32 bits. > > Please advise if any further information would be helpful in resolving= =20 > this > > problem - should I send the verbose dmesg output? dmesg with and= without > > ACPI, for comparison? > > > > Thanks for any suggestions and support! > > > > -- Fred Koschara ________________________________________________________________________ Ignorance can easily be cured by knowledge, stupidity is generally only=20 cured by death... Truth and Falsehood were bathing. Falsehood came out of the water first and= =20 dressed herself in Truth's clothes. Truth, unwilling to put on the garments= =20 of Falsehood, went naked. (Author Unknown) The "war on terror" is a sham: There is no real protection against=20 suicidal maniacs spurred on by creative madmen. In the end, the only=20 outcomes will be the destruction of the American economy due to pouring a=20 bankrupting stream of wealth into a bottomless pit, and the final=20 destruction of personal liberty in the name of "security." (When was the=20 last time you were asked for "Your papers, please?" - er, that is, "License= =20 and registration?") FKE Internet, Web hosting for space related businesses
Domain registration - $15.95/year, $29.95 for 2 years http://FKEinternet.com For private sector (commercial) space development, visit http://www.L5Development.com For your daily dose of art, try http://PhotoByFred.com L5 Software Development - "out of this world" sites and software http://www.L5Software.com How much did your last traffic ticket cost you? http://www.StopHighwayRobbery.com FredLines(tm), T-Shirts For the Thinking Mind(tm) http://www.FredLines-TShirts.com From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 10 22:24:32 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3894616A41B; Sat, 10 Jun 2006 22:24:32 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7D5443D45; Sat, 10 Jun 2006 22:24:31 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.6/8.13.6/NinthNine) with ESMTP id k5AMOUrJ070831; Sun, 11 Jun 2006 07:24:30 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 11 Jun 2006 07:24:29 +0900 From: Norikatsu Shigemura To: John Baldwin Message-Id: <20060611072429.607d9efa.nork@FreeBSD.org> In-Reply-To: <200606090820.33793.jhb@freebsd.org> References: <20060604200834.8db4782c.nork@FreeBSD.org> <200606090820.33793.jhb@freebsd.org> X-Mailer: Sylpheed version 2.2.5 (GTK+ 2.8.18; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Sun, 11 Jun 2006 07:24:30 +0900 (JST) Cc: freebsd-acpi@FreeBSD.org, nork@FreeBSD.org Subject: Re: FYI: Panasonic Toughbook CF-R4 can suspend/resume 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, 10 Jun 2006 22:24:32 -0000 On Fri, 9 Jun 2006 08:20:33 -0400 John Baldwin wrote: > On Sunday 04 June 2006 07:08, Norikatsu Shigemura wrote: > > I confirmed 3rd generation CF-R4 (Panasonic Toughbook/ > > Let's Note series, 2006 Spring Model) can suspend/resume:-) > > with following settings. > > Add to /boot/loader.conf > > - - - - - - - - - - - - - - - - > > hint.apic.0.disabled="1" > > hint.psm.0.flags="0x2000" > > - - - - - - - - - - - - - - - - > Does it work if you don't disable APIC? Almost works, but freezed after resume. So I didn't notice that CF-RF can suspend/resume. Because APIC is defalut option on 6.x kernel configuration file. And I heard 'hint.apic.0.disabled' advice from rushani@.