From owner-freebsd-acpi@FreeBSD.ORG Sun May 13 09:23:37 2012 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 1F508106564A; Sun, 13 May 2012 09:23:37 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id D88A78FC16; Sun, 13 May 2012 09:23:34 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id q4D7v2wT022863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 May 2012 09:57:02 +0200 Received: from portgus.lan (17.Red-83-38-184.dynamicIP.rima-tde.net [83.38.184.17]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q4D7v0Bw012801 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 13 May 2012 09:57:01 +0200 Message-ID: <4FAF696D.3060806@entel.upc.edu> Date: Sun, 13 May 2012 09:57:33 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120422 Thunderbird/12.0 MIME-Version: 1.0 To: FreeBSD current , freebsd-acpi@freebsd.org References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> In-Reply-To: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Sun, 13 May 2012 09:57:02 +0200 (CEST) Cc: Mitsuru IWASAKI Subject: Re: [CFT] SMP/i386 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: Sun, 13 May 2012 09:23:37 -0000 Al 11/05/2012 04:10, En/na Mitsuru IWASAKI ha escrit: > Hi > > I've been working on suspend/resume for SMP/i386 for a week > and created patches against CURRENT, RELENG_9 and RELENG_8 > available at: > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511.diff > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-20120511.diff > > A lot of portion of the patches was ported from amd64. > Testing on Thinkpad X60 (Core Duo T2300), so far so good :) > > I'll commit them against CURRENT hopefully next week. > Reporting from an Acer Centrino Duo, running CURRENT r235266. The machine has an nvidia card (Ge7300go). The acpi_video and nvidia modules are there. I did test it a few times with X running (plain twm) and worked just fine. Setting hw.acpi.lid_switch_state=S3 allowed me to use the close-the-lid-to-sleep functionality. The problem comes when I suspend the machine in the console. The machine resumes fine (I can ping and ssh it) but the screen remains black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a console but X is running, after the resume I can CTRL+ALT+F9 and get my video back; then I can return to the console. If I don't have X running, I don't know how to get my console back. Thanks From owner-freebsd-acpi@FreeBSD.ORG Sun May 13 13:53:37 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32221106564A; Sun, 13 May 2012 13:53:37 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id DA8398FC0A; Sun, 13 May 2012 13:53:36 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4DDrTnN079627; Sun, 13 May 2012 22:53:29 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Sun, 13 May 2012 22:53:28 +0900 (JST) Message-Id: <20120513.225328.10294857.iwasaki@jp.FreeBSD.org> To: peter@rulingia.com From: Mitsuru IWASAKI In-Reply-To: <20120511112005.GA87299@server.rulingia.com> References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <20120511112005.GA87299@server.rulingia.com> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 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: Sun, 13 May 2012 13:53:37 -0000 Hi, Thanks for your report. From: Peter Jeremy Subject: Re: [CFT] SMP/i386 suspend/resume Date: Fri, 11 May 2012 21:20:05 +1000 Message-ID: <20120511112005.GA87299@server.rulingia.com> > On 2012-May-11 11:10:19 +0900, Mitsuru IWASAKI wrote: > >I've been working on suspend/resume for SMP/i386 for a week > >and created patches against CURRENT, RELENG_9 and RELENG_8 > >available at: > > Thank you for that. Since I was in the process of upgrading my > netbook (Acer Aspire One AOA-110 - Atom N270), I rolled your RELENG_8 > patch on top of r235229. > > Unfortunately, the result hasn't been a complete success. I can > suspend to S3 with no problems (though that worked before). The > resume is less successful. If X is running, I get a garbage screen. > If I suspend at a VTY, the screen comes back correctly but there is no > response from keyboard, touchpad or wired network (though it has the > correct lights). > > Let me know if you have any suggestions for debugging. I think graphic driver (or pic?) has some problems on resume and they are out of scope of my patches. HEAD and RELENG_9 have better support on interrupt re-enabling than RELENG_8 I think. Could you try them? And for ps/2 mouse, kernel option PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND would be useful. Thanks > > -- > Peter Jeremy From owner-freebsd-acpi@FreeBSD.ORG Sun May 13 13:59:18 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBB33106564A; Sun, 13 May 2012 13:59:18 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE838FC16; Sun, 13 May 2012 13:59:18 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4DDxHaY079665; Sun, 13 May 2012 22:59:17 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Sun, 13 May 2012 22:59:17 +0900 (JST) Message-Id: <20120513.225917.02304793.iwasaki@jp.FreeBSD.org> To: dhw@FreeBSD.org From: Mitsuru IWASAKI In-Reply-To: <20120511132257.GA96585@freefall.freebsd.org> References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <20120511132257.GA96585@freefall.freebsd.org> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [CFT] SMP/i386 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: Sun, 13 May 2012 13:59:18 -0000 Hi, Thanks for you report. From: David Wolfskill Subject: Re: [CFT] SMP/i386 suspend/resume Date: Fri, 11 May 2012 13:22:57 +0000 Message-ID: <20120511132257.GA96585@freefall.freebsd.org> > On Fri, May 11, 2012 at 11:10:19AM +0900, Mitsuru IWASAKI wrote: > > Hi > > > > I've been working on suspend/resume for SMP/i386 for a week > > and created patches against CURRENT, RELENG_9 and RELENG_8 > > available at: > > > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511.diff > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-20120511.diff > > ... > > I'm sorry to report that while head & stable/9 did work for me (see > previous notes in this thread), stable/8 did not. Well, suspend > seemed to, but on resume, the screen stayed dark and the machine > was (as far as I could tell without trying to ping it from another > machine) unresponsive. OK, we need some more investigation on RELENG_8 SMP. I think Core 2 Duo can run amd64, would like to confirm this problem can be reproduced only on i386 or not. Could you try same thing on amd64? Thanks > > This was on the same Dell Precision M4400 as before (Core(TM)2 Duo CPU > T9600), running: > > FreeBSD localhost 8.3-STABLE FreeBSD 8.3-STABLE #382 235262M: Fri May 11 04:45:52 EDT 2012 root@localhost:/common/S1/obj/usr/src/sys/CANARY i386 > > Peace, > david > -- > David H. Wolfskill dhw@freebsd.org > There is a use for spam: it helps identify spammers. > I have no use for spammers. > From owner-freebsd-acpi@FreeBSD.ORG Sun May 13 14:03:03 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41A6A106564A; Sun, 13 May 2012 14:03:03 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 158C78FC15; Sun, 13 May 2012 14:03:02 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q4DE32qL021203; Sun, 13 May 2012 07:03:02 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q4DE323f021202; Sun, 13 May 2012 07:03:02 -0700 (PDT) (envelope-from david) Date: Sun, 13 May 2012 07:03:02 -0700 From: David Wolfskill To: Mitsuru IWASAKI Message-ID: <20120513140302.GI13138@albert.catwhisker.org> References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <20120511132257.GA96585@freefall.freebsd.org> <20120513.225917.02304793.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="svExV93C05KqedWb" Content-Disposition: inline In-Reply-To: <20120513.225917.02304793.iwasaki@jp.FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org, dhw@FreeBSD.org Subject: Re: [CFT] SMP/i386 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: Sun, 13 May 2012 14:03:03 -0000 --svExV93C05KqedWb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 13, 2012 at 10:59:17PM +0900, Mitsuru IWASAKI wrote: > .... > OK, we need some more investigation on RELENG_8 SMP. > I think Core 2 Duo can run amd64, would like to confirm > this problem can be reproduced only on i386 or not. > Could you try same thing on amd64? Well, that will require a bit more work -- I'm pretty sure the hardware can run amd64, but I only have i386 inistalled presently. And I'm getting ready to head to the airport to fly back home now. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --svExV93C05KqedWb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+vvxUACgkQmprOCmdXAD3X2ACfdPO192dSLiJexjCjmkKf8UcX NZEAn03z3mmDsFaTRtDedcwVJdUP5jUV =cwGV -----END PGP SIGNATURE----- --svExV93C05KqedWb-- From owner-freebsd-acpi@FreeBSD.ORG Sun May 13 14:40:28 2012 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 4BA851065672; Sun, 13 May 2012 14:40:28 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id 014A58FC0C; Sun, 13 May 2012 14:40:27 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4DEeFsq079851; Sun, 13 May 2012 23:40:15 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Sun, 13 May 2012 23:40:14 +0900 (JST) Message-Id: <20120513.234014.26960250.iwasaki@jp.FreeBSD.org> To: gperez@entel.upc.edu From: Mitsuru IWASAKI In-Reply-To: <4FAF696D.3060806@entel.upc.edu> References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <4FAF696D.3060806@entel.upc.edu> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 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: Sun, 13 May 2012 14:40:28 -0000 Hi, Thanks for your report. From: Gustau P=E9rez i Querol Subject: Re: [CFT] SMP/i386 suspend/resume Date: Sun, 13 May 2012 09:57:33 +0200 Message-ID: <4FAF696D.3060806@entel.upc.edu> > Al 11/05/2012 04:10, En/na Mitsuru IWASAKI ha escrit: > > Hi > > > > I've been working on suspend/resume for SMP/i386 for a week > > and created patches against CURRENT, RELENG_9 and RELENG_8 > > available at: > > > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20= 120511.diff > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-2= 0120511.diff > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-2= 0120511.diff > > > > A lot of portion of the patches was ported from amd64. > > Testing on Thinkpad X60 (Core Duo T2300), so far so good :) > > > > I'll commit them against CURRENT hopefully next week. > > > = > Reporting from an Acer Centrino Duo, running CURRENT r235266. The = > machine has an nvidia card (Ge7300go). The acpi_video and nvidia modu= les = > are there. > = > I did test it a few times with X running (plain twm) and worked ju= st = > fine. Setting hw.acpi.lid_switch_state=3DS3 allowed me to use the = > close-the-lid-to-sleep functionality. > = > The problem comes when I suspend the machine in the console. The = > machine resumes fine (I can ping and ssh it) but the screen remains = > black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a = > console but X is running, after the resume I can CTRL+ALT+F9 and get = my = > video back; then I can return to the console. If I don't have X runni= ng, = > I don't know how to get my console back. I think this is graphic driver problem. nvidia's driver seems to have correct suspend/resume method. http://www.nvidia.com/object/freebsd_archive.html Have you try it? Thanks > = > Thanks > = > = From owner-freebsd-acpi@FreeBSD.ORG Sun May 13 15:01:00 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17CFE1065673; Sun, 13 May 2012 15:01:00 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id B814B8FC0A; Sun, 13 May 2012 15:00:59 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4DF0mlW079938; Mon, 14 May 2012 00:00:48 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Mon, 14 May 2012 00:00:48 +0900 (JST) Message-Id: <20120514.000048.08647576.iwasaki@jp.FreeBSD.org> To: david@catwhisker.org From: Mitsuru IWASAKI In-Reply-To: <20120513140302.GI13138@albert.catwhisker.org> References: <20120511132257.GA96585@freefall.freebsd.org> <20120513.225917.02304793.iwasaki@jp.FreeBSD.org> <20120513140302.GI13138@albert.catwhisker.org> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org, dhw@freebsd.org Subject: Re: [CFT] SMP/i386 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: Sun, 13 May 2012 15:01:00 -0000 Hi, From: David Wolfskill Subject: Re: [CFT] SMP/i386 suspend/resume Date: Sun, 13 May 2012 07:03:02 -0700 Message-ID: <20120513140302.GI13138@albert.catwhisker.org> > On Sun, May 13, 2012 at 10:59:17PM +0900, Mitsuru IWASAKI wrote: > > .... > > OK, we need some more investigation on RELENG_8 SMP. > > I think Core 2 Duo can run amd64, would like to confirm > > this problem can be reproduced only on i386 or not. > > Could you try same thing on amd64? > > Well, that will require a bit more work -- I'm pretty sure the hardware > can run amd64, but I only have i386 inistalled presently. And I'm > getting ready to head to the airport to fly back home now. Understood. I don't need to hurry on this. BTW, amd64 Live CD might be useful for this purpose. Thanks! > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-acpi@FreeBSD.ORG Sun May 13 18:21:15 2012 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 831541065674; Sun, 13 May 2012 18:21:15 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id F2BE68FC1B; Sun, 13 May 2012 18:21:14 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id q4DILD2H002578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 May 2012 20:21:13 +0200 Received: from [10.1.170.94] (99.Red-80-27-97.dynamicIP.rima-tde.net [80.27.97.99]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q4DIL9uQ022662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 May 2012 20:21:10 +0200 References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <4FAF696D.3060806@entel.upc.edu> <20120513.234014.26960250.iwasaki@jp.FreeBSD.org> In-Reply-To: <20120513.234014.26960250.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <9E61BC2D-2654-40D9-936F-A99CD7AC1354@entel.upc.edu> X-Mailer: iPhone Mail (9B206) From: Gustau Perez Date: Sun, 13 May 2012 20:21:05 +0200 To: Mitsuru IWASAKI X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Sun, 13 May 2012 20:21:13 +0200 (CEST) Cc: "freebsd-acpi@freebsd.org" , "freebsd-current@freebsd.org" Subject: Re: [CFT] SMP/i386 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: Sun, 13 May 2012 18:21:15 -0000 Enviat des del meu iTotxo El 13/05/2012, a les 16:40, Mitsuru IWASAKI va escr= iure: > Hi, Thanks for your report. >=20 > From: Gustau P=C3=A9rez i Querol > Subject: Re: [CFT] SMP/i386 suspend/resume > Date: Sun, 13 May 2012 09:57:33 +0200 > Message-ID: <4FAF696D.3060806@entel.upc.edu> >=20 >> Al 11/05/2012 04:10, En/na Mitsuru IWASAKI ha escrit: >>> Hi >>>=20 >>> I've been working on suspend/resume for SMP/i386 for a week >>> and created patches against CURRENT, RELENG_9 and RELENG_8 >>> available at: >>>=20 >>> http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-2012051= 1.diff >>> http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-201205= 11.diff >>> http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-201205= 11.diff >>>=20 >>> A lot of portion of the patches was ported from amd64. >>> Testing on Thinkpad X60 (Core Duo T2300), so far so good :) >>>=20 >>> I'll commit them against CURRENT hopefully next week. >>>=20 >>=20 >> Reporting from an Acer Centrino Duo, running CURRENT r235266. The=20 >> machine has an nvidia card (Ge7300go). The acpi_video and nvidia modules=20= >> are there. >>=20 >> I did test it a few times with X running (plain twm) and worked just=20= >> fine. Setting hw.acpi.lid_switch_state=3DS3 allowed me to use the=20 >> close-the-lid-to-sleep functionality. >>=20 >> The problem comes when I suspend the machine in the console. The=20 >> machine resumes fine (I can ping and ssh it) but the screen remains=20 >> black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a=20 >> console but X is running, after the resume I can CTRL+ALT+F9 and get my=20= >> video back; then I can return to the console. If I don't have X running,=20= >> I don't know how to get my console back. >=20 > I think this is graphic driver problem. nvidia's driver seems > to have correct suspend/resume method. > http://www.nvidia.com/object/freebsd_archive.html >=20 > Have you try it? Yes, it is running the propietary driver. Everything was done with it load= ed. Do you want me to try without the nvidia binary driver? OTOH, IIRC the console only test (without X) without acpi_video lead to f= reeze. No crash dump. The machine has no serial or fwire ports :( Thanks Gus =20 >=20 > Thanks >=20 >>=20 >> Thanks >>=20 >>=20 From owner-freebsd-acpi@FreeBSD.ORG Sun May 13 20:06:21 2012 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 CAE2B1065677; Sun, 13 May 2012 20:06:21 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B09748FC1E; Sun, 13 May 2012 20:06:20 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA11953; Sun, 13 May 2012 23:06:16 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1STf3Y-000Cv5-Jj; Sun, 13 May 2012 23:06:16 +0300 Message-ID: <4FB01437.6030608@FreeBSD.org> Date: Sun, 13 May 2012 23:06:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Bruce Cran References: <4FAF7343.8010808@cran.org.uk> In-Reply-To: <4FAF7343.8010808@cran.org.uk> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' 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, 13 May 2012 20:06:21 -0000 on 13/05/2012 11:39 Bruce Cran said the following: > I've just updated to -current and noticed the following errors in dmesg: > > acpi0: on motherboard > acpi0: Power Button (fixed) > acpi0: reservation of fee00000, 1000 (3) failed > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bbf00000 (3) failed > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) > cpu0: on acpi0 > ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 > (20120420/tbutils-293) > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > cpu2: on acpi0 > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > cpu1: on acpi0 > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > Can you produce an equivalent snippet with verbose logging enabled? I have a suspicion that these messages are a byproduct from r231161. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sun May 13 22:43:44 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 690CE1065676; Sun, 13 May 2012 22:43:44 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) by mx1.freebsd.org (Postfix) with ESMTP id 1BB748FC19; Sun, 13 May 2012 22:43:44 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id F21AFE6503; Sun, 13 May 2012 23:43:54 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=P9vexZF1B51q irlqH785imScAc0=; b=eGGRiypUeZbejCC7VCRjFVF+x30aF2KLKuCvqrW3v5ql FMCWHxCqOgdE2nAYDxb1ECPWJWulCdiBWXu59KqAC1mUBgJSuOHaLy6NdSzcRH77 jd9WJZJ1Mw5LrfMq7k1PIYPKT2whNkmO+++PbF9QwiRFI3t2PiSZNa1T5k1u4B0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=e6LBdJ sroFCCakMx+ogdjam5qi63NAM9jBOMRxwe1x9yNJEHfHefTg6oTL0wh42llk2xtg 8c9phhnCc8zZ7aZTMEuoPAsPTtVQ6pi3+iQ+6C1oWPmoa/gFGdhjkSu+eV+VQF3j xd8ZxDT84wXX0PDpx0oTXDPioM946nV+yzcu8= Received: from [192.168.2.2] (unknown [89.194.1.1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 43F2BE6482; Sun, 13 May 2012 23:43:54 +0100 (BST) Message-ID: <4FB0391D.3040501@cran.org.uk> Date: Sun, 13 May 2012 23:43:41 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4FAF7343.8010808@cran.org.uk> <4FB01437.6030608@FreeBSD.org> In-Reply-To: <4FB01437.6030608@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' 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, 13 May 2012 22:43:44 -0000 On 13/05/2012 21:06, Andriy Gapon wrote: > Can you produce an equivalent snippet with verbose logging enabled? I > have a suspicion that these messages are a byproduct from r231161. acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bbf00000 (3) failed acpi_sysresource: acpi_sysresource0 already exists; skipping it driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) acpi_timer: acpi_timer0 already exists; skipping it driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 (20120420/tbutils-293) ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) acpi_sysresource: acpi_sysresource2 already exists; skipping it driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu2: on acpi0 acpi_sysresource: acpi_sysresource1 already exists; skipping it driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu1: on acpi0 acpi_sysresource: acpi_sysresource3 already exists; skipping it driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) -- Bruce Cran From owner-freebsd-acpi@FreeBSD.ORG Mon May 14 04:16:25 2012 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 C9A99106566C; Mon, 14 May 2012 04:16:25 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id 7BB448FC0C; Mon, 14 May 2012 04:16:25 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4E4GHXD082844; Mon, 14 May 2012 13:16:17 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Mon, 14 May 2012 13:16:17 +0900 (JST) Message-Id: <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> To: gperez@entel.upc.edu From: Mitsuru IWASAKI In-Reply-To: <9E61BC2D-2654-40D9-936F-A99CD7AC1354@entel.upc.edu> References: <4FAF696D.3060806@entel.upc.edu> <20120513.234014.26960250.iwasaki@jp.FreeBSD.org> <9E61BC2D-2654-40D9-936F-A99CD7AC1354@entel.upc.edu> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 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: Mon, 14 May 2012 04:16:25 -0000 Hi, > >> Reporting from an Acer Centrino Duo, running CURRENT r235266. The > >> machine has an nvidia card (Ge7300go). The acpi_video and nvidia modules > >> are there. > >> > >> I did test it a few times with X running (plain twm) and worked just > >> fine. Setting hw.acpi.lid_switch_state=S3 allowed me to use the > >> close-the-lid-to-sleep functionality. > >> > >> The problem comes when I suspend the machine in the console. The > >> machine resumes fine (I can ping and ssh it) but the screen remains > >> black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a > >> console but X is running, after the resume I can CTRL+ALT+F9 and get my > >> video back; then I can return to the console. If I don't have X running, > >> I don't know how to get my console back. > > > > I think this is graphic driver problem. nvidia's driver seems > > to have correct suspend/resume method. > > http://www.nvidia.com/object/freebsd_archive.html > > > > Have you try it? > > Yes, it is running the propietary driver. Everything was done with it loaded. Do you want me to try without the nvidia binary driver? Yes, if it doesn't bother you. Hmmm, it doesn't seem related with my SMP/i386 sleep patches. Could you try also Uni-processer kernel (w/o SMP and apic from config file) without my patches? > OTOH, IIRC the console only test (without X) without acpi_video lead to freeze. No crash dump. The machine has no serial or fwire ports :( We can improve video initialization on another opportunity. Linux have many video hacks while we have only hw.acpi.reset_video ;) http://www.kernel.org/doc/Documentation/power/video.txt I believe there are some solutions for you in this document, then we can implement them in our source if found. Thanks From owner-freebsd-acpi@FreeBSD.ORG Mon May 14 09:03:13 2012 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 A26EC106564A; Mon, 14 May 2012 09:03:13 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 67B288FC12; Mon, 14 May 2012 09:03:11 +0000 (UTC) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id q4E7o1b8018671; Mon, 14 May 2012 09:50:01 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 203DE2CBD0E; Mon, 14 May 2012 09:49:56 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 14 May 2012 09:49:56 +0200 From: Gustau Perez Querol To: , In-Reply-To: <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> References: <4FAF696D.3060806@entel.upc.edu> <20120513.234014.26960250.iwasaki@jp.FreeBSD.org> <9E61BC2D-2654-40D9-936F-A99CD7AC1354@entel.upc.edu> <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> Message-ID: X-Sender: gperez@entel.upc.edu User-Agent: RoundCube Webmail/0.5.1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Mon, 14 May 2012 09:50:03 +0200 (CEST) Cc: iwasaki@jp.FreeBSD.org Subject: Re: [CFT] SMP/i386 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: Mon, 14 May 2012 09:03:13 -0000 > >> >> Reporting from an Acer Centrino Duo, running CURRENT r235266. >> The >> >> machine has an nvidia card (Ge7300go). The acpi_video and nvidia >> modules >> >> are there. >> >> >> >> I did test it a few times with X running (plain twm) and worked >> just >> >> fine. Setting hw.acpi.lid_switch_state=S3 allowed me to use the >> >> close-the-lid-to-sleep functionality. >> >> >> >> The problem comes when I suspend the machine in the console. >> The >> >> machine resumes fine (I can ping and ssh it) but the screen >> remains >> >> black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a >> >> console but X is running, after the resume I can CTRL+ALT+F9 and >> get my >> >> video back; then I can return to the console. If I don't have X >> running, >> >> I don't know how to get my console back. >> > >> > I think this is graphic driver problem. nvidia's driver seems >> > to have correct suspend/resume method. >> > http://www.nvidia.com/object/freebsd_archive.html >> > >> > Have you try it? >> >> Yes, it is running the propietary driver. Everything was done with >> it loaded. Do you want me to try without the nvidia binary driver? > > Yes, if it doesn't bother you. What follows was still done with your patch there. First, I tried with acpi_bounce. I saw this on dmesg: vgapci0: calling BIOS POST I also tried the complete suspend/resume without the nvidia blob. The machine showed the same behavior; it came online after suspending. Everything working but the video. After the suspend/resume cycle and w/o the nvidia blob, I tried to ssh it. The screen was completely black. After logging in, I kldload'ed the nvidia blob and tried to start X. I got a panic (I was unable to read it) and a core after rebooting. The relevant part was: ************************************************* Unread portion of the kernel message buffer: NVRM: failed to copy vbios to system memory. NVRM: RmInitAdapter failed! (0x30:0xffffffff:858) nvidia0: NVRM: rm_init_adapter() failed! ************************************************* So I would say the bios is doing something during the suspend/resume cycle. I would say the nvidia module knows to handle this, but the module must be loaded before the first suspend/resume cycle. That would explain why it works with X running. That would also somehow explain why I can resume while working with ttyv1 having X working on ttvy9 (remember, in that case I had to vidcontrol -s 9 < /dev/console to get my screen back online). I'm just guessing. Could it be that > Hmmm, it doesn't seem related with my SMP/i386 sleep patches. > Could you try also Uni-processer kernel (w/o SMP and apic from config > file) without my patches? I tried smp disabled on boot (kern.smp.disabled=1) and failed the same way. I'm compiling w/o your patch (will take it a while) but I guess it will do worst. Last time I tried, when 9 was head, it did not resume at all. > >> OTOH, IIRC the console only test (without X) without acpi_video >> lead to freeze. No crash dump. The machine has no serial or fwire >> ports :( > > We can improve video initialization on another opportunity. > Linux have many video hacks while we have only hw.acpi.reset_video ;) > http://www.kernel.org/doc/Documentation/power/video.txt > I believe there are some solutions for you in this document, then > we can implement them in our source if found. Could this all be an ASL problem? Thanks, Gus > From owner-freebsd-acpi@FreeBSD.ORG Mon May 14 11:03:33 2012 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 431D71065674 for ; Mon, 14 May 2012 11:03:33 +0000 (UTC) (envelope-from onyx@z-up.ru) Received: from mx.z-up.ru (mx.z-up.ru [92.50.244.44]) by mx1.freebsd.org (Postfix) with ESMTP id EA3C38FC0A for ; Mon, 14 May 2012 11:03:32 +0000 (UTC) Received: from onyx-y550p.loc (unknown [192.168.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.z-up.ru (Postfix) with ESMTPSA id 2C9991144D for ; Mon, 14 May 2012 14:54:00 +0400 (GMT-4) From: Dmitry Kolosov To: freebsd-acpi@freebsd.org Date: Mon, 14 May 2012 14:54:04 +0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; i386; ; ) References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> In-Reply-To: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201205141454.04561.onyx@z-up.ru> Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: onyx@z-up.ru List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 11:03:33 -0000 On =D0=9F=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D0=B0 11 =D0=BC=D0=B0=D1=8F 2012 06= :10:19 Mitsuru IWASAKI wrote: > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511 > .diff Tested on: * i386 9.0-STABLE FreeBSD 9.0-STABLE #3 r234558M: Mon May 14 00:46:28 MSK 2= 012 * Lenovo Ideapad Y550P * x11/nvidia-driver * pciconf: vgapci0@pci0:1:0:0: class=3D0x030000 card=3D0x38cd17aa chip=3D0x0a3410d= e=20 rev=3D0xa2 hdr=3D0x00 vendor =3D 'nVidia Corporation' device =3D 'GT216 [GeForce GT 240M]' class =3D display subclass =3D VGA * sysctl: hw.nvidia.version: NVIDIA UNIX x86 Kernel Module 295.49 Mon Apr 30 23:45:= 17=20 PDT 2012 hw.model: Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz acpiconf -s3 tested 3 times, last one full success (suspend/restore), other= 2=20 less flawless - X or terminal stalled after restoration. acpiconf -s4 tested 1 time with fail. Requesting any rc.conf/sysctl.conf/other configuration for smooth=20 suspend/restore. Anyway, this is HUGE success for FBSD. =2D-=20 () ascii ribbon campaign - against html mail=20 /\ - against microsoft attachments From owner-freebsd-acpi@FreeBSD.ORG Mon May 14 11:07:06 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C831106572C for ; Mon, 14 May 2012 11:07:06 +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 4C5DD8FC0C for ; Mon, 14 May 2012 11:07:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q4EB76en053181 for ; Mon, 14 May 2012 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4EB75H9053179 for freebsd-acpi@FreeBSD.org; Mon, 14 May 2012 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 May 2012 11:07:05 GMT Message-Id: <201205141107.q4EB75H9053179@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, 14 May 2012 11:07:06 -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/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/163268 acpi [acpi_hp] fix driver detach in absence of CMI o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152438 acpi [acpi]: patch to acpi_asus(4) to add extra sysctls for o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o bin/126162 acpi [acpi] ACPI autoload failed : loading required module o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/91594 acpi [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/ o kern/73823 acpi [request] acpi / power-on by timer support o kern/56024 acpi ACPI suspend drains battery while in S3 32 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon May 14 16:41:42 2012 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 197A7106566B; Mon, 14 May 2012 16:41:42 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DDD968FC12; Mon, 14 May 2012 16:41:40 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA26869; Mon, 14 May 2012 19:41:38 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB135C1.4000505@FreeBSD.org> Date: Mon, 14 May 2012 19:41:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Bruce Cran References: <4FAF7343.8010808@cran.org.uk> <4FB01437.6030608@FreeBSD.org> <4FB0391D.3040501@cran.org.uk> In-Reply-To: <4FB0391D.3040501@cran.org.uk> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' 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, 14 May 2012 16:41:42 -0000 on 14/05/2012 01:43 Bruce Cran said the following: > On 13/05/2012 21:06, Andriy Gapon wrote: >> Can you produce an equivalent snippet with verbose logging enabled? I have a >> suspicion that these messages are a byproduct from r231161. > > acpi0: reservation of fee00000, 1000 (3) failed > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bbf00000 (3) failed > acpi_sysresource: acpi_sysresource0 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > acpi_timer: acpi_timer0 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) > cpu0: on acpi0 > ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 > (20120420/tbutils-293) > ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > acpi_sysresource: acpi_sysresource2 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > cpu2: on acpi0 > acpi_sysresource: acpi_sysresource1 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > cpu1: on acpi0 > acpi_sysresource: acpi_sysresource3 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > I think that the following is what happens here in the acpi_timer case. Previously one acpi_timer device_t was added with an order of zero and a fixed unit number of zero in acpi_timer_identify(). Then, another acpi_timer device_t could be added when walking the ACPI device tree, that device would always have a later order and a wildcard unit number (-1). Now both the "hardwired" device and "auto-probed" device are added with the same order of 2 and it also so happens that the hardwired device is after the auto-probed in the device list. So first the auto-probed device just takes the unit number of zero because it is free and then the hardwired device fails to claim the same unit number. The call chain is: device_probe_child -> device_set_devclass -> devclass_add_device -> devclass_alloc_unit. BTW, it seems that acpi_timer_probe is hardcoded to succeed only for the hardwired device, so I am not if we should just skip creating an auto-probed device. In any case, setting any special properties for the auto-probed device (like the order) seems to be completely pointless. I am not really sure what happens for the acpi_sysresource devices. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon May 14 17:55:05 2012 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 2F9EC1065672; Mon, 14 May 2012 17:55:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 96BEE8FC17; Mon, 14 May 2012 17:55:04 +0000 (UTC) Message-ID: <4FB146F8.9090901@FreeBSD.org> Date: Mon, 14 May 2012 13:55:04 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120502 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mitsuru IWASAKI References: <4FAF696D.3060806@entel.upc.edu> <20120513.234014.26960250.iwasaki@jp.FreeBSD.org> <9E61BC2D-2654-40D9-936F-A99CD7AC1354@entel.upc.edu> <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> In-Reply-To: <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, gperez@entel.upc.edu, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 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: Mon, 14 May 2012 17:55:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-05-14 00:16:17 -0400, Mitsuru IWASAKI wrote: > Hi, > >>>> Reporting from an Acer Centrino Duo, running CURRENT r235266. >>>> The machine has an nvidia card (Ge7300go). The acpi_video and >>>> nvidia modules are there. >>>> >>>> I did test it a few times with X running (plain twm) and >>>> worked just fine. Setting hw.acpi.lid_switch_state=S3 allowed >>>> me to use the close-the-lid-to-sleep functionality. >>>> >>>> The problem comes when I suspend the machine in the console. >>>> The machine resumes fine (I can ping and ssh it) but the >>>> screen remains black. I set hw.acpi.reset_video to 0 or 1 but >>>> no go. If I'm in a console but X is running, after the resume >>>> I can CTRL+ALT+F9 and get my video back; then I can return to >>>> the console. If I don't have X running, I don't know how to >>>> get my console back. >>> >>> I think this is graphic driver problem. nvidia's driver seems >>> to have correct suspend/resume method. >>> http://www.nvidia.com/object/freebsd_archive.html >>> >>> Have you try it? >> >> Yes, it is running the propietary driver. Everything was done >> with it loaded. Do you want me to try without the nvidia binary >> driver? First of all, thank you very much for your work! I wanted to do it for very long time but I had no time to actually implement it. :-) > Yes, if it doesn't bother you. Hmmm, it doesn't seem related with > my SMP/i386 sleep patches. I know for sure it is not related to your patches. In fact, we cannot resume most NVIDIA controllers without NVIDIA kernel driver + binary X.org driver + VT switching hack (i.e., hw.syscons.sc_no_suspend_vtswitch=0, which is default). Also, there is ACPI_PM option for ports/x11/nvidia-driver but it doesn't help much because it doesn't seem to save/restore GPU registers by itself (off by default). Very few NVIDIA controllers can be reset with BIOS POST or saved/restored with VBE functions. Many Intel controllers have similar issues and they need kib's KMS driver. Usually, ATI/AMD controllers have no problem when (relatively recent) vesa.ko is compiled into kernel or loaded as module as they have complete VBE save/restore functions. Similarly, any video controllers with correct save/restore functions should work with vesa.ko. > Could you try also Uni-processer kernel (w/o SMP and apic from > config file) without my patches? > >> OTOH, IIRC the console only test (without X) without acpi_video >> lead to freeze. No crash dump. The machine has no serial or fwire >> ports :( > > We can improve video initialization on another opportunity. Linux > have many video hacks while we have only hw.acpi.reset_video ;) FYI, we don't need hw.acpi.reset_video any more (and it is even harmful). It is done from vesa.ko now. > http://www.kernel.org/doc/Documentation/power/video.txt I believe > there are some solutions for you in this document, then we can > implement them in our source if found. Most of these Linux hacks are completely obsolete since KMS. I really don't want to reiterate Linux mistakes again. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+xRvcACgkQmlay1b9qnVP1NwCfVPMz1YhvUcyyhWkQjs4JZdgd B0gAoKuv4ST+N7FInyfaMwMYuFe4AfNx =jk3/ -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Tue May 15 07:30:20 2012 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 95B98106567A; Tue, 15 May 2012 07:30:20 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by mx1.freebsd.org (Postfix) with ESMTP id 258B98FC14; Tue, 15 May 2012 07:30:19 +0000 (UTC) Received: from server.rulingia.com (c220-239-254-65.belrs5.nsw.optusnet.com.au [220.239.254.65]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4F7U9xW016889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 May 2012 17:30:12 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q4F7U4dc021123; Tue, 15 May 2012 17:30:04 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q4F7U2K4021122; Tue, 15 May 2012 17:30:02 +1000 (EST) (envelope-from peter) Date: Tue, 15 May 2012 17:30:02 +1000 From: Peter Jeremy To: Mitsuru IWASAKI Message-ID: <20120515073002.GA21005@server.rulingia.com> References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <20120511112005.GA87299@server.rulingia.com> <20120513.225328.10294857.iwasaki@jp.FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <20120513.225328.10294857.iwasaki@jp.FreeBSD.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 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, 15 May 2012 07:30:20 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I wrote: >> Thank you for that. Since I was in the process of upgrading my >> netbook (Acer Aspire One AOA-110 - Atom N270), I rolled your RELENG_8 >> patch on top of r235229. >>=20 >> Unfortunately, the result hasn't been a complete success. On 2012-May-13 22:53:28 +0900, Mitsuru IWASAKI wro= te: >I think graphic driver (or pic?) has some problems on resume and they >are out of scope of my patches. >HEAD and RELENG_9 have better support on interrupt re-enabling than >RELENG_8 I think. Could you try them? >And for ps/2 mouse, kernel option PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND >would be useful. I've tried stable/9 r235399 with your patches as well as PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND and suspend/resume now works (for the first time) from VTY. I haven't tried suspending directly =66rom X but expect that is still broken. Thank you very much. --=20 Peter Jeremy --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+yBfoACgkQ/opHv/APuIdzgwCeNpwQSpdrUomm10If3/aXxyIh VPYAn0m/xkqL0goAj+UqT+9QxCtuTfBx =gCdw -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-freebsd-acpi@FreeBSD.ORG Tue May 15 15:35:21 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95376106564A; Tue, 15 May 2012 15:35:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 685598FC14; Tue, 15 May 2012 15:35:21 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CE30DB93E; Tue, 15 May 2012 11:35:20 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Tue, 15 May 2012 10:34:13 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <4FB0391D.3040501@cran.org.uk> <4FB135C1.4000505@FreeBSD.org> In-Reply-To: <4FB135C1.4000505@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205151034.13994.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 May 2012 11:35:20 -0400 (EDT) Cc: Bruce Cran , freebsd-current , Andriy Gapon Subject: Re: ACPI 'driver bug: Unable to set devclass' 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, 15 May 2012 15:35:21 -0000 On Monday, May 14, 2012 12:41:37 pm Andriy Gapon wrote: > on 14/05/2012 01:43 Bruce Cran said the following: > > On 13/05/2012 21:06, Andriy Gapon wrote: > >> Can you produce an equivalent snippet with verbose logging enabled? I have a > >> suspicion that these messages are a byproduct from r231161. > > > > acpi0: reservation of fee00000, 1000 (3) failed > > acpi0: reservation of 0, a0000 (3) failed > > acpi0: reservation of 100000, bbf00000 (3) failed > > acpi_sysresource: acpi_sysresource0 already exists; skipping it > > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > > acpi_timer: acpi_timer0 already exists; skipping it > > driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) > > cpu0: on acpi0 > > ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 > > (20120420/tbutils-293) > > ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > > ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > > acpi_sysresource: acpi_sysresource2 already exists; skipping it > > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > > cpu2: on acpi0 > > acpi_sysresource: acpi_sysresource1 already exists; skipping it > > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > > cpu1: on acpi0 > > acpi_sysresource: acpi_sysresource3 already exists; skipping it > > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > > > > I think that the following is what happens here in the acpi_timer case. > Previously one acpi_timer device_t was added with an order of zero and a fixed > unit number of zero in acpi_timer_identify(). Then, another acpi_timer device_t > could be added when walking the ACPI device tree, that device would always have a > later order and a wildcard unit number (-1). > Now both the "hardwired" device and "auto-probed" device are added with the same > order of 2 and it also so happens that the hardwired device is after the > auto-probed in the device list. So first the auto-probed device just takes the > unit number of zero because it is free and then the hardwired device fails to > claim the same unit number. Eh. This should not be true. The unit 0 is reserved when device_add_child() is called in the acpi_timer identify routine. The wildcard device will not be assigned a unit number until device_probe_child time. > The call chain is: > device_probe_child -> device_set_devclass -> devclass_add_device -> > devclass_alloc_unit. That is, the unit for the wildcard devices should still be -1 here and should not even get to this message. I wonder if this is related to the recent changes to set the unit number for CPUs? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue May 15 16:35:24 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD6A3106566B; Tue, 15 May 2012 16:35:23 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 814EC8FC14; Tue, 15 May 2012 16:35:22 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA12485; Tue, 15 May 2012 19:35:14 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB285C0.1090905@FreeBSD.org> Date: Tue, 15 May 2012 19:35:12 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <4FAF7343.8010808@cran.org.uk> <4FB0391D.3040501@cran.org.uk> <4FB135C1.4000505@FreeBSD.org> <201205151034.13994.jhb@freebsd.org> In-Reply-To: <201205151034.13994.jhb@freebsd.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Bruce Cran , freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' 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, 15 May 2012 16:35:24 -0000 on 15/05/2012 17:34 John Baldwin said the following: > On Monday, May 14, 2012 12:41:37 pm Andriy Gapon wrote: >> on 14/05/2012 01:43 Bruce Cran said the following: >>> On 13/05/2012 21:06, Andriy Gapon wrote: >>>> Can you produce an equivalent snippet with verbose logging enabled? I have a >>>> suspicion that these messages are a byproduct from r231161. >>> >>> acpi0: reservation of fee00000, 1000 (3) failed >>> acpi0: reservation of 0, a0000 (3) failed >>> acpi0: reservation of 100000, bbf00000 (3) failed >>> acpi_sysresource: acpi_sysresource0 already exists; skipping it >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) >>> acpi_timer: acpi_timer0 already exists; skipping it >>> driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) >>> cpu0: on acpi0 >>> ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 >>> (20120420/tbutils-293) >>> ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) >>> ACPI: Dynamic OEM Table Load: >>> ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) >>> ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) >>> ACPI: Dynamic OEM Table Load: >>> ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) >>> acpi_sysresource: acpi_sysresource2 already exists; skipping it >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) >>> cpu2: on acpi0 >>> acpi_sysresource: acpi_sysresource1 already exists; skipping it >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) >>> cpu1: on acpi0 >>> acpi_sysresource: acpi_sysresource3 already exists; skipping it >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) >>> >> >> I think that the following is what happens here in the acpi_timer case. >> Previously one acpi_timer device_t was added with an order of zero and a fixed >> unit number of zero in acpi_timer_identify(). Then, another acpi_timer device_t >> could be added when walking the ACPI device tree, that device would always have a >> later order and a wildcard unit number (-1). >> Now both the "hardwired" device and "auto-probed" device are added with the same >> order of 2 and it also so happens that the hardwired device is after the >> auto-probed in the device list. So first the auto-probed device just takes the >> unit number of zero because it is free and then the hardwired device fails to >> claim the same unit number. > > Eh. This should not be true. The unit 0 is reserved when device_add_child() > is called in the acpi_timer identify routine. The wildcard device will not be > assigned a unit number until device_probe_child time. Not sure what you disagree with... First, the wildcard device is added to the child list during the walk. Then, the unit 0 device is added to the list when acpi_timer identify is executed. Then, the wildcard device is probed and gets unit number of zero. Then, the fixed device is being probed and the unit number conflict arises. Am I misunderstanding something? -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue May 15 17:04:02 2012 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 8BA67106566B; Tue, 15 May 2012 17:04:02 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0EB898FC0A; Tue, 15 May 2012 17:04:01 +0000 (UTC) Message-ID: <4FB28C81.9090401@FreeBSD.org> Date: Tue, 15 May 2012 13:04:01 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120502 Thunderbird/12.0.1 MIME-Version: 1.0 To: Peter Jeremy References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <20120511112005.GA87299@server.rulingia.com> <20120513.225328.10294857.iwasaki@jp.FreeBSD.org> <20120515073002.GA21005@server.rulingia.com> In-Reply-To: <20120515073002.GA21005@server.rulingia.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org, Mitsuru IWASAKI Subject: Re: [CFT] SMP/i386 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, 15 May 2012 17:04:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-05-15 03:30:02 -0400, Peter Jeremy wrote: > I wrote: >>> Thank you for that. Since I was in the process of upgrading my >>> netbook (Acer Aspire One AOA-110 - Atom N270), I rolled your >>> RELENG_8 patch on top of r235229. >>> >>> Unfortunately, the result hasn't been a complete success. > > On 2012-May-13 22:53:28 +0900, Mitsuru IWASAKI > wrote: >> I think graphic driver (or pic?) has some problems on resume and >> they are out of scope of my patches. HEAD and RELENG_9 have >> better support on interrupt re-enabling than RELENG_8 I think. >> Could you try them? And for ps/2 mouse, kernel option >> PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND would be useful. > > I've tried stable/9 r235399 with your patches as well as > PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND and suspend/resume now > works (for the first time) from VTY. FYI, you don't need the kernel options. You just have to add the following line to /boot/loader.conf: hint.psm.0.flags="0x6000" It is much easier for us to debug the issue. Please revert the kernel options and give us the following results. 1. Test psm and moused without the above hint. 2. Test psm and moused with "hint.psm.0.flags="0x2000". 3. Test psm and moused with "hint.psm.0.flags="0x6000". 4. Verbose dmesg output (for the touch pad model strings). > I haven't tried suspending directly from X but expect that is > still broken. I believe you have Intel graphics, right? Then, you need kib's KMS patchset to make it happen. http://wiki.freebsd.org/Intel_GPU Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+yjIEACgkQmlay1b9qnVPogACgj+HUK/lYje8MBvca1oUI6A82 gJMAoKkDSb/KW/CEZ8+Hw7RAUGDIOw8t =IFVX -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Wed May 16 02:31:34 2012 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 1B9371065673; Wed, 16 May 2012 02:31:34 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id C17378FC08; Wed, 16 May 2012 02:31:32 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4G2VH4a093543; Wed, 16 May 2012 11:31:17 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Wed, 16 May 2012 11:31:17 +0900 (JST) Message-Id: <20120516.113117.66055741.iwasaki@jp.FreeBSD.org> To: jkim@freebsd.org From: Mitsuru IWASAKI In-Reply-To: <4FB146F8.9090901@FreeBSD.org> References: <9E61BC2D-2654-40D9-936F-A99CD7AC1354@entel.upc.edu> <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> <4FB146F8.9090901@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, gperez@entel.upc.edu, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 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, 16 May 2012 02:31:34 -0000 Hi, > First of all, thank you very much for your work! I wanted to do it > for very long time but I had no time to actually implement it. :-) Welcome! I also wanted to do this for very long time but I had no time and test machines ;) Recently I got Core Duo (Thinkpad X60) and Core 2 Duo (X61) machines. I have some more ideas on wakecode but I'm not sure whether it is possible for now. I'll propose it when it is ready. > I know for sure it is not related to your patches. In fact, we cannot > resume most NVIDIA controllers without NVIDIA kernel driver + binary > X.org driver + VT switching hack (i.e., Hmm, my knowledge on recent hardware is very poor, so your comments are very helpful to catch up. Thanks. > > We can improve video initialization on another opportunity. Linux > > have many video hacks while we have only hw.acpi.reset_video ;) > > FYI, we don't need hw.acpi.reset_video any more (and it is even > harmful). It is done from vesa.ko now. Yeah, I thought that we need INT10 to set video mode again in realmode, but found it can be done in protected mode with x86bios_intr(), great! Anyway, thanks for many things! From owner-freebsd-acpi@FreeBSD.ORG Wed May 16 15:09:10 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A6AA1065672; Wed, 16 May 2012 15:09:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E95628FC16; Wed, 16 May 2012 15:09:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5DED8B922; Wed, 16 May 2012 11:09:09 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Wed, 16 May 2012 10:50:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <201205151034.13994.jhb@freebsd.org> <4FB285C0.1090905@FreeBSD.org> In-Reply-To: <4FB285C0.1090905@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205161050.35759.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 16 May 2012 11:09:09 -0400 (EDT) Cc: Bruce Cran , freebsd-current , Andriy Gapon Subject: Re: ACPI 'driver bug: Unable to set devclass' 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, 16 May 2012 15:09:10 -0000 On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: > on 15/05/2012 17:34 John Baldwin said the following: > > On Monday, May 14, 2012 12:41:37 pm Andriy Gapon wrote: > >> on 14/05/2012 01:43 Bruce Cran said the following: > >>> On 13/05/2012 21:06, Andriy Gapon wrote: > >>>> Can you produce an equivalent snippet with verbose logging enabled? I have a > >>>> suspicion that these messages are a byproduct from r231161. > >>> > >>> acpi0: reservation of fee00000, 1000 (3) failed > >>> acpi0: reservation of 0, a0000 (3) failed > >>> acpi0: reservation of 100000, bbf00000 (3) failed > >>> acpi_sysresource: acpi_sysresource0 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > >>> acpi_timer: acpi_timer0 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) > >>> cpu0: on acpi0 > >>> ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 > >>> (20120420/tbutils-293) > >>> ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > >>> ACPI: Dynamic OEM Table Load: > >>> ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > >>> ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > >>> ACPI: Dynamic OEM Table Load: > >>> ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > >>> acpi_sysresource: acpi_sysresource2 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > >>> cpu2: on acpi0 > >>> acpi_sysresource: acpi_sysresource1 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > >>> cpu1: on acpi0 > >>> acpi_sysresource: acpi_sysresource3 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > >>> > >> > >> I think that the following is what happens here in the acpi_timer case. > >> Previously one acpi_timer device_t was added with an order of zero and a fixed > >> unit number of zero in acpi_timer_identify(). Then, another acpi_timer device_t > >> could be added when walking the ACPI device tree, that device would always have a > >> later order and a wildcard unit number (-1). > >> Now both the "hardwired" device and "auto-probed" device are added with the same > >> order of 2 and it also so happens that the hardwired device is after the > >> auto-probed in the device list. So first the auto-probed device just takes the > >> unit number of zero because it is free and then the hardwired device fails to > >> claim the same unit number. > > > > Eh. This should not be true. The unit 0 is reserved when device_add_child() > > is called in the acpi_timer identify routine. The wildcard device will not be > > assigned a unit number until device_probe_child time. > > Not sure what you disagree with... > First, the wildcard device is added to the child list during the walk. > Then, the unit 0 device is added to the list when acpi_timer identify is executed. > Then, the wildcard device is probed and gets unit number of zero. > Then, the fixed device is being probed and the unit number conflict arises. > > Am I misunderstanding something? Yes. The third step will see that unit 0 is already in use and shouldn't reuse unit 0. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed May 16 16:18:29 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC4801065670; Wed, 16 May 2012 16:18:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 870808FC12; Wed, 16 May 2012 16:18:28 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA27762; Wed, 16 May 2012 19:18:26 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB3D351.6030804@FreeBSD.org> Date: Wed, 16 May 2012 19:18:25 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <4FAF7343.8010808@cran.org.uk> <201205151034.13994.jhb@freebsd.org> <4FB285C0.1090905@FreeBSD.org> <201205161050.35759.jhb@freebsd.org> In-Reply-To: <201205161050.35759.jhb@freebsd.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Bruce Cran , freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' 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, 16 May 2012 16:18:29 -0000 on 16/05/2012 17:50 John Baldwin said the following: > On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: >> Not sure what you disagree with... >> First, the wildcard device is added to the child list during the walk. >> Then, the unit 0 device is added to the list when acpi_timer identify is executed. >> Then, the wildcard device is probed and gets unit number of zero. >> Then, the fixed device is being probed and the unit number conflict arises. >> >> Am I misunderstanding something? > > Yes. The third step will see that unit 0 is already in use and shouldn't > reuse unit 0. > Looks like I missed the call to devclass_add_device() in make_device(). Your guess: > I wonder if this is related to the recent changes to set the unit number for CPUs? seems to be true. The device_t-s created for CPUs have NULL driver name / devclass, but a non-wildcard unit number. So when such a device with unit number 0 is probed by acpi_timer we get a unit number conflict with acpi_timer0 pre-created via the identify. Similarly we get conflicts for acpi_sysresource driver, because we do an early probe-and-attach for this driver and the attached devices get some unit numbers (0, 1, etc). So when during the normal probe pass the "CPU" devices with matching unit numbers are passed to the driver the conflict results. I guess that it is an unorthodox use of newbus to specify a unit number without specifying a driver name... It's like saying "this device must be unit N whatever driver claims it (be it kbdN or diskN) just because I say so". Not sure if this ever makes sense and maybe we should prohibit such a combination (reject it earlier). I guess that in this particular case we already know that the devices are really CPU devices and are going to be claimed by acpi cpu driver. So we should pass "cpu" as the name. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed May 16 19:26:27 2012 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 AB00A106566B; Wed, 16 May 2012 19:26:27 +0000 (UTC) (envelope-from activism7549@bmatter.com) Received: from mail.norfab.ca (mail.norfab.ca [75.152.251.135]) by mx1.freebsd.org (Postfix) with ESMTP id 28A228FC14; Wed, 16 May 2012 19:26:27 +0000 (UTC) Received: from apache by kckcmcwimrmblrekblmcmrcglhikdk.hermes.com with local (Exim 4.67) (envelope-from <, >) id XPDFP1-C91ANE-T2 for , ; Wed, 16 May 2012 12:26:26 -0700 To: , X-PHP-Script: kckcmcwimrmblrekblmcmrcglhikdk.fiemg.com.br/sendmail.php for 75.152.251.135 From: , X-Sender: , X-Mailer: PHP X-Priority: 1 Content-Type: text/plain; charset="iso-8859-1" Message-Id: Date: Wed, 16 May 2012 12:26:26 -0700 Cc: Subject: You do not have much money? We offer a solution to - work in your spare time in our company 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, 16 May 2012 19:26:27 -0000 We invite you to work in the remote assistant position. This work takes 2-3 hours per week and requires absolutely no investment. The essence of this work for incoming client requests in your city. The starting salary is about 2500 EUR per month + bonuses. You get paid your salary every 2 weeks and your bonuses after fulfilling each task! We guarantee work for everyone. But we accept applications this week only! Therefore, you should write a request right now. And you will start earning money, starting from next week. Please indicate in the request: Your name: Your email address: City of residence: Please send the request to my email Margarito@eureseurope.com and I will answer you personally as soon as possible Sincerely, Margarito Lacy From owner-freebsd-acpi@FreeBSD.ORG Wed May 16 20:07:47 2012 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 E0ED31065673; Wed, 16 May 2012 20:07:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B2C7D8FC16; Wed, 16 May 2012 20:07:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 86D1DB948; Wed, 16 May 2012 16:07:46 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Wed, 16 May 2012 16:07:43 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <201205161050.35759.jhb@freebsd.org> <4FB3D351.6030804@FreeBSD.org> In-Reply-To: <4FB3D351.6030804@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205161607.43286.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 16 May 2012 16:07:47 -0400 (EDT) Cc: Bruce Cran , freebsd-acpi@freebsd.org, freebsd-current Subject: Re: ACPI 'driver bug: Unable to set devclass' 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, 16 May 2012 20:07:48 -0000 On Wednesday, May 16, 2012 12:18:25 pm Andriy Gapon wrote: > on 16/05/2012 17:50 John Baldwin said the following: > > On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: > >> Not sure what you disagree with... > >> First, the wildcard device is added to the child list during the walk. > >> Then, the unit 0 device is added to the list when acpi_timer identify is executed. > >> Then, the wildcard device is probed and gets unit number of zero. > >> Then, the fixed device is being probed and the unit number conflict arises. > >> > >> Am I misunderstanding something? > > > > Yes. The third step will see that unit 0 is already in use and shouldn't > > reuse unit 0. > > > > Looks like I missed the call to devclass_add_device() in make_device(). > > Your guess: > > I wonder if this is related to the recent changes to set the unit number for CPUs? > > seems to be true. > > The device_t-s created for CPUs have NULL driver name / devclass, but a > non-wildcard unit number. So when such a device with unit number 0 is probed by > acpi_timer we get a unit number conflict with acpi_timer0 pre-created via the > identify. > Similarly we get conflicts for acpi_sysresource driver, because we do an early > probe-and-attach for this driver and the attached devices get some unit numbers > (0, 1, etc). So when during the normal probe pass the "CPU" devices with matching > unit numbers are passed to the driver the conflict results. > > I guess that it is an unorthodox use of newbus to specify a unit number without > specifying a driver name... It's like saying "this device must be unit N whatever > driver claims it (be it kbdN or diskN) just because I say so". Not sure if this > ever makes sense and maybe we should prohibit such a combination (reject it earlier). > I guess that in this particular case we already know that the devices are really > CPU devices and are going to be claimed by acpi cpu driver. So we should pass > "cpu" as the name. Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() (and/or, not make the unit number in cpuX mean anything at all, but use a separate ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think the last approach is really the right way to fix this. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu May 17 15:00:38 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 503D0106566B; Thu, 17 May 2012 15:00:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE318FC0C; Thu, 17 May 2012 15:00:38 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 86E24B948; Thu, 17 May 2012 11:00:37 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Thu, 17 May 2012 10:05:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <4FB3D351.6030804@FreeBSD.org> <201205161607.43286.jhb@freebsd.org> In-Reply-To: <201205161607.43286.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205171005.19736.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 17 May 2012 11:00:37 -0400 (EDT) Cc: Bruce Cran , freebsd-current , Andriy Gapon Subject: Re: ACPI 'driver bug: Unable to set devclass' 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, 17 May 2012 15:00:38 -0000 On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: > On Wednesday, May 16, 2012 12:18:25 pm Andriy Gapon wrote: > > on 16/05/2012 17:50 John Baldwin said the following: > > > On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: > > >> Not sure what you disagree with... > > >> First, the wildcard device is added to the child list during the walk. > > >> Then, the unit 0 device is added to the list when acpi_timer identify is executed. > > >> Then, the wildcard device is probed and gets unit number of zero. > > >> Then, the fixed device is being probed and the unit number conflict arises. > > >> > > >> Am I misunderstanding something? > > > > > > Yes. The third step will see that unit 0 is already in use and shouldn't > > > reuse unit 0. > > > > > > > Looks like I missed the call to devclass_add_device() in make_device(). > > > > Your guess: > > > I wonder if this is related to the recent changes to set the unit number for CPUs? > > > > seems to be true. > > > > The device_t-s created for CPUs have NULL driver name / devclass, but a > > non-wildcard unit number. So when such a device with unit number 0 is probed by > > acpi_timer we get a unit number conflict with acpi_timer0 pre-created via the > > identify. > > Similarly we get conflicts for acpi_sysresource driver, because we do an early > > probe-and-attach for this driver and the attached devices get some unit numbers > > (0, 1, etc). So when during the normal probe pass the "CPU" devices with matching > > unit numbers are passed to the driver the conflict results. > > > > I guess that it is an unorthodox use of newbus to specify a unit number without > > specifying a driver name... It's like saying "this device must be unit N whatever > > driver claims it (be it kbdN or diskN) just because I say so". Not sure if this > > ever makes sense and maybe we should prohibit such a combination (reject it earlier). > > I guess that in this particular case we already know that the devices are really > > CPU devices and are going to be claimed by acpi cpu driver. So we should pass > > "cpu" as the name. > > Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() > (and/or, not make the unit number in cpuX mean anything at all, but use a separate > ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think > the last approach is really the right way to fix this. I haven't been able to try this yet, but I have a first cut at www.freebsd.org/~jhb/patches/acpi_cpu.patch -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu May 17 15:34:01 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 977871065676; Thu, 17 May 2012 15:34:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5441A8FC1E; Thu, 17 May 2012 15:34:00 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA12182; Thu, 17 May 2012 18:33:57 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB51A64.6090906@FreeBSD.org> Date: Thu, 17 May 2012 18:33:56 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <4FAF7343.8010808@cran.org.uk> <4FB3D351.6030804@FreeBSD.org> <201205161607.43286.jhb@freebsd.org> <201205171005.19736.jhb@freebsd.org> In-Reply-To: <201205171005.19736.jhb@freebsd.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Bruce Cran , freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' 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, 17 May 2012 15:34:01 -0000 on 17/05/2012 17:05 John Baldwin said the following: > On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: >> Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() >> (and/or, not make the unit number in cpuX mean anything at all, but use a separate >> ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think >> the last approach is really the right way to fix this. > > I haven't been able to try this yet, but I have a first cut at > www.freebsd.org/~jhb/patches/acpi_cpu.patch > The patch has not been compile-tested? :) -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu May 17 19:29:49 2012 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 44181106566B; Thu, 17 May 2012 19:29:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 16CB68FC16; Thu, 17 May 2012 19:29:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7E43CB94F; Thu, 17 May 2012 15:29:48 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Thu, 17 May 2012 13:50:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <201205171005.19736.jhb@freebsd.org> <4FB51A64.6090906@FreeBSD.org> In-Reply-To: <4FB51A64.6090906@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205171350.53229.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 17 May 2012 15:29:48 -0400 (EDT) Cc: Bruce Cran , freebsd-acpi@freebsd.org, freebsd-current Subject: Re: ACPI 'driver bug: Unable to set devclass' 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, 17 May 2012 19:29:49 -0000 On Thursday, May 17, 2012 11:33:56 am Andriy Gapon wrote: > on 17/05/2012 17:05 John Baldwin said the following: > > On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: > >> Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() > >> (and/or, not make the unit number in cpuX mean anything at all, but use a separate > >> ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think > >> the last approach is really the right way to fix this. > > > > I haven't been able to try this yet, but I have a first cut at > > www.freebsd.org/~jhb/patches/acpi_cpu.patch > > > > The patch has not been compile-tested? :) Not yet. I'll try to test it later today unless someone beats me to it. :-P -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri May 18 14:45:18 2012 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 12E9F1065674; Fri, 18 May 2012 14:45:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D978A8FC14; Fri, 18 May 2012 14:45:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3ADF1B96C; Fri, 18 May 2012 10:45:17 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Fri, 18 May 2012 10:45:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <201205171005.19736.jhb@freebsd.org> <4FB51A64.6090906@FreeBSD.org> In-Reply-To: <4FB51A64.6090906@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205181045.16675.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 18 May 2012 10:45:17 -0400 (EDT) Cc: Bruce Cran , freebsd-acpi@freebsd.org, freebsd-current Subject: Re: ACPI 'driver bug: Unable to set devclass' 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, 18 May 2012 14:45:18 -0000 On Thursday, May 17, 2012 11:33:56 am Andriy Gapon wrote: > on 17/05/2012 17:05 John Baldwin said the following: > > On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: > >> Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() > >> (and/or, not make the unit number in cpuX mean anything at all, but use a separate > >> ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think > >> the last approach is really the right way to fix this. > > > > I haven't been able to try this yet, but I have a first cut at > > www.freebsd.org/~jhb/patches/acpi_cpu.patch > > > > The patch has not been compile-tested? :) I've updated it with a run-tested version. -- John Baldwin