From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 20 11:06:46 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCC65106569B for ; Mon, 20 Oct 2008 11:06:46 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AA8268FC1A for ; Mon, 20 Oct 2008 11:06:46 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id m9KB6k8l082563 for ; Mon, 20 Oct 2008 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id m9KB6kOh082559 for freebsd-acpi@FreeBSD.org; Mon, 20 Oct 2008 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Oct 2008 11:06:46 GMT Message-Id: <200810201106.m9KB6kOh082559@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2008 11:06:46 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be o kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 f kern/67309 acpi zzz reboot computer (ACPI S3) o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 41 problems total. From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 21 12:06:18 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCC88106567E for ; Tue, 21 Oct 2008 12:06:18 +0000 (UTC) (envelope-from lme@FreeBSD.org) Received: from mail.0x20.net (unknown [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5EBD08FC1A for ; Tue, 21 Oct 2008 12:06:18 +0000 (UTC) (envelope-from lme@FreeBSD.org) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mail.0x20.net (Postfix) with ESMTP id 400DD3A581 for ; Tue, 21 Oct 2008 14:06:17 +0200 (CEST) Received: from i011-63.fin-nrw.de (i011-63.fin-nrw.de [193.109.238.130]) by 0x20.net (Horde MIME library) with HTTP; Tue, 21 Oct 2008 14:06:17 +0200 Message-ID: <20081021140617.ejzk8i5wpskksc4w@0x20.net> X-Priority: 3 (Normal) Date: Tue, 21 Oct 2008 14:06:17 +0200 From: Lars Engels To: acpi@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_15pe04xec4v4"; protocol="application/pgp-signature"; micalg="pgp-sha1" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) Cc: Subject: acpi_tz1: _CRT value is absurd, ignored (256.0C) 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, 21 Oct 2008 12:06:18 -0000 This message is in MIME format and has been PGP signed. --=_15pe04xec4v4 Content-Type: text/plain; charset=ISO-8859-15; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, every few seconds I get this kernel message on the console: acpi_tz1: _CRT value is absurd, ignored (256.0C) FreeBSD 8-CURRENT HP Compaq 8710w Notebook # sysctl hw.acpi.thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 48.0C hw.acpi.thermal.tz0.active: 5 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 105.0C hw.acpi.thermal.tz0._ACx: 98.0C 88.0C 76.0C 65.0C 55.0C 45.0C -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 70.0C hw.acpi.thermal.tz1.active: 2 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 97.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: -1 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ hw.acpi.thermal.tz1._ACx: 89.0C 83.0C 60.0C 50.0C 40.0C -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 1 hw.acpi.thermal.tz1._TC2: 2 hw.acpi.thermal.tz1._TSP: 300 hw.acpi.thermal.tz2.temperature: 59.0C hw.acpi.thermal.tz2.active: -1 hw.acpi.thermal.tz2.passive_cooling: 0 hw.acpi.thermal.tz2.thermal_flags: 0 hw.acpi.thermal.tz2._PSV: -1 hw.acpi.thermal.tz2._HOT: -1 hw.acpi.thermal.tz2._CRT: 102.0C hw.acpi.thermal.tz2._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz2._TC1: -1 hw.acpi.thermal.tz2._TC2: -1 hw.acpi.thermal.tz2._TSP: -1 hw.acpi.thermal.tz3.temperature: 44.0C hw.acpi.thermal.tz3.active: -1 hw.acpi.thermal.tz3.passive_cooling: 0 hw.acpi.thermal.tz3.thermal_flags: 0 hw.acpi.thermal.tz3._PSV: 95.0C hw.acpi.thermal.tz3._HOT: -1 hw.acpi.thermal.tz3._CRT: 105.0C hw.acpi.thermal.tz3._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz3._TC1: 1 hw.acpi.thermal.tz3._TC2: 2 hw.acpi.thermal.tz3._TSP: 300 hw.acpi.thermal.tz4.temperature: 34.4C hw.acpi.thermal.tz4.active: -1 hw.acpi.thermal.tz4.passive_cooling: 0 hw.acpi.thermal.tz4.thermal_flags: 0 hw.acpi.thermal.tz4._PSV: 60.0C hw.acpi.thermal.tz4._HOT: -1 hw.acpi.thermal.tz4._CRT: 102.0C hw.acpi.thermal.tz4._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz4._TC1: 1 hw.acpi.thermal.tz4._TC2: 2 hw.acpi.thermal.tz4._TSP: 300 hw.acpi.thermal.tz5.temperature: 70.0C hw.acpi.thermal.tz5.active: -1 hw.acpi.thermal.tz5.passive_cooling: 0 hw.acpi.thermal.tz5.thermal_flags: 0 hw.acpi.thermal.tz5._PSV: -1 hw.acpi.thermal.tz5._HOT: -1 hw.acpi.thermal.tz5._CRT: 110.0C hw.acpi.thermal.tz5._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz5._TC1: -1 hw.acpi.thermal.tz5._TC2: -1 hw.acpi.thermal.tz5._TSP: -1 Is there a way to fix that or prevent the tz from being probed? Please CC me, I am not subscribed to the list. --=20 Lars Engels lme@FreeBSD.org --=_15pe04xec4v4 Content-Type: application/pgp-signature Content-Description: Digitale PGP-Unterschrift Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkj9xbkACgkQKc512sD3afg5eACfZvxu1eFvCLPbvwyzvPi5GCyu QckAnRybjM2xv0kBTa90uCrymstRLWkN =gz/2 -----END PGP SIGNATURE----- --=_15pe04xec4v4-- From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 21 16:28:41 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id D7F30106566C; Tue, 21 Oct 2008 16:28:40 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org, freebsd-amd64@FreeBSD.org Date: Tue, 21 Oct 2008 12:28:28 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200810211228.31028.jkim@FreeBSD.org> Cc: peter@FreeBSD.org Subject: Semi-working patch for amd64 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: Tue, 21 Oct 2008 16:28:41 -0000 I was working on suspend/resume support for amd64 and this is the result. It works with a modified QEMU (QEMU does not support S3) but real boxes that I have don't seem to like it (e.g., broken BIOSes). If there is someone interested in finishing it off or giving it a try, the patch is here: http://people.freebsd.org/~jkim/amd64_suspend.diff Please note this patch is heavily inspired by Takanori Watanabe's SMP patch for i386: http://docs.freebsd.org/cgi/mid.cgi?200805131125.m4DBPu1q092741 and large portion is shamlessly stolen from Peter Wemm's AP boot code for amd64. ;-) Cheers, Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 21 17:47:31 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C0451065672 for ; Tue, 21 Oct 2008 17:47:31 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi025.prodigy.net (nlpi025.sbcis.sbc.com [207.115.36.54]) by mx1.freebsd.org (Postfix) with ESMTP id 212D48FC21 for ; Tue, 21 Oct 2008 17:47:31 +0000 (UTC) (envelope-from nate@root.org) Received: from [127.0.0.1] (root.org [208.72.84.34]) (authenticated bits=0) by nlpi025.prodigy.net (8.13.8 smtpauth/dk/8.13.8) with ESMTP id m9LHW9uD005144; Tue, 21 Oct 2008 12:32:15 -0500 Message-ID: <48FE121B.3000206@root.org> Date: Tue, 21 Oct 2008 10:32:11 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Lars Engels References: <20081021140617.ejzk8i5wpskksc4w@0x20.net> In-Reply-To: <20081021140617.ejzk8i5wpskksc4w@0x20.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org Subject: Re: acpi_tz1: _CRT value is absurd, ignored (256.0C) 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, 21 Oct 2008 17:47:31 -0000 Lars Engels wrote: > Hi all, > > every few seconds I get this kernel message on the console: > > acpi_tz1: _CRT value is absurd, ignored (256.0C) > > FreeBSD 8-CURRENT > HP Compaq 8710w Notebook > > # sysctl hw.acpi.thermal > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 48.0C > hw.acpi.thermal.tz0.active: 5 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 105.0C > hw.acpi.thermal.tz0._ACx: 98.0C 88.0C 76.0C 65.0C 55.0C 45.0C -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: -1 > hw.acpi.thermal.tz0._TC2: -1 > hw.acpi.thermal.tz0._TSP: -1 > hw.acpi.thermal.tz1.temperature: 70.0C > hw.acpi.thermal.tz1.active: 2 > hw.acpi.thermal.tz1.passive_cooling: 1 > hw.acpi.thermal.tz1.thermal_flags: 0 > hw.acpi.thermal.tz1._PSV: 97.0C > hw.acpi.thermal.tz1._HOT: -1 > hw.acpi.thermal.tz1._CRT: -1 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > hw.acpi.thermal.tz1._ACx: 89.0C 83.0C 60.0C 50.0C 40.0C -1 -1 -1 -1 -1 > hw.acpi.thermal.tz1._TC1: 1 > hw.acpi.thermal.tz1._TC2: 2 > hw.acpi.thermal.tz1._TSP: 300 We could try to work around it in the tz poll routine. Or, you could set the _CRT value to something reasonable via sysctl. man acpi_thermal to see how. You have to specify user_override to unlock the sysctl. 105C seems reasonable based on other settings in tz2-3. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 22 08:15:08 2008 Return-Path: Delivered-To: acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3F2B1065685 for ; Wed, 22 Oct 2008 08:15:08 +0000 (UTC) (envelope-from lme@FreeBSD.org) Received: from mail.0x20.net (unknown [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 635298FC39 for ; Wed, 22 Oct 2008 08:15:08 +0000 (UTC) (envelope-from lme@FreeBSD.org) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mail.0x20.net (Postfix) with ESMTP id 158343A581; Wed, 22 Oct 2008 10:15:07 +0200 (CEST) Received: from i011-63.fin-nrw.de (i011-63.fin-nrw.de [193.109.238.130]) by 0x20.net (Horde MIME library) with HTTP; Wed, 22 Oct 2008 10:15:06 +0200 Message-ID: <20081022101506.zfazdtjeskwg8sgc@0x20.net> X-Priority: 3 (Normal) Date: Wed, 22 Oct 2008 10:15:06 +0200 From: Lars Engels To: Nate Lawson References: <20081021140617.ejzk8i5wpskksc4w@0x20.net> <48FE121B.3000206@root.org> In-Reply-To: <48FE121B.3000206@root.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_7fm4qq2xbpss"; protocol="application/pgp-signature"; micalg="pgp-sha1" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) Cc: acpi@FreeBSD.org Subject: Re: acpi_tz1: _CRT value is absurd, ignored (256.0C) 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, 22 Oct 2008 08:15:08 -0000 This message is in MIME format and has been PGP signed. --=_7fm4qq2xbpss Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Nate Lawson : >> hw.acpi.thermal.tz1._CRT: -1 >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> hw.acpi.thermal.tz1._ACx: 89.0C 83.0C 60.0C 50.0C 40.0C -1 -1 -1 -1 -1 >> hw.acpi.thermal.tz1._TC1: 1 >> hw.acpi.thermal.tz1._TC2: 2 >> hw.acpi.thermal.tz1._TSP: 300 > > We could try to work around it in the tz poll routine. Or, you could > set the _CRT value to something reasonable via sysctl. man acpi_thermal > to see how. You have to specify user_override to unlock the sysctl. > 105C seems reasonable based on other settings in tz2-3. Setting the sysctl doesn't work: Oct 22 09:50:15 NB0117232 sudo: engels : TTY=3Dpts/3 ; =20 PWD=3D/usr/home/engels ; USER=3Droot ; COMMAND=3D/sbin/sysctl =20 hw.acpi.thermal.user_override=3D1 Oct 22 09:50:45 NB0117232 kernel: acpi_tz1: _CRT value is absurd, =20 ignored (256.0C) Oct 22 09:50:55 NB0117232 sudo: engels : TTY=3Dpts/3 ; =20 PWD=3D/usr/home/engels ; USER=3Droot ; COMMAND=3D/sbin/sysctl =20 hw.acpi.thermal.tz1._CRT=3D105C Oct 22 09:51:03 NB0117232 kernel: acpi_tz1: _CRT value is absurd, =20 ignored (256.0C) hw.acpi.thermal.tz1._CRT: -1 It is only set to the overridden value for a moment and is then set =20 back to -1. So a workaround in the code would be nice. --=20 Lars Engels lme@FreeBSD.org --=_7fm4qq2xbpss Content-Type: application/pgp-signature Content-Description: Digitale PGP-Unterschrift Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkj+4QoACgkQKc512sD3afj5ngCfdfN422rFxXStTKHfHCtxYvDu GucAoMF1ViQ+hN/H1vs87chkQNMuzmWg =7YvO -----END PGP SIGNATURE----- --=_7fm4qq2xbpss-- From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 22 14:10:12 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24341106567E for ; Wed, 22 Oct 2008 14:10:12 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id C67498FC22 for ; Wed, 22 Oct 2008 14:10:11 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so571726ywe.13 for ; Wed, 22 Oct 2008 07:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=1nXAQR4/YLBK6aNY+UV0ToBxhy4+pNSyKawpBiQdxUQ=; b=cQ2RrNmDbmxLiJR2DLyzDL3UbdvdetW4T8NBN/cjiH/+qTdska9X8+ouX/gZytZbH+ y5LIpnCT5noladPIMcazEaYKhLQ0eo9epEwZZXwJrw6y7sSy34AE87wZ3mY2GtxLW+NY XscX4ovzd7lxgJU9FRE2tZVSBFcwKyH3WoBs4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=nZrDKrcLJyz8WTzT4yCRl/iQH5EDyNDTzSm6Jn+qlR77AH+3C50mW2iNj+ZWc8KiE6 nits/7ydfavj2ni+A+NU0055K51MMXqplpvgvmpRDRSfApuhHH+bXaiBz0jPK39Ne3nJ A6qPoiDHiqtEmqxpxv7qolXh4rlVmgKVvt1OQ= Received: by 10.231.19.3 with SMTP id y3mr6020777iba.8.1224683280785; Wed, 22 Oct 2008 06:48:00 -0700 (PDT) Received: from ?10.0.3.231? (pool-70-111-10-128.nwrk.east.verizon.net [70.111.10.128]) by mx.google.com with ESMTPS id 8sm9353078ywg.6.2008.10.22.06.47.59 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Oct 2008 06:48:00 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Lars Engels In-Reply-To: <20081022101506.zfazdtjeskwg8sgc@0x20.net> References: <20081021140617.ejzk8i5wpskksc4w@0x20.net> <48FE121B.3000206@root.org> <20081022101506.zfazdtjeskwg8sgc@0x20.net> Content-Type: text/plain; charset=utf-8 Date: Wed, 22 Oct 2008 09:47:43 -0400 Message-Id: <1224683263.2199.24.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: acpi@FreeBSD.org Subject: Re: acpi_tz1: _CRT value is absurd, ignored (256.0C) 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, 22 Oct 2008 14:10:12 -0000 On Wed, 2008-10-22 at 10:15 +0200, Lars Engels wrote: > Quoting Nate Lawson : > > > >> hw.acpi.thermal.tz1._CRT: -1 > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> hw.acpi.thermal.tz1._ACx: 89.0C 83.0C 60.0C 50.0C 40.0C -1 -1 -1 -1 -1 > >> hw.acpi.thermal.tz1._TC1: 1 > >> hw.acpi.thermal.tz1._TC2: 2 > >> hw.acpi.thermal.tz1._TSP: 300 > > > > We could try to work around it in the tz poll routine. Or, you could > > set the _CRT value to something reasonable via sysctl. man acpi_thermal > > to see how. You have to specify user_override to unlock the sysctl. > > 105C seems reasonable based on other settings in tz2-3. > > Setting the sysctl doesn't work: > > Oct 22 09:50:15 NB0117232 sudo: engels : TTY=pts/3 ; > PWD=/usr/home/engels ; USER=root ; COMMAND=/sbin/sysctl > hw.acpi.thermal.user_override=1 > Oct 22 09:50:45 NB0117232 kernel: acpi_tz1: _CRT value is absurd, > ignored (256.0C) > Oct 22 09:50:55 NB0117232 sudo: engels : TTY=pts/3 ; > PWD=/usr/home/engels ; USER=root ; COMMAND=/sbin/sysctl > hw.acpi.thermal.tz1._CRT=105C > Oct 22 09:51:03 NB0117232 kernel: acpi_tz1: _CRT value is absurd, > ignored (256.0C) > > hw.acpi.thermal.tz1._CRT: -1 > > It is only set to the overridden value for a moment and is then set > back to -1. I suspect that ASL re-evaluates _CRT and tells FreeBSD to re-read it based on some event. I would have expected 'user_override' to block the update. I might be completely off the mark, though. > > So a workaround in the code would be nice. In the time being you should be able to dump our ASL (see Handbook for instructions), look for something like Scope (\_TZ) { ... ThermalZone (THM1) { ... Method (_CRT, 0, NotSerialized) { Return () } where THM1 is just a name, so it could be different in your case. You need to find one for the zone #1 inside the Scope(\TZ) definition. I think FreeBSD numbers them sequentially, regardless of the name, so this would be the second ThermalZone definition in the scope. If you want 105C, put Return(0xEC6); in there. The value 0xEC6 = 105 * 0xA + 0xAAC. If _CRT method is not there, you should be safe to add one, consisting of the single return statement. You would have to recompile ASL and set it to override on boot (see Handbook). As the side note, thermal chapter of the ACPI spec is both short and readable, so if you'd rather understand where did all of this come from, I would recommend reading through it. HTH, -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 22 16:51:11 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 053D11065674 for ; Wed, 22 Oct 2008 16:51:11 +0000 (UTC) (envelope-from olivier@aixmarseille.com) Received: from royale.aixmarseille.com (royale.aixmarseille.com [82.243.78.230]) by mx1.freebsd.org (Postfix) with ESMTP id B5E908FC22 for ; Wed, 22 Oct 2008 16:51:10 +0000 (UTC) (envelope-from olivier@aixmarseille.com) Received: from royale.aixmarseille.com ([192.168.10.11]) by royale.aixmarseille.com with esmtpa (Exim 4.69) (envelope-from ) id 1KsgRd-0001sR-Vz for freebsd-acpi@FreeBSD.org; Wed, 22 Oct 2008 18:20:26 +0200 Message-ID: <48FF52C9.3040105@aixmarseille.com> Date: Wed, 22 Oct 2008 18:20:25 +0200 From: Olivier Fauchon User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Crash after undocking Dell Lat. d430 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, 22 Oct 2008 16:51:11 -0000 Hi. I'm running SMP FreeBSD7 on Dell Latitude d430. I have dell dockstation (for connecting office display, keyboard mouse ...) Last week, I tried to undock the laptop (While working in X session) , and laptop crashed. Do FreeBSD support docking/undocking, can you tell me if it's transparent, or if there are commands to run before undocking ? maybe ways to debug it ? The dockstation seems to have a 'undock' button which doesn't react under freebsd. Thanks -- Olivier Fauchon Freelance System-Network Admin Phone: +33 610 493 763 http://www.aixmarseille.com From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 22 20:03:15 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCB001065675; Wed, 22 Oct 2008 20:03:15 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3588FC19; Wed, 22 Oct 2008 20:03:14 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 225853438; Wed, 22 Oct 2008 22:03:13 +0300 Message-ID: <48FF78F0.2090801@FreeBSD.org> Date: Wed, 22 Oct 2008 22:03:12 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: Jung-uk Kim References: <1224616985.00027652.1224606603@10.7.7.3> In-Reply-To: <1224616985.00027652.1224606603@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, peter@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Semi-working patch for amd64 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: Wed, 22 Oct 2008 20:03:15 -0000 Hi. Jung-uk Kim wrote: > I was working on suspend/resume support for amd64 and this is the > result. It works with a modified QEMU (QEMU does not support S3) but > real boxes that I have don't seem to like it (e.g., broken BIOSes). > If there is someone interested in finishing it off or giving it a > try, the patch is here: > > http://people.freebsd.org/~jkim/amd64_suspend.diff I have tried it on my Acer TM6292. S1/S2 are unsupported. On S3 system successfully got down, but on wakeup button, two seconds after power up, even without video initialization, it shut down, reset and then started usual boot. I have tried both original and updated BIOS, without any difference. Can I give you any other help? -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 22 20:23:19 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id C14BB1065670; Wed, 22 Oct 2008 20:23:18 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Alexander Motin Date: Wed, 22 Oct 2008 16:23:07 -0400 User-Agent: KMail/1.6.2 References: <1224616985.00027652.1224606603@10.7.7.3> <48FF78F0.2090801@FreeBSD.org> In-Reply-To: <48FF78F0.2090801@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200810221623.09613.jkim@FreeBSD.org> Cc: freebsd-acpi@FreeBSD.org, peter@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: Semi-working patch for amd64 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: Wed, 22 Oct 2008 20:23:19 -0000 On Wednesday 22 October 2008 03:03 pm, Alexander Motin wrote: > Hi. > > Jung-uk Kim wrote: > > I was working on suspend/resume support for amd64 and this is the > > result. It works with a modified QEMU (QEMU does not support S3) > > but real boxes that I have don't seem to like it (e.g., broken > > BIOSes). If there is someone interested in finishing it off or > > giving it a try, the patch is here: > > > > http://people.freebsd.org/~jkim/amd64_suspend.diff > > I have tried it on my Acer TM6292. S1/S2 are unsupported. On S3 > system successfully got down, but on wakeup button, two seconds > after power up, even without video initialization, it shut down, > reset and then started usual boot. I have tried both original and > updated BIOS, without any difference. > > Can I give you any other help? When you do 'sysctl debug.acpi.suspend_bounce=1' and 'acpiconf -s 3', does it bounce back? If it does not, there are other problems, e.g., device drivers. On my desktop, for example, vga(4) tries to restore previous state while resuming but it hangs system. In fact, I believe ISA-era EGA/VGA save/restore routines do not work for modern graphics cards at all. :-( Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 22 21:20:40 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10E95106567E; Wed, 22 Oct 2008 21:20:40 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 941CE8FC16; Wed, 22 Oct 2008 21:20:38 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 225861485; Thu, 23 Oct 2008 00:20:37 +0300 Message-ID: <48FF9925.4090007@FreeBSD.org> Date: Thu, 23 Oct 2008 00:20:37 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: Jung-uk Kim References: <1224616985.00027652.1224606603@10.7.7.3> <48FF78F0.2090801@FreeBSD.org> <200810221623.09613.jkim@FreeBSD.org> In-Reply-To: <200810221623.09613.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, peter@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: Semi-working patch for amd64 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: Wed, 22 Oct 2008 21:20:40 -0000 Jung-uk Kim wrote: > When you do 'sysctl debug.acpi.suspend_bounce=1' and 'acpiconf -s 3', > does it bounce back? If it does not, there are other problems, e.g., > device drivers. On my desktop, for example, vga(4) tries to restore > previous state while resuming but it hangs system. In fact, I > believe ISA-era EGA/VGA save/restore routines do not work for modern > graphics cards at all. :-( Test passed from both console and XOrg. I have integrated i965GM video. Here is verbose messages from that trip "there and back again": Oct 23 00:11:55 mavbook acpi: suspend at 20081023 00:11:55 Oct 23 00:11:59 mavbook kernel: bge0: Disabling fastboot Oct 23 00:11:59 mavbook kernel: bge0: link DOWN Oct 23 00:11:59 mavbook kernel: pci0:4:0:0: Transition from D0 to D3 Oct 23 00:11:59 mavbook kernel: iwn0: iwn_mem_lock: could not lock memory Oct 23 00:11:59 mavbook last message repeated 17 times Oct 23 00:11:59 mavbook kernel: pci0:5:0:0: Transition from D0 to D3 Oct 23 00:11:59 mavbook kernel: usb4: interrupt while not operating ignored Oct 23 00:11:59 mavbook last message repeated 3 times Oct 23 00:11:59 mavbook kernel: fwohci0: fwohci_pci_suspend Oct 23 00:11:59 mavbook kernel: pci0:10:9:0: Transition from D0 to D3 Oct 23 00:11:59 mavbook kernel: usb4: interrupt while not operating ignored Oct 23 00:11:59 mavbook last message repeated 3 times Oct 23 00:12:00 mavbook kernel: vga0: saving 68 bytes of video state Oct 23 00:12:00 mavbook kernel: pci0:0:2:0: Transition from D0 to D3 Oct 23 00:12:00 mavbook kernel: pci0:0:2:1: Transition from D0 to D3 Oct 23 00:12:00 mavbook kernel: pci0:0:26:7: Transition from D0 to D3 Oct 23 00:12:00 mavbook kernel: acpi: bad write to port 0x080 (32), val 0xbb Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D0 to D3 Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition from D0 to D3 Oct 23 00:12:06 mavbook kernel: pci0:0:2:0: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: pci0:0:2:1: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: acpi: bad write to port 0x080 (32), val 0xaa Oct 23 00:12:06 mavbook kernel: pci0:0:26:7: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: hdac0: GPIO init: data=0x00000000 mask=0x00000000 dir=0x00000000 Oct 23 00:12:06 mavbook kernel: hdac0: GPIO commit: data=0x00000001 mask=0x00000001 dir=0x00000001 Oct 23 00:12:06 mavbook kernel: hdac0: Enabling headphone/speaker audio routing switching: Oct 23 00:12:06 mavbook kernel: hdac0: as=0 sense nid=20 [UNSOL] Oct 23 00:12:06 mavbook kernel: hdac0: Pin sense: nid=20 res=0x80000000 Oct 23 00:12:06 mavbook kernel: pci0:4:0:0: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: bge0: link UP Oct 23 00:12:06 mavbook kernel: bge0: Disabling fastboot Oct 23 00:12:06 mavbook kernel: bge0: link DOWN Oct 23 00:12:06 mavbook kernel: bge0: Disabling fastboot Oct 23 00:12:06 mavbook kernel: pci0:5:0:0: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: pci0:10:9:0: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: fwohci0: Phy 1394a available S400, 3 ports. Oct 23 00:12:06 mavbook kernel: fwohci0: Link S400, max_rec 2048 bytes. Oct 23 00:12:06 mavbook kernel: fwohci0: Initiate bus reset Oct 23 00:12:06 mavbook kernel: fwohci0: BUS reset Oct 23 00:12:06 mavbook kernel: fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode Oct 23 00:12:06 mavbook kernel: ata0: reiniting channel .. Oct 23 00:12:06 mavbook kernel: ata0: reset tp1 mask=03 ostat0=50 ostat1=00 Oct 23 00:12:06 mavbook kernel: ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb Oct 23 00:12:06 mavbook kernel: ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 Oct 23 00:12:06 mavbook kernel: ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 Oct 23 00:12:06 mavbook kernel: iwn0: RF switch: radio fdiisraebwlierde Oct 23 00:12:06 mavbook kernel: 0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) Oct 23 00:12:06 mavbook kernel: firewire0: bus manager 0 (me) Oct 23 00:12:06 mavbook kernel: fwohci0: phy int Oct 23 00:12:06 mavbook kernel: ugen0: at uhub2 port 3 (addr 2) disconnected Oct 23 00:12:06 mavbook kernel: bge0: link UP Oct 23 00:12:06 mavbook kernel: bge0: 2 link states coalesced Oct 23 00:12:06 mavbook kernel: bge0: link state changed to UP Oct 23 00:12:06 mavbook kernel: ugen1: at uhub0 port 1 (addr 2) disconnected Oct 23 00:12:06 mavbook kernel: ugen1: detached Oct 23 00:12:06 mavbook kernel: ums0: at uhub3 port 2 (addr 2) disconnected Oct 23 00:12:06 mavbook kernel: acd0: setting PIO4 on ICH8M chip Oct 23 00:12:06 mavbook kernel: ugen0: detached Oct 23 00:12:06 mavbook kernel: ukbd0: at uhub4 port 1 (addr 2) disconnected Oct 23 00:12:06 mavbook kernel: ums0: detached Oct 23 00:12:06 mavbook kernel: ukbd0: detached Oct 23 00:12:06 mavbook kernel: uhid0: at uhub4 port 1 (addr 2) disconnected Oct 23 00:12:06 mavbook kernel: uhid0: detached Oct 23 00:12:06 mavbook kernel: acd0: setting UDMA33 on ICH8M chip Oct 23 00:12:06 mavbook kernel: ata0: reinit done .. Oct 23 00:12:06 mavbook kernel: ata2: reiniting channel .. Oct 23 00:12:06 mavbook kernel: ata2: SATA connect time=0ms Oct 23 00:12:06 mavbook kernel: ata2: BUSY wait time=1ms Oct 23 00:12:06 mavbook kernel: ata2: SIGNATURE: 00000101 Oct 23 00:12:06 mavbook kernel: ata2: ahci_reset devices=00000001 Oct 23 00:12:06 mavbook kernel: ata2: reinit done .. Oct 23 00:12:06 mavbook kernel: ata3: reiniting channel .. Oct 23 00:12:06 mavbook kernel: ata3: SATA connect status=00000004 Oct 23 00:12:06 mavbook kernel: ata3: phy reset found no device Oct 23 00:12:06 mavbook kernel: ata3: reinit done .. Oct 23 00:12:06 mavbook kernel: ata4: reiniting channel .. Oct 23 00:12:06 mavbook kernel: ata4: SATA connect status=00000000 Oct 23 00:12:06 mavbook kernel: ata4: phy reset found no device Oct 23 00:12:06 mavbook kernel: ata4: reinit done .. Oct 23 00:12:06 mavbook kernel: atkbd: the current kbd controller command byte 0047 Oct 23 00:12:06 mavbook kernel: atkbd: keyboard ID 0x41ab (2) Oct 23 00:12:06 mavbook kernel: kbdc: RESET_KBD return code:00fa Oct 23 00:12:06 mavbook kernel: kbdc: RESET_KBD status:00aa Oct 23 00:12:06 mavbook kernel: battery0: battery initialization start Oct 23 00:12:06 mavbook kernel: battery0: battery initialization done, tried 1 times Oct 23 00:12:07 mavbook kernel: drm0: [MPSAFE] Oct 23 00:12:07 mavbook kernel: drm0: [ITHREAD] Oct 23 00:12:07 mavbook kernel: ugen0: on uhub2 Oct 23 00:12:07 mavbook kernel: ugen1: on uhub0 Oct 23 00:12:07 mavbook kernel: ums0: on uhub3 Oct 23 00:12:07 mavbook kernel: ums0: 16 buttons and Z dir. Oct 23 00:12:07 mavbook acpi: resumed at 20081023 00:12:07 Oct 23 00:12:07 mavbook root: Unknown USB device: vendor 0x064e product 0xa101 bus uhub2 Oct 23 00:12:07 mavbook root: Unknown USB device: vendor 0x147e product 0x2016 bus uhub0 Oct 23 00:12:07 mavbook root: Unknown USB device: vendor 0x046d product 0xc50e bus uhub3 Oct 23 00:12:09 mavbook root: Unknown USB device: vendor 0x046d product 0xc313 bus uhub4 Oct 23 00:12:09 mavbook kernel: ukbd0: on uhub4 Oct 23 00:12:09 mavbook kernel: kbd2 at ukbd0 Oct 23 00:12:09 mavbook kernel: kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 Oct 23 00:12:09 mavbook kernel: uhid0: on uhub4 -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 22 21:27:52 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B554710656A1; Wed, 22 Oct 2008 21:27:52 +0000 (UTC) (envelope-from nate@root.org) Received: from fulgencio.claresco.com (209-128-117-004.BAYAREA.NET [209.128.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9516C8FC0C; Wed, 22 Oct 2008 21:27:52 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.8.5] (fw.claresco.com [209.128.117.3]) by fulgencio.claresco.com (Postfix) with ESMTP id 1730E1339C4; Wed, 22 Oct 2008 14:27:52 -0700 (PDT) Message-ID: <48FF9AFA.3030201@root.org> Date: Wed, 22 Oct 2008 14:28:26 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Alexander Motin References: <1224616985.00027652.1224606603@10.7.7.3> <48FF78F0.2090801@FreeBSD.org> <200810221623.09613.jkim@FreeBSD.org> <48FF9925.4090007@FreeBSD.org> In-Reply-To: <48FF9925.4090007@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: Semi-working patch for amd64 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: Wed, 22 Oct 2008 21:27:52 -0000 Alexander Motin wrote: > Jung-uk Kim wrote: >> When you do 'sysctl debug.acpi.suspend_bounce=1' and 'acpiconf -s 3', >> does it bounce back? If it does not, there are other problems, e.g., >> device drivers. On my desktop, for example, vga(4) tries to restore >> previous state while resuming but it hangs system. In fact, I believe >> ISA-era EGA/VGA save/restore routines do not work for modern graphics >> cards at all. :-( > > Test passed from both console and XOrg. I have integrated i965GM video. > > Here is verbose messages from that trip "there and back again": > > Oct 23 00:11:55 mavbook acpi: suspend at 20081023 00:11:55 > Oct 23 00:12:00 mavbook kernel: vga0: saving 68 bytes of video state > Oct 23 00:12:00 mavbook kernel: pci0:0:2:0: Transition from D0 to D3 > Oct 23 00:12:00 mavbook kernel: pci0:0:2:1: Transition from D0 to D3 > Oct 23 00:12:00 mavbook kernel: pci0:0:26:7: Transition from D0 to D3 > Oct 23 00:12:00 mavbook kernel: acpi: bad write to port 0x080 (32), val > 0xbb > Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D0 to D3 > Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition from D0 to D3 > Oct 23 00:12:06 mavbook kernel: pci0:0:2:0: Transition from D3 to D0 > Oct 23 00:12:06 mavbook kernel: pci0:0:2:1: Transition from D3 to D0 > Oct 23 00:12:06 mavbook kernel: acpi: bad write to port 0x080 (32), val > 0xaa > Oct 23 00:12:06 mavbook kernel: pci0:0:26:7: Transition from D3 to D0 > Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D3 to D0 > Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition from D3 to D0 That's kind of weird. The above devices were turned off (D3) then back on again (D0). I'm wondering about that blocked write also. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 22 22:33:52 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0D9E1065681; Wed, 22 Oct 2008 22:33:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2FF508FC19; Wed, 22 Oct 2008 22:33:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m9MMXjQr020559; Wed, 22 Oct 2008 18:33:46 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Wed, 22 Oct 2008 18:13:38 -0400 User-Agent: KMail/1.9.7 References: <1224616985.00027652.1224606603@10.7.7.3> <48FF9925.4090007@FreeBSD.org> <48FF9AFA.3030201@root.org> In-Reply-To: <48FF9AFA.3030201@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810221813.39270.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 22 Oct 2008 18:33:46 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8470/Wed Oct 22 11:13:42 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Alexander Motin , freebsd-amd64@freebsd.org Subject: Re: Semi-working patch for amd64 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: Wed, 22 Oct 2008 22:33:52 -0000 On Wednesday 22 October 2008 05:28:26 pm Nate Lawson wrote: > Alexander Motin wrote: > > Jung-uk Kim wrote: > >> When you do 'sysctl debug.acpi.suspend_bounce=1' and 'acpiconf -s 3', > >> does it bounce back? If it does not, there are other problems, e.g., > >> device drivers. On my desktop, for example, vga(4) tries to restore > >> previous state while resuming but it hangs system. In fact, I believe > >> ISA-era EGA/VGA save/restore routines do not work for modern graphics > >> cards at all. :-( > > > > Test passed from both console and XOrg. I have integrated i965GM video. > > > > Here is verbose messages from that trip "there and back again": > > > > Oct 23 00:11:55 mavbook acpi: suspend at 20081023 00:11:55 > > > Oct 23 00:12:00 mavbook kernel: vga0: saving 68 bytes of video state > > Oct 23 00:12:00 mavbook kernel: pci0:0:2:0: Transition from D0 to D3 > > Oct 23 00:12:00 mavbook kernel: pci0:0:2:1: Transition from D0 to D3 > > Oct 23 00:12:00 mavbook kernel: pci0:0:26:7: Transition from D0 to D3 > > Oct 23 00:12:00 mavbook kernel: acpi: bad write to port 0x080 (32), val > > 0xbb > > Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D0 to D3 > > Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition from D0 to D3 > > > Oct 23 00:12:06 mavbook kernel: pci0:0:2:0: Transition from D3 to D0 > > Oct 23 00:12:06 mavbook kernel: pci0:0:2:1: Transition from D3 to D0 > > Oct 23 00:12:06 mavbook kernel: acpi: bad write to port 0x080 (32), val > > 0xaa > > Oct 23 00:12:06 mavbook kernel: pci0:0:26:7: Transition from D3 to D0 > > Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D3 to D0 > > Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition from D3 to D0 > > That's kind of weird. The above devices were turned off (D3) then back > on again (D0). I'm wondering about that blocked write also. I think they were probably off before due to not having a driver and we turned them back on, noticed there wasn't a driver, and turned them back off again. If so, that should be fixable. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 22 23:44:23 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 642BF106566B; Wed, 22 Oct 2008 23:44:21 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Wed, 22 Oct 2008 19:44:08 -0400 User-Agent: KMail/1.6.2 References: <1224616985.00027652.1224606603@10.7.7.3> <48FF9925.4090007@FreeBSD.org> <48FF9AFA.3030201@root.org> In-Reply-To: <48FF9AFA.3030201@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200810221944.13406.jkim@FreeBSD.org> Cc: Alexander Motin , freebsd-amd64@freebsd.org Subject: Re: Semi-working patch for amd64 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: Wed, 22 Oct 2008 23:44:23 -0000 On Wednesday 22 October 2008 05:28 pm, Nate Lawson wrote: > Alexander Motin wrote: > > Jung-uk Kim wrote: > >> When you do 'sysctl debug.acpi.suspend_bounce=1' and 'acpiconf > >> -s 3', does it bounce back? If it does not, there are other > >> problems, e.g., device drivers. On my desktop, for example, > >> vga(4) tries to restore previous state while resuming but it > >> hangs system. In fact, I believe ISA-era EGA/VGA save/restore > >> routines do not work for modern graphics cards at all. :-( > > > > Test passed from both console and XOrg. I have integrated i965GM > > video. > > > > Here is verbose messages from that trip "there and back again": > > > > Oct 23 00:11:55 mavbook acpi: suspend at 20081023 00:11:55 > > > > Oct 23 00:12:00 mavbook kernel: vga0: saving 68 bytes of video > > state Oct 23 00:12:00 mavbook kernel: pci0:0:2:0: Transition from > > D0 to D3 Oct 23 00:12:00 mavbook kernel: pci0:0:2:1: Transition > > from D0 to D3 Oct 23 00:12:00 mavbook kernel: pci0:0:26:7: > > Transition from D0 to D3 Oct 23 00:12:00 mavbook kernel: acpi: > > bad write to port 0x080 (32), val 0xbb > > Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D0 > > to D3 Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition > > from D0 to D3 > > > > Oct 23 00:12:06 mavbook kernel: pci0:0:2:0: Transition from D3 to > > D0 Oct 23 00:12:06 mavbook kernel: pci0:0:2:1: Transition from D3 > > to D0 Oct 23 00:12:06 mavbook kernel: acpi: bad write to port > > 0x080 (32), val 0xaa > > Oct 23 00:12:06 mavbook kernel: pci0:0:26:7: Transition from D3 > > to D0 Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition > > from D3 to D0 Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: > > Transition from D3 to D0 > > That's kind of weird. The above devices were turned off (D3) then > back on again (D0). I'm wondering about that blocked write also. The port 0x80 is usually used for BIOS debugging. http://www.coreboot.org/FAQ#POST_card Probably BIOS developer forgot to comment out the lines. :-) Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 23 00:48:38 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B1CD106567A; Thu, 23 Oct 2008 00:48:38 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 607508FC0A; Thu, 23 Oct 2008 00:48:38 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id m9N0Oe601954; Wed, 22 Oct 2008 17:24:40 -0700 (PDT) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id m9N0OeX06794; Wed, 22 Oct 2008 17:24:40 -0700 (PDT) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Wed, 22 Oct 2008 17:24:39 -0700 (PDT) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Jung-uk Kim In-Reply-To: <200810221944.13406.jkim@FreeBSD.org> Message-ID: References: <1224616985.00027652.1224606603@10.7.7.3> <48FF9925.4090007@FreeBSD.org> <48FF9AFA.3030201@root.org> <200810221944.13406.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org, Alexander Motin , freebsd-amd64@freebsd.org Subject: Re: Semi-working patch for amd64 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, 23 Oct 2008 00:48:38 -0000 On Wed, 22 Oct 2008, Jung-uk Kim wrote: > The port 0x80 is usually used for BIOS debugging. > > http://www.coreboot.org/FAQ#POST_card > > Probably BIOS developer forgot to comment out the lines. :-) Or it's been left in as a diagnostic tool. My motherboard has a built-in LED display wired up to port 0x80, and it flashes various numbers as it passes different stages of booting. Useful for detecting various types of failure, nicer than the beep codes. It can also be handy for kernel debugging, when you can't use printf. A very thoughtful feature on the motherboard designer's part. Btw, I'm interested to test the patch, and I'll do so when I have a chance. This is a feature I've been awaiting for some time. -- Nate Eldredge neldredge@math.ucsd.edu From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 23 03:07:57 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3086D1065671 for ; Thu, 23 Oct 2008 03:07:57 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.246]) by mx1.freebsd.org (Postfix) with ESMTP id CCA618FC2A for ; Thu, 23 Oct 2008 03:07:56 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by hs-out-0708.google.com with SMTP id 54so29008hsz.11 for ; Wed, 22 Oct 2008 20:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=sUi44HGyLndJqfDHUQ63ENY9rAb/OuUDFiT+MeuijYA=; b=A9ivRp6K20pc1R/5Cw307daROBQZxsU+sOuihg4ZOVFZ7MImdSqPkcNIsC9qJ5OkEP rbDL3y30sopbqTp7x4cTeSPN8IfgMCK710MkPnjS6tgPAi34HLWaB7JkP+1pTDDh1dS+ RnJKyEYgb4M/Djw+Xhb9RQFoNo61tvz2WpdZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=EAQFeJMm1kUj3OXSVtDHcLl/htR1/G4sVk3PpTy7HvtMBQk9HYMlCwow1f+cwWPExt lsEYfrmVpIRDwzXBkDhPYOe0rfZSq0jkILRzV0oUbnzYzOF1Va0CmAXbZFZNXpfwVbfW bA+EayiMczjgt41nsAYB3O5Jq+WRMOl8HXoqs= Received: by 10.90.79.12 with SMTP id c12mr7060agb.65.1224729739748; Wed, 22 Oct 2008 19:42:19 -0700 (PDT) Received: from ?10.0.3.231? (pool-70-111-10-128.nwrk.east.verizon.net [70.111.10.128]) by mx.google.com with ESMTPS id 36sm14311908aga.10.2008.10.22.19.42.18 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Oct 2008 19:42:19 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Olivier Fauchon In-Reply-To: <48FF52C9.3040105@aixmarseille.com> References: <48FF52C9.3040105@aixmarseille.com> Content-Type: text/plain; charset=utf-8 Date: Wed, 22 Oct 2008 22:42:02 -0400 Message-Id: <1224729722.1153.11.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: Crash after undocking Dell Lat. d430 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, 23 Oct 2008 03:07:57 -0000 On Wed, 2008-10-22 at 18:20 +0200, Olivier Fauchon wrote: > Hi. > > I'm running SMP FreeBSD7 on Dell Latitude d430. > > I have dell dockstation (for connecting office display, keyboard mouse ...) > > Last week, I tried to undock the laptop (While working in X session) , > and laptop crashed. > > Do FreeBSD support docking/undocking, can you tell me if it's > transparent, or if there are commands to run before undocking ? maybe > ways to debug it ? FWIW: I routinely dock and undock my ThinkPad X61. If I do not forget to unmount ATA drive in the UltraBay, or one of the USB drives, plugged into the dock, things work rather well. I normally plug my USB mouse into one of the dock's USB ports -- this does not seem to require any special handling. Is it possible that you have something in the dock that does not like being yanked? I woould recommend starting by comparing output of 'pciconf -l' in both states. I am tracking RELENG_7 somewhat lazily. > > The dockstation seems to have a 'undock' button which doesn't react > under freebsd. Mine actually does -- it turns off red led and unlocks the laptop. > > Thanks > > -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-acpi@FreeBSD.ORG Sat Oct 25 22:43:48 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B82DE106567E for ; Sat, 25 Oct 2008 22:43:48 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 73A738FC14 for ; Sat, 25 Oct 2008 22:43:47 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 226127437 for freebsd-acpi@FreeBSD.org; Sun, 26 Oct 2008 01:43:46 +0300 Message-ID: <4903A120.7040003@FreeBSD.org> Date: Sun, 26 Oct 2008 01:43:44 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org Content-Type: multipart/mixed; boundary="------------080606050200070300070407" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: PCIe bridges resources disappearing with ACPI enabled. 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, 25 Oct 2008 22:43:48 -0000 This is a multi-part message in MIME format. --------------080606050200070300070407 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hi. I have spent whole day trying to investigate strange problem of my Acer TM6292 laptop (965GM+ICH8M). When booted with ACPI enabled, all three of PCIe-to-PCIe bridges appearing completely without I/O resources: pcib1: irq 17 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 2 pcib1: subordinate bus 3 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode ... At the same time, with ACPI disabled, resources are present. There are some different problem with IRQ in that case, but it is another question, not so interesting to me. I have tried both IO and memory mapped PCIe configuration registers without success. I have made heavy digging trying to find where resources disappearing. I have even added debug printing inside pcireg_cfgwrite() and pciereg_cfgwrite() to trace if somebody erases it and found nothing. Nothing writes into that devices configuration registers. At this moment I am living with ugly hack found here: http://lists.freebsd.org/pipermail/freebsd-acpi/2008-May/004905.html, and I would be grateful if somebody give me a hint what is going on here and why Windows and Linux (according reports) work fine. Here is my pciconf -l: hostb0@pci0:0:0:0: class=0x060000 card=0x011b1025 chip=0x2a008086 rev=0x03 hdr=0x00 vgapci0@pci0:0:2:0: class=0x030000 card=0x011b1025 chip=0x2a028086 rev=0x03 hdr=0x00 vgapci1@pci0:0:2:1: class=0x038000 card=0x011b1025 chip=0x2a038086 rev=0x03 hdr=0x00 uhci0@pci0:0:26:0: class=0x0c0300 card=0x011b1025 chip=0x28348086 rev=0x03 hdr=0x00 uhci1@pci0:0:26:1: class=0x0c0300 card=0x011b1025 chip=0x28358086 rev=0x03 hdr=0x00 ehci0@pci0:0:26:7: class=0x0c0320 card=0x011b1025 chip=0x283a8086 rev=0x03 hdr=0x00 hdac0@pci0:0:27:0: class=0x040300 card=0x011b1025 chip=0x284b8086 rev=0x03 hdr=0x00 pcib1@pci0:0:28:0: class=0x060400 card=0x011b1025 chip=0x283f8086 rev=0x03 hdr=0x01 pcib2@pci0:0:28:2: class=0x060400 card=0x011b1025 chip=0x28438086 rev=0x03 hdr=0x01 pcib3@pci0:0:28:3: class=0x060400 card=0x011b1025 chip=0x28458086 rev=0x03 hdr=0x01 uhci2@pci0:0:29:0: class=0x0c0300 card=0x011b1025 chip=0x28308086 rev=0x03 hdr=0x00 uhci3@pci0:0:29:1: class=0x0c0300 card=0x011b1025 chip=0x28318086 rev=0x03 hdr=0x00 uhci4@pci0:0:29:2: class=0x0c0300 card=0x011b1025 chip=0x28328086 rev=0x03 hdr=0x00 ehci1@pci0:0:29:7: class=0x0c0320 card=0x011b1025 chip=0x28368086 rev=0x03 hdr=0x00 pcib4@pci0:0:30:0: class=0x060401 card=0x00000000 chip=0x24488086 rev=0xf3 hdr=0x01 isab0@pci0:0:31:0: class=0x060100 card=0x011b1025 chip=0x28158086 rev=0x03 hdr=0x00 atapci0@pci0:0:31:1: class=0x01018a card=0x011b1025 chip=0x28508086 rev=0x03 hdr=0x00 atapci1@pci0:0:31:2: class=0x010601 card=0x011b1025 chip=0x28298086 rev=0x03 hdr=0x00 none0@pci0:0:31:3: class=0x0c0500 card=0x011b1025 chip=0x283e8086 rev=0x03 hdr=0x00 bge0@pci0:4:0:0: class=0x020000 card=0x011b1025 chip=0x169314e4 rev=0x02 hdr=0x00 iwn0@pci0:5:0:0: class=0x028000 card=0x11018086 chip=0x42298086 rev=0x61 hdr=0x00 cbb0@pci0:10:1:0: class=0x060700 card=0x011b1025 chip=0x14101524 rev=0x01 hdr=0x02 none1@pci0:10:2:0: class=0x050100 card=0x011b1025 chip=0x07301524 rev=0x00 hdr=0x00 sdhci0@pci0:10:2:1: class=0x080501 card=0x011b1025 chip=0x07501524 rev=0x00 hdr=0x00 none2@pci0:10:2:2: class=0x050100 card=0x011b1025 chip=0x07201524 rev=0x00 hdr=0x00 sdhci1@pci0:10:2:3: class=0x050100 card=0x011b1025 chip=0x07511524 rev=0x00 hdr=0x00 fwohci0@pci0:10:9:0: class=0x0c0010 card=0x011b1025 chip=0x8024104c rev=0x00 hdr=0x00 Problematic devices are 0:28:0, 0:28:2, 0:28:3. What is also strange is that PCIe-to-PCI bridge 0:30:0 working just fine. ASL attached. -- Alexander Motin --------------080606050200070300070407--