From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 24 19:55:48 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C166B7CB; Sun, 24 Feb 2013 19:55:48 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-da0-f52.google.com (mail-da0-f52.google.com [209.85.210.52]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7BA115; Sun, 24 Feb 2013 19:55:48 +0000 (UTC) Received: by mail-da0-f52.google.com with SMTP id x33so113119dad.39 for ; Sun, 24 Feb 2013 11:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=kBbTUmkhxW0iNvLGNGsW6/OC2bPt0MD7ohu7nkVh/KQ=; b=ilZQjhaLMv8K/jDC808PNPzGS4lSDksleFj4S7Au6PZCmsYrd2Cc8OBFG3BL4XycO6 GfUTGbGgbAo7wmJJuPeO3vDzTf/UNQwBbjgCoYX6a6+18qlY8lq8soHG9TtlWU4Askgc mfTRD5V6Wz/w6HPRFYFx0RMwmR1+3D+L2v/LcZOliuMdN0XEvUCqRFdyXExqAKave0vt 8Mw3Hj+R+FK28f6/lwcOg3whdCf0nhlffHjOzQM/RIo0bacitDTW8s0BDdbzvmdcljMC KrAJEf4Ewj0Eag/4tzVTeX3RjVqZgGDzQTuefxBLbX6J5bwoRtwq3moSrbkMIBslodSc 0znw== X-Received: by 10.68.227.9 with SMTP id rw9mr14456370pbc.185.1361735741921; Sun, 24 Feb 2013 11:55:41 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id dk1sm10074608pbc.15.2013.02.24.11.55.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Feb 2013 11:55:41 -0800 (PST) Message-ID: <512A6FFF.2060603@gmail.com> Date: Sun, 24 Feb 2013 11:54:39 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130202 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-acpi Subject: Fixing X220 Video The Right Way Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 19:55:48 -0000 I am working on fixing acpi_video for X220. My X220 is back to FreeBSD land, and I always felt \VBRC calls were dirty. So I've set out to fix acpi_video to work naturally, as it does in linux land. Background: Lenovo laptops boot in a mode where the brightness keys automagically work, under BIOS/EC control. This gets blown away (for us) shortly after Kernel attach. At this point, the acpi method \NBCF will return 0, which means acpi cannot control video brightness. Once we touch the _BCL method on the video output (even inactive ones), \NBCF returns 1 and will allow acpi control. You may remember that acpi_video records some brightness value that changes with keypresses, but does not work on X220. Current status: If I modify acpi video to attach to \_SB.PCI0.PEG.VID, brightness works via sysctl but not keypress (\NBCF = 1) If I leave that alone, but just redirect the brightness set function to \_SB.PCI0.PEG.VID.LCD0._BCM, the keyboard works That is obviously a hack, but it indicates something is going on here. I think that get_acpi_handle() on the X220 vgapci is returning the wrong ACPI_HANDLE. Perhaps this is why the screen stays off when resume used to work? Obviously it can be fixed by hard coding this path into acpi_video, but I feel like that is definitely the wrong way. A tunable for an acpi_video override might be useful, but it still leaves potentially the wrong path in vgapci's IVARs. Is there a better place to "correct" the ACPI_PATH that gets stored in vgapci's ivar? Is there already a tunable I can use to fix this? Thanks! Matt From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 00:58:41 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2FB06D47; Mon, 25 Feb 2013 00:58:41 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id DD92615E; Mon, 25 Feb 2013 00:58:40 +0000 (UTC) Received: by mail-da0-f44.google.com with SMTP id z20so1201164dae.31 for ; Sun, 24 Feb 2013 16:58:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=C6yTWJgDKjLg5k4JuLlBHyW3FHrBc/GHWCepd4UgBFA=; b=De7rP8CfzsWL6q7y2Imfiun3K2imubfxnGA8vP5OXdi3//qf/CQYhZ8W2lDFxzXE/Y G6N2t2KbEc3tnSE98DnzfdIOhCuL2r2jAzFdZcRp4wyy9Gpdtffzh+eSOmAFkoi/VtmC v0vi8CJ8038HroqlDsYBO7q2MmM3DrrBhdkiQy+KxtSytajrnSb3/d7zh8easC7PoG2Q foqSU0lpm+Tq0bqUTMbcnLmp35W9a8AknCmHubIATYQHA2pG8GcsSFuMg6R29lQSUCn+ Qzvnj2rNVOdoCkE7zgsgICsktVE8gFr3eq5heEXRCj+ABVeH0TjASYHWNH3ZeZFxa9Zj DUVA== X-Received: by 10.68.237.165 with SMTP id vd5mr15429536pbc.52.1361753913936; Sun, 24 Feb 2013 16:58:33 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id qb10sm10706217pbb.43.2013.02.24.16.58.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Feb 2013 16:58:32 -0800 (PST) Message-ID: <512AB6F3.6030001@gmail.com> Date: Sun, 24 Feb 2013 16:57:23 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130202 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ian Smith Subject: Re: what is required to support a new laptop? References: <20130128114938.GK50515@e-new.0x20.net> <20130130024649.R87033@sola.nimnet.asn.au> <20130130032714.D87033@sola.nimnet.asn.au> <20130130050811.H87033@sola.nimnet.asn.au> In-Reply-To: <20130130050811.H87033@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, bapt@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 00:58:41 -0000 On 01/29/13 10:24, Ian Smith wrote: > On Tue, 29 Jan 2013 12:46:43 -0500, Eitan Adler wrote: > > On 29 January 2013 12:29, Ian Smith wrote: > > > Ah right. I don't suppose kldload -v shows anything useful about the > > > problem loading it? Ah, never mind, it may be obvious .. lightly > > > skimming your asl.y530.gz, I recalled folks having to patch something > > > for Lenovo rather than IBM OEMIDs .. hunt, hunt .. ok, here it is: > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164538 > > > > > > This is after the install of a patched acpi_ibm > > [3500 root@gravity /usr/src/sys/modules/acpi ]#kldload -v acpi_ibm > > Loaded acpi_ibm, id=12 > > Which looks maybe successful, on the face of it? .. > > > [5507 eitan@gravity (100)% ~ !1!]%sysctl dev.acpi_ibm > > sysctl: unknown oid 'dev.acpi_ibm' > > .. but clearly wasn't. > The Y series doesn't have the HKEY stuff, or it's not the same. You want acpi_video (as does every new Lenovo, thinkpad or not). The problem is Lenovo is putting the "correct" _BCL/_BCM under "PEG" devices....section from your dsdt follows, temporary workaround test after that Device (LCD) { Method (_ADR, 0, NotSerialized) { Return (0x0110) } Method (LVLS, 1, NotSerialized) { Store (One, Local0) Store (Zero, Local1) If (LEqual (OSYS, 0x07DC)) { Store (0x14, Local5) Store (PLV2, Local6) } Else { Store (0x0F, Local5) Store (PLVL, Local6) } While (Local0) { Add (Local1, 0x02, Local2) Store (DerefOf (Index (Local6, Local2)), Local3) And (Arg0, 0xFF, Local4) If (LEqual (Local4, Local3)) { Store (Zero, Local0) } Subtract (Local3, One, Local3) If (LEqual (Local4, Local3)) { Store (Zero, Local0) } If (LGreaterEqual (Local1, Local5)) { Store (Zero, Local0) } If (Local0) { Add (One, Local1, Local1) } } Return (Local1) } Method (_BCL, 0, NotSerialized) { If (LNotEqual (OSYS, 0x07DC)) { Return (PLVL) } Else { Return (PLV2) } } Method (_BCM, 1, NotSerialized) { If (IGDS) { Store (^^^^GFX0.DD02.LVLS (Arg0), Local1) Store (Local1, ^^^^LPCB.EC0.BRTS) ^^^^GFX0.AINT (One, Arg0) } Else { Store (LVLS (Arg0), Local1) Store (Local1, ^^^^LPCB.EC0.BRTS) } Store (Arg0, BRTL) } Method (_BQC, 0, NotSerialized) { Return (BRTL) } } } } This would be under _SB.PCI0.PEG0.VGA Try acpi_call -p '\_SB.PCI0.PEG0.VGA.LCD._BCL' then acpi_call -p '\_SB.PCI0.PEG0.VGA.LCD._BCL' -i 50 Experiment with the numbers. We need to fix acpi_video so it attaches to the correct _BCL on these laptops. Matt From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 01:04:57 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 538CBDED for ; Mon, 25 Feb 2013 01:04:57 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id DDFCE198 for ; Mon, 25 Feb 2013 01:04:56 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so1946395wgh.31 for ; Sun, 24 Feb 2013 17:04:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5ZFAHJBCFyvJylam7ZWV9LowWLDeXeFxS2EwWO/NcUA=; b=V81jkpq6IbHi4gzb+wGwc9KYT7H0CZL2YnA/CJ57GqsOM9DL6U6yLvR/JpNIbLXbzk dzccaloJ53akZ7G0h0gr94OH5FmuceTz5+b5k1MGO2x6R3+Z5WwvxSxx2Dji5jjtyXjw GE3uO9Y6cFCaF9PgbAjQMBqYm79ojrye6mybY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=5ZFAHJBCFyvJylam7ZWV9LowWLDeXeFxS2EwWO/NcUA=; b=hul8PuuNuHTNAlro7JcO+or6JU5ggpJEgg9JtWBbDm53ch0m2ZngO7SQurUCwDje0O WwJvPzdiJ1oqKPVZmF7O7ozprP+XWAAK+58mWBYJJBCQ1VZNf1DXaoKOIym8QMC7nLQy SZe01CKoincmNiQNHstzqbxNaA227vVfbp0x9NQwta2/NyTxvj7dWFiZpA0KwN2Q5CTy 7Jd3Vod74R+cMPY9Vz/Y0vhpUzY6ximCZ7Bz/C86Yz0/8f8moIXgWJW+bgD2NwXLE2xt 9ORQPrtEGJ+uGmRodg6Hm4nXb9cBDXoE9vMUEKY23FONewiazY8eX/yS2ED/v5Yx3OXh /TgQ== X-Received: by 10.194.122.131 with SMTP id ls3mr15601422wjb.55.1361754295451; Sun, 24 Feb 2013 17:04:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.122.201 with HTTP; Sun, 24 Feb 2013 17:04:25 -0800 (PST) In-Reply-To: <512AB6F3.6030001@gmail.com> References: <20130128114938.GK50515@e-new.0x20.net> <20130130024649.R87033@sola.nimnet.asn.au> <20130130032714.D87033@sola.nimnet.asn.au> <20130130050811.H87033@sola.nimnet.asn.au> <512AB6F3.6030001@gmail.com> From: Eitan Adler Date: Sun, 24 Feb 2013 20:04:25 -0500 Message-ID: Subject: Re: what is required to support a new laptop? To: matt Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQm/BVPpbC5cjOEATQ5FYVl0LQVKEs6c62FlWmxgF5VT1Xmt2o+QH8BTvA28SS+3KPrhywQ5 Cc: bapt@freebsd.org, freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 01:04:57 -0000 On 24 February 2013 19:57, matt wrote: > On 01/29/13 10:24, Ian Smith wrote: >> On Tue, 29 Jan 2013 12:46:43 -0500, Eitan Adler wrote: >> > On 29 January 2013 12:29, Ian Smith wrote: >> > > Ah right. I don't suppose kldload -v shows anything useful about the >> > > problem loading it? Ah, never mind, it may be obvious .. lightly >> > > skimming your asl.y530.gz, I recalled folks having to patch something >> > > for Lenovo rather than IBM OEMIDs .. hunt, hunt .. ok, here it is: >> > > >> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164538 >> > >> > >> > This is after the install of a patched acpi_ibm >> > [3500 root@gravity /usr/src/sys/modules/acpi ]#kldload -v acpi_ibm >> > Loaded acpi_ibm, id=12 >> >> Which looks maybe successful, on the face of it? .. >> >> > [5507 eitan@gravity (100)% ~ !1!]%sysctl dev.acpi_ibm >> > sysctl: unknown oid 'dev.acpi_ibm' >> >> .. but clearly wasn't. >> > > The Y series doesn't have the HKEY stuff, or it's not the same. You want > acpi_video (as does every new Lenovo, thinkpad or not). > > The problem is Lenovo is putting the "correct" _BCL/_BCM under "PEG" > devices....section from your dsdt follows, temporary workaround test > after that ... > This would be under _SB.PCI0.PEG0.VGA > > Try acpi_call -p '\_SB.PCI0.PEG0.VGA.LCD._BCL' > then > acpi_call -p '\_SB.PCI0.PEG0.VGA.LCD._BCL' -i 50 > > Experiment with the numbers. > > We need to fix acpi_video so it attaches to the correct _BCL on these > laptops. Unknown object type '4' regardless of what number is passed to -i. Same with the first call. -- Eitan Adler From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 01:17:34 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F12DDF6C; Mon, 25 Feb 2013 01:17:34 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-da0-f45.google.com (mail-da0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id A2E79235; Mon, 25 Feb 2013 01:17:34 +0000 (UTC) Received: by mail-da0-f45.google.com with SMTP id v40so1215321dad.4 for ; Sun, 24 Feb 2013 17:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aq0M3qcq+vEl2CrGtqASwUC4FhuXszIxGXWV41kdbfI=; b=X8oxXE7MT3HlmHIAD4RHb+lp1T/o4xo1ESaRz9WkfovuEgCFEaBAZFwSI9xVCoTFi5 vg4/7flIzy47FslnNdN4nCGPvENLix6tQHaXi2RJsh4Ja2kRvwrYNt7FqaD9ifcxF3GN /fUodw2nqqMlYtgX9xE9Ha6wmpO1l604CP3cZzMQ0H6WALxX6hfOkbea9SCjc9DPxluG MzVS9vPWl5VxkOoIe64+0SDIa6X4SVMFIdzN7K6xxpIz3V2l14ObLB4Ezyz/5zDQNKvs 1f6pBS90clqEBKUC1DXfY3dVQ62EHUDxJZ04mrETsf8QW7T69NjwChsOkSFZQJzQD3dA U5lw== X-Received: by 10.66.235.102 with SMTP id ul6mr16105226pac.111.1361755048193; Sun, 24 Feb 2013 17:17:28 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id gg7sm10752297pbc.45.2013.02.24.17.17.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Feb 2013 17:17:27 -0800 (PST) Message-ID: <512ABB5E.5050904@gmail.com> Date: Sun, 24 Feb 2013 17:16:14 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130202 Thunderbird/17.0.2 MIME-Version: 1.0 To: Eitan Adler Subject: Re: what is required to support a new laptop? References: <20130128114938.GK50515@e-new.0x20.net> <20130130024649.R87033@sola.nimnet.asn.au> <20130130032714.D87033@sola.nimnet.asn.au> <20130130050811.H87033@sola.nimnet.asn.au> <512AB6F3.6030001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: bapt@freebsd.org, freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 01:17:35 -0000 On 02/24/13 17:04, Eitan Adler wrote: > On 24 February 2013 19:57, matt wrote: >> On 01/29/13 10:24, Ian Smith wrote: >>> On Tue, 29 Jan 2013 12:46:43 -0500, Eitan Adler wrote: >>> > On 29 January 2013 12:29, Ian Smith wrote: >>> > > Ah right. I don't suppose kldload -v shows anything useful about the >>> > > problem loading it? Ah, never mind, it may be obvious .. lightly >>> > > skimming your asl.y530.gz, I recalled folks having to patch something >>> > > for Lenovo rather than IBM OEMIDs .. hunt, hunt .. ok, here it is: >>> > > >>> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164538 >>> > >>> > >>> > This is after the install of a patched acpi_ibm >>> > [3500 root@gravity /usr/src/sys/modules/acpi ]#kldload -v acpi_ibm >>> > Loaded acpi_ibm, id=12 >>> >>> Which looks maybe successful, on the face of it? .. >>> >>> > [5507 eitan@gravity (100)% ~ !1!]%sysctl dev.acpi_ibm >>> > sysctl: unknown oid 'dev.acpi_ibm' >>> >>> .. but clearly wasn't. >>> >> The Y series doesn't have the HKEY stuff, or it's not the same. You want >> acpi_video (as does every new Lenovo, thinkpad or not). >> >> The problem is Lenovo is putting the "correct" _BCL/_BCM under "PEG" >> devices....section from your dsdt follows, temporary workaround test >> after that > ... > >> This would be under _SB.PCI0.PEG0.VGA >> >> Try acpi_call -p '\_SB.PCI0.PEG0.VGA.LCD._BCL' >> then >> acpi_call -p '\_SB.PCI0.PEG0.VGA.LCD._BCL' -i 50 >> >> Experiment with the numbers. >> >> We need to fix acpi_video so it attaches to the correct _BCL on these >> laptops. > Unknown object type '4' > > regardless of what number is passed to -i. Same with the first call. > I made a typo :( Change the second call from _BCL to _BCM. The first call _BCL would "trapdoor" a thinkpad, and it returns an unknown object type 4. Acpi call has some formatting options to display this "object", it's usually (or should be) a list of valid backlight levels. The second call should set the value. _BQC will return the current value. If that does not work, also try replacing PEG0 with PEG1. Matt From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 01:30:20 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 58BC31C5 for ; Mon, 25 Feb 2013 01:30:20 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id B601D2AE for ; Mon, 25 Feb 2013 01:30:19 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id s43so2079313wey.35 for ; Sun, 24 Feb 2013 17:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=TJibTcC2nQ8GVsCV4A1FcjPAEhjfhn1mStWe+XSyYAc=; b=L25UVESaFbJMHzUnfQ3FBaHHZ+6NAiQN7JIiUQXB1RTXs6UvSXVoWyVh+zEAx2HtiY T80VsazESeWnEsxIExWcwVsZTgZu6XGGfo9hNhfRPiGHNHI/kUmwVXLdsq+AQ02qbCi5 00MUNdoU0wyxMRxaM5ajpvV+yQ0xJMpRKNiJE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=TJibTcC2nQ8GVsCV4A1FcjPAEhjfhn1mStWe+XSyYAc=; b=nCjPQsQM5N919X8NKH/HKuyaXgoV5Xz7VctmhlpHrN2qElBRCTCq0C2QnBKOgy+5tv TlaAoWoeWHnHIy+ADgfmJVdaBZiFV2fUOnd9JKLS0p25DHqDoxNv0I5ZXFMWEJ0a56Gd iN0Uk7ya2Z7zbKSO/8YBMqjU7OYFsJBGX7BBnyOxKMa4RStTbuUZ/swIy2GDbTQEASIo dZf5Y0K2c/Fyth4XPOIwkhosmIFwWx+nY3sltKDy5xb96C1SvFgZbdbTnlvdY0lC96Om Yub8jzO+5d8UqVOTg8e1fb4bWe6UGoYCxt7XznXLxVAz/U0G4L3fcP1UxFpQo+cBlGlO 5JVw== X-Received: by 10.180.77.9 with SMTP id o9mr9058747wiw.16.1361755818694; Sun, 24 Feb 2013 17:30:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.122.201 with HTTP; Sun, 24 Feb 2013 17:29:48 -0800 (PST) In-Reply-To: <512ABB5E.5050904@gmail.com> References: <20130128114938.GK50515@e-new.0x20.net> <20130130024649.R87033@sola.nimnet.asn.au> <20130130032714.D87033@sola.nimnet.asn.au> <20130130050811.H87033@sola.nimnet.asn.au> <512AB6F3.6030001@gmail.com> <512ABB5E.5050904@gmail.com> From: Eitan Adler Date: Sun, 24 Feb 2013 20:29:48 -0500 Message-ID: Subject: Re: what is required to support a new laptop? To: matt Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnzHnqpkrrtIsjP7NkWUQMwmSFgkvNDaYM/AW2wCU5S3Mdeyvge8gz+narGnOZU+X8MMfrq Cc: bapt@freebsd.org, freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 01:30:20 -0000 On 24 February 2013 20:16, matt wrote: > I made a typo :( Change the second call from _BCL to _BCM. > The first call _BCL would "trapdoor" a thinkpad, and it returns an > unknown object type 4. Acpi call has some formatting options to display > this "object", it's usually (or should be) a list of valid backlight > levels. The second call should set the value. _BQC will return the > current value. If that does not work, also try replacing PEG0 with PEG1. [5398 root@gravity (100)% ...ts/sysutils/acpi_call !5!]#acpi_call -p '\_SB.PCI0.PEG1.VGA.LCD._BQC' -o o 0 [5399 root@gravity (100)% ...ports/sysutils/acpi_call ]#acpi_call -p '\_SB.PCI0.PEG0.VGA.LCD._BQC' -o o 0 [5389 root@gravity (100)% ...ports/sysutils/acpi_call ]#acpi_call -p '\_SB.PCI0.PEG1.VGA.LCD._BCM' -i 50 50 [5390 root@gravity (100)% ...ports/sysutils/acpi_call ]#acpi_call -p '\_SB.PCI0.PEG1.VGA.LCD._BCM' -i 20 20 but nothing visible changes. This is better than before (I think). Thanks! I hope this could work in the end. -- Eitan Adler From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 01:40:12 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8966A270 for ; Mon, 25 Feb 2013 01:40:12 +0000 (UTC) (envelope-from ait.mlist@gmail.com) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id 17B2B2F2 for ; Mon, 25 Feb 2013 01:40:11 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id s4so1875491lbc.35 for ; Sun, 24 Feb 2013 17:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:subject:message-id:mime-version :content-type:content-disposition:x-operating-system:user-agent; bh=UmOUyzxWyzUkzpjJ9VdX1JC6C+DzukqyjgW2q2YIu1Y=; b=f6wlp8fPtgzUn7roWQWSV15wCz1+qSYi00lp1q80iolNiyh2teRS1U888kNIlMnZUq EXokt+zYzuXQBKlaxAO9Hr+lBOpwPm8a/oZxVV1CpOT5wLT1GQ2OSz5WVafnwbqMWNOI 7jGAXzzbQ9CeI5nA5R8HKWZ8pcG9DVKmYuHl4rdNX8rN2SaoazCGcYdTjfoF7jHJs7so 7a8mcYoW2PhIIwKeIJEtxpjJAELA3xSYYoVOydZjZc/Pdau9Sk37CfNjDkAxl+Pml/o+ SrV/tX7hSQNcQkjshtw5ND95LWjZqJ2LJHvFWL0mXKIsIyyjtCGbLqyfy12PpKk2Ie0l VYcQ== X-Received: by 10.152.147.130 with SMTP id tk2mr8373323lab.24.1361756404634; Sun, 24 Feb 2013 17:40:04 -0800 (PST) Received: from a3500l ([109.165.59.127]) by mx.google.com with ESMTPS id i3sm3534268lbn.0.2013.02.24.17.40.01 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 24 Feb 2013 17:40:03 -0800 (PST) Received: by a3500l (sSMTP sendmail emulation); Mon, 25 Feb 2013 05:40:00 +0400 Date: Mon, 25 Feb 2013 05:40:00 +0400 From: Dmitry Sarkisov To: freebsd-acpi@freebsd.org Subject: acpi_termal sysctl interface strange temperature value Message-ID: <20130225014000.GA6413@aperturescience.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 9.1-RELEASE i386 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 01:40:12 -0000 Hello, I'm trying to poll cpu temperature with the following code: #define TEMP_MIB "hw.acpi.thermal.tz0.temperature" size_t len; int t; len = sizeof(t); bzero(temp, len); if(sysctlbyname(TEMP_MIB, &t, &len, NULL, 0) == -1 ){ perror("sysctl"); return -1; }else{ printf("%d\n", t); } Values I'm geting are like this: 3732 while actual is: sysctl -n hw.acpi.thermal.tz0.temperature 55.0C Any advices are much appreciated. Please cc me, as I'm not subscribed. ps: I'm using i386 9.1-RELEASE -- Dmitry Sarkisov <-\ Powered by <-------------------o <-/ FreeBSD From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 02:42:59 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9CC93D43; Mon, 25 Feb 2013 02:42:59 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by mx1.freebsd.org (Postfix) with ESMTP id 546DA715; Mon, 25 Feb 2013 02:42:59 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id fb1so1462965pad.11 for ; Sun, 24 Feb 2013 18:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NcrUkAjC9CtqdsecQxB/fCRSb4UpyB5nfF+l7773JVA=; b=u65uMFdqgGfXmZAEm1+5vj07GGX9faKy8XDTC85EzeQjUwKx/KCLfz4CgYlXKfiuAn j6kwLETU5UkOv54S7uxNURu6zTsyH61/lcguLkzvDwocuHYyNeq2yHJOFXZ6Fhk0JGnx B8QqwIbL1ABcHRiYOnWwRYfo0JUWjRxUzGm3yLLKSJXxr48EQ0F85C1Tf6hBhln1HYtP Ffk+eS2jKWeENMbZMUkTKrLA/EDbPVX24yb9AkC9NysrGLv9Q5qL9Y6QtyLIfkS/4Rs0 Lc3d+2ry0i6w8b99htP0bU8ht+JCcW2Ly0cPmoWQaxQgVfYEftvT2lkqO1aSWtnagMK8 wxFQ== X-Received: by 10.68.42.39 with SMTP id k7mr15447388pbl.138.1361760173021; Sun, 24 Feb 2013 18:42:53 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id tm1sm10994727pbc.11.2013.02.24.18.42.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Feb 2013 18:42:52 -0800 (PST) Message-ID: <512ACF4E.7090806@gmail.com> Date: Sun, 24 Feb 2013 18:41:18 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130202 Thunderbird/17.0.2 MIME-Version: 1.0 To: Eitan Adler Subject: Re: what is required to support a new laptop? References: <20130128114938.GK50515@e-new.0x20.net> <20130130024649.R87033@sola.nimnet.asn.au> <20130130032714.D87033@sola.nimnet.asn.au> <20130130050811.H87033@sola.nimnet.asn.au> <512AB6F3.6030001@gmail.com> <512ABB5E.5050904@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: bapt@freebsd.org, freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 02:42:59 -0000 On 02/24/13 17:29, Eitan Adler wrote: > [5398 root@gravity (100)% ...ts/sysutils/acpi_call !5!]#acpi_call -p > '\_SB.PCI0.PEG1.VGA.LCD._BQC' -o o 0 [5399 root@gravity (100)% > ...ports/sysutils/acpi_call ]#acpi_call -p > '\_SB.PCI0.PEG0.VGA.LCD._BQC' -o o 0 [5389 root@gravity (100)% > ...ports/sysutils/acpi_call ]#acpi_call -p > '\_SB.PCI0.PEG1.VGA.LCD._BCM' -i 50 50 [5390 root@gravity (100)% > ...ports/sysutils/acpi_call ]#acpi_call -p > '\_SB.PCI0.PEG1.VGA.LCD._BCM' -i 20 20 but nothing visible changes. > This is better than before (I think). Thanks! I hope this could work > in the end. Next step is to call _BCL then _BCM at every location in the DSDT and see if any of them work. It's probable that one of them does... Lenovo seems to like playing hide the correct acpi methods or something. Matt From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 06:13:57 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4586FC57 for ; Mon, 25 Feb 2013 06:13:57 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by mx1.freebsd.org (Postfix) with ESMTP id 026DEF61 for ; Mon, 25 Feb 2013 06:13:56 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id i10so2578008oag.14 for ; Sun, 24 Feb 2013 22:13:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bPx4ZXZccbrlYTKhhuuCq9rmXNYIMUsiDZ9hN9ReF9A=; b=tSMGtmlggIzzHFW91wBlMT2sbKdyVBDmcMvaRNLxxRUY6U25nt3xlz2FEcufZvgWk8 JmiAn+B73MMXOqnLACduvb0ndYeaC7U7EbIsITtsPuASBCt5HwYAlX/78Hp/Z8Mr+t27 bDCYzA0xRZXdwFNdqFINab6OLTnZ78kxBQGgSJXRuSdEVqhDf0WykLgiNU+/Zo8aq/Ms 6Kb63Me7hni0kvw2p1nG8kFSTasEc4aNys1ed+oaLou7r+ASxLI97cuJPNJqwEBccxgT LJw9EyDklU5j5TQhu5VhZeGl0UI162JrXVFUi0TKI3DGhskYi8B7ALBMSQ6+UoYBM+OP p1kA== MIME-Version: 1.0 X-Received: by 10.60.19.101 with SMTP id d5mr6265583oee.115.1361772836137; Sun, 24 Feb 2013 22:13:56 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.76.34.197 with HTTP; Sun, 24 Feb 2013 22:13:56 -0800 (PST) In-Reply-To: <20130225014000.GA6413@aperturescience.org> References: <20130225014000.GA6413@aperturescience.org> Date: Sun, 24 Feb 2013 22:13:56 -0800 X-Google-Sender-Auth: CTe4EvGz1ytqhLNTmMzNjyrOqo8 Message-ID: Subject: Re: acpi_termal sysctl interface strange temperature value From: Kevin Oberman To: Dmitry Sarkisov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 06:13:57 -0000 On Sun, Feb 24, 2013 at 5:40 PM, Dmitry Sarkisov wrote: > Hello, > > I'm trying to poll cpu temperature with the following code: > > > #define TEMP_MIB "hw.acpi.thermal.tz0.temperature" > > size_t len; > int t; > > len = sizeof(t); > bzero(temp, len); > > if(sysctlbyname(TEMP_MIB, &t, &len, NULL, 0) == -1 ){ > perror("sysctl"); > return -1; > }else{ > printf("%d\n", t); > } > > Values I'm geting are like this: > 3732 > > while actual is: > > sysctl -n hw.acpi.thermal.tz0.temperature > 55.0C > ACPI does not report temperature in degrees Celsius, but in tenths of a degree Kelvin. So both agree. When ACPI was first introduced into head (v5?), the sysctl reported the raw number, but the code was later modified to provide a more human friendly value. Directly probing ACPI for temperature still returns the raw value. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 07:19:32 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8E2A6490 for ; Mon, 25 Feb 2013 07:19:32 +0000 (UTC) (envelope-from j@uriah.heep.sax.de) Received: from uriah.heep.sax.de (unknown [IPv6:2a01:170:1047::9]) by mx1.freebsd.org (Postfix) with ESMTP id 4EBA21B4 for ; Mon, 25 Feb 2013 07:19:32 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 5329B56A; Mon, 25 Feb 2013 08:19:30 +0100 (MET) Date: Mon, 25 Feb 2013 08:19:30 +0100 From: Joerg Wunsch To: freebsd-acpi@freebsd.org Subject: Re: acpi_termal sysctl interface strange temperature value Message-ID: <20130225071929.GM28792@uriah.heep.sax.de> References: <20130225014000.GA6413@aperturescience.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Joerg Wunsch List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 07:19:32 -0000 As Kevin Oberman wrote: > > Values I'm geting are like this: > > 3732 > > > > while actual is: > > > > sysctl -n hw.acpi.thermal.tz0.temperature > > 55.0C > > > ACPI does not report temperature in degrees Celsius, but in tenths > of a degree Kelvin. So both agree. I wouldn't call it an agreement if one reports 373 K (= 100 °C), and the other one 55 °C ... (Btw., according to SI, Kelvin is a normal unit of measure, without the "degree".) -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 11:06:43 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0B536105 for ; Mon, 25 Feb 2013 11:06:43 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DA280E60 for ; Mon, 25 Feb 2013 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1PB6g1w066502 for ; Mon, 25 Feb 2013 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1PB6g7V066500 for freebsd-acpi@FreeBSD.org; Mon, 25 Feb 2013 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Feb 2013 11:06:42 GMT Message-Id: <201302251106.r1PB6g7V066500@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 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 11:06:43 -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/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/163268 acpi [acpi_hp] [patch] 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 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 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 33 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 21:13:24 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8AFC8F48; Mon, 25 Feb 2013 21:13:24 +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 69995854; Mon, 25 Feb 2013 21:13:24 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 93BDEB93B; Mon, 25 Feb 2013 16:13:22 -0500 (EST) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: Fixing X220 Video The Right Way Date: Mon, 25 Feb 2013 13:30:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> In-Reply-To: <512A6FFF.2060603@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302251330.57034.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 25 Feb 2013 16:13:22 -0500 (EST) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 21:13:24 -0000 On Sunday, February 24, 2013 2:54:39 pm matt wrote: > I am working on fixing acpi_video for X220. > > My X220 is back to FreeBSD land, and I always felt \VBRC calls were dirty. > So I've set out to fix acpi_video to work naturally, as it does in linux > land. > > Background: > Lenovo laptops boot in a mode where the brightness keys automagically > work, under BIOS/EC control. > This gets blown away (for us) shortly after Kernel attach. > > At this point, the acpi method \NBCF will return 0, which means acpi > cannot control video brightness. > > Once we touch the _BCL method on the video output (even inactive ones), > \NBCF returns 1 and will allow acpi control. > > You may remember that acpi_video records some brightness value that > changes with keypresses, but does not work on X220. > > Current status: > If I modify acpi video to attach to \_SB.PCI0.PEG.VID, brightness works > via sysctl but not keypress (\NBCF = 1) > > If I leave that alone, but just redirect the brightness set function to > \_SB.PCI0.PEG.VID.LCD0._BCM, the keyboard works > > That is obviously a hack, but it indicates something is going on here. > > I think that get_acpi_handle() on the X220 vgapci is returning the wrong > ACPI_HANDLE. > Perhaps this is why the screen stays off when resume used to work? > > Obviously it can be fixed by hard coding this path into acpi_video, but > I feel like that is definitely the wrong way. > A tunable for an acpi_video override might be useful, but it still > leaves potentially the wrong path in vgapci's IVARs. > > Is there a better place to "correct" the ACPI_PATH that gets stored in > vgapci's ivar? Is there already a tunable I can use to fix this? vgapci's ivar is set by the PCI address. Do you have multiple vgapci devices? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 22:28:17 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC30C458 for ; Mon, 25 Feb 2013 22:28:17 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6EDBF2 for ; Mon, 25 Feb 2013 22:28:17 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id u54so3004867wey.30 for ; Mon, 25 Feb 2013 14:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Z11PXDn9B9WOQGPxSJVOkwnWdaTe9E+JNFWj/qc3Ckc=; b=U/dfruDSrLTgovVrXEbrAhpe7BKX5XV9CrE5Y51NjIdtTnyQ22Yfqdmlfzroh19X/J fpt/FQMFWioITI9ubsMl5j8lgxg32M3+RQxfdO3SeIi2rHhVNSr98m3e07lCk/+LArup +Nh+i/kHK2oZsyTliaacnrzd+Y4LxhhWL1ZVU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Z11PXDn9B9WOQGPxSJVOkwnWdaTe9E+JNFWj/qc3Ckc=; b=hXmQCbc+tDQY9lNbGNqAJjvvD5L+dUeoiGBX7kMbb27WJT3HNQV78BMpt2y5nPmnXL K6wpwvGqDRjfwMa6bHcBOSLDhSciYb/BqgK79NhYNPSfV0+D0An3PNcFDQ9BU7DeSFaq hTOT4DiRaThVw+Rv/JjCOpLqAK499c+HIziCkl0wJjo+RZIoQe/LlZND42zRsgvQbgAY +MehVHf6dMFCGO/+c9Ve0mddejxzCq/84NN6j1L0XviLZZ0aSlYqGZu9zCV8inHSy/bu UteIP8R6eQcFGMWSKfBpXCbJB/cJudz1P/4d9b+YMjEYHVC8suktIj5xKAva2t35tI72 WwWQ== X-Received: by 10.180.93.234 with SMTP id cx10mr15350769wib.34.1361831296299; Mon, 25 Feb 2013 14:28:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.122.201 with HTTP; Mon, 25 Feb 2013 14:27:46 -0800 (PST) In-Reply-To: <512ACF4E.7090806@gmail.com> References: <20130128114938.GK50515@e-new.0x20.net> <20130130024649.R87033@sola.nimnet.asn.au> <20130130032714.D87033@sola.nimnet.asn.au> <20130130050811.H87033@sola.nimnet.asn.au> <512AB6F3.6030001@gmail.com> <512ABB5E.5050904@gmail.com> <512ACF4E.7090806@gmail.com> From: Eitan Adler Date: Mon, 25 Feb 2013 17:27:46 -0500 Message-ID: Subject: Re: what is required to support a new laptop? To: matt Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQniLcy357xRvT2zcOBa+I3CkXdOI8wWDXH6lEesYFkMDAPYAUzgkx8rNt8HbeDfma+5s+DL Cc: bapt@freebsd.org, freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:28:17 -0000 On 24 February 2013 21:41, matt wrote: > Next step is to call _BCL then _BCM at every location in the DSDT and > see if any of them work. > It's probable that one of them does... Tried randomly guessing path names, but nothing resulted in anything but "Unknown object type '0'" I don't know how to read the ASL, what other paths are likely to work? > Lenovo seems to like playing hide the correct acpi methods or something. Heh. I could try to add support for this laptop to acpi_ibm or acpi_video (wherever is a appropriate) once this is figured out. -- Eitan Adler From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 01:54:43 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9C261245; Tue, 26 Feb 2013 01:54:43 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by mx1.freebsd.org (Postfix) with ESMTP id 56E633A7; Tue, 26 Feb 2013 01:54:43 +0000 (UTC) Received: by mail-pb0-f41.google.com with SMTP id um15so2038050pbc.0 for ; Mon, 25 Feb 2013 17:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=Asf1qZ865mpkCGbhtWXyxaIsLHlAJpeZKnAiQvcLY6U=; b=07lp1ugUad/R8jJHdpWTsr0KlDElWdH+i6StTry4OlNxdd9gxkxP6eERcE/WDBOlxn DXI8BtOyIf6VujonF/NAPZfIoBW/2DaA4q7NtTm2DJd4avvqJOlgFi8xqtsnI3qIs6ju zHpbJV+BU4HIuSDew8C3CQkIESQAQK9u4EinaY9muNR8gG2y/dCK+E8uJbhah0WfS562 zLRYVkuhGro9agNaf8TbbY/nDatP5R+htD3xxCk6hYm9ajPJdsxj3ctN/g6VRU54A5ji gKGxqGFBULhMXA09JywckJqjvHqq2tFo/Vz/TBwBIthYsAM3TSHY40uixSY+sJr1DuNW Re6w== X-Received: by 10.68.212.197 with SMTP id nm5mr20799872pbc.179.1361843677654; Mon, 25 Feb 2013 17:54:37 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id t6sm15625028paz.11.2013.02.25.17.54.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 17:54:36 -0800 (PST) Message-ID: <512C159B.3020707@gmail.com> Date: Mon, 25 Feb 2013 17:53:31 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <201302251330.57034.jhb@freebsd.org> In-Reply-To: <201302251330.57034.jhb@freebsd.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 01:54:43 -0000 On 02/25/13 10:30, John Baldwin wrote: > > Is there a better place to "correct" the ACPI_PATH that gets stored in > vgapci's ivar? Is there already a tunable I can use to fix this? > vgapci's ivar is set by the PCI address. Do you have multiple vgapci devices? > No, just one. I think that the DSDT is very creative on recent Lenovos (read: broken). There are multiple video devices defined, with "functional" calls that nonetheless don't work to actually do anything. The acpi_get_handle() call in acpi_video returns a handle that has no active outputs and doesn't have any control over the brightness. The other path can control brightness. Here's a related discussion on Linux, I'm not sure how much applies other than the situation discussed: http://comments.gmane.org/gmane.linux.acpi.devel/57228 The same thing happens on AGP thinkpads, I believe, based on Mitsuru Iwasaki's comment a long time ago to an X220 thread. Matt From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 02:09:51 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 52534560; Tue, 26 Feb 2013 02:09:51 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by mx1.freebsd.org (Postfix) with ESMTP id ED4A0717; Tue, 26 Feb 2013 02:09:50 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id hz1so2102408pad.24 for ; Mon, 25 Feb 2013 18:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Cl5N9quvpb3OYaYPOBF0eUW5yfJwoNaI+SZ+No1futE=; b=lenWl0qtTYBUjna3w68Tf/AOAEdok0vOfSm/LkcjlSRgikRXIH8+IynRiqqtpGJ9SS f5Kkbik02tQIeGxMlSPPxOWborUyDhnFfdHdhA3CG5PbYbnJ4jW0cz9A8MUWOly6Z1wq lv+aUZwI13XoDZ9pE53vgtzGZp6x5ermmxfCX9TIJG5gMWbvukOgYJyfCE4O+vJUuqbr 9kjzueBd3Y9m26nlSeDdd61cXaqmbeuKBRrsdAxSvCVQPTr2ZUmVXQy4/qi+h+oYXoES bWCF28Z5A7fUcCp5UUtO/Xpd4jc060uduz4deNsvodS32J1MTF1qQR6tGRY5n8Z8BIhq buBQ== X-Received: by 10.68.252.134 with SMTP id zs6mr21493329pbc.66.1361844584172; Mon, 25 Feb 2013 18:09:44 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id rn14sm14576969pbb.33.2013.02.25.18.09.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 18:09:43 -0800 (PST) Message-ID: <512C1922.4090109@gmail.com> Date: Mon, 25 Feb 2013 18:08:34 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: Eitan Adler Subject: Re: what is required to support a new laptop? References: <20130128114938.GK50515@e-new.0x20.net> <20130130024649.R87033@sola.nimnet.asn.au> <20130130032714.D87033@sola.nimnet.asn.au> <20130130050811.H87033@sola.nimnet.asn.au> <512AB6F3.6030001@gmail.com> <512ABB5E.5050904@gmail.com> <512ACF4E.7090806@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: bapt@freebsd.org, freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 02:09:51 -0000 On 02/25/13 14:27, Eitan Adler wrote: > Tried randomly guessing path names, but nothing resulted in anything > but "Unknown object type '0'" I don't know how to read the ASL, what > other paths are likely to work? The "SCOPE" sections set the base path for the devices in a block, so if you find "device vga", scroll up and you'll Replace * with _BCL then _BCM -i "value in bcl results" (the bcl results are kind of readable in hex) _SB.PCI0.PEG0.VGA.LCD.* _SB.PCI0.PEG1.VGA.LCD.* _SB.PCI0.GFX0.DD02.* Are all I can find. There might be another issue than the thinkpad one at play if none work. All the BCMs call the AINT method (which I hope doesn't stand for AINT GONNA WORK :) ) They all are shell functions for the one under GFX0 (which also has a bunch of thermal checks, maybe it's the best bet). One other method to try is this LVLS method under any of the above...it is involved in transforming the incoming level to ec-values I think? Matt From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 02:19:27 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E7F81796; Tue, 26 Feb 2013 02:19:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id 1776D74B; Tue, 26 Feb 2013 02:19:26 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id l13so5470768wie.0 for ; Mon, 25 Feb 2013 18:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5nKdek7JZHUSEM+8qH3tDJxs0ZQ0+uy4JlK23YS5plA=; b=H3t3e/7Mp0FzlA8LnWN7/I7JQUenm4gF9bJL3jSQsh3UFEFQwdYTQ9oHpHQT8JYM29 o1Hl6VnGKEXAw8iL0Ym6gE0FwFxhXYV9pA9i2G7/3kIrd9NxAN/38//DKTjgQ9IwGnQr Az3Zf/NlzUqOu8Y98OFIkp1UxJLKZU7SgkRlabiBn9wDWbRoKN93Bmnomn8ukH6Iy2sV 6UD677t9KkT4J3IwtyPvNhdyh7Cl7JHCtzQU2h1v3MeXZzNIgHHoi05nQ3MIoX473WyO 7QORHAySGUn586eMTDUpKPquuFqeNHPjwO0g90/9jpw1uHb8u2RLPDXWZavqVS+7eRvx dDyg== MIME-Version: 1.0 X-Received: by 10.194.5.137 with SMTP id s9mr21990527wjs.5.1361845166348; Mon, 25 Feb 2013 18:19:26 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.74.194 with HTTP; Mon, 25 Feb 2013 18:19:25 -0800 (PST) In-Reply-To: <512C159B.3020707@gmail.com> References: <512A6FFF.2060603@gmail.com> <201302251330.57034.jhb@freebsd.org> <512C159B.3020707@gmail.com> Date: Mon, 25 Feb 2013 18:19:25 -0800 X-Google-Sender-Auth: 5Qj_KNR34GIgUeGOPWZy8mcs9UQ Message-ID: Subject: Re: Fixing X220 Video The Right Way From: Adrian Chadd To: matt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 02:19:28 -0000 On 25 February 2013 17:53, matt wrote: > No, just one. I think that the DSDT is very creative on recent Lenovos > (read: broken). There are multiple video devices defined, with > "functional" calls that nonetheless don't work to actually do anything. > The acpi_get_handle() call in acpi_video returns a handle that has no > active outputs and doesn't have any control over the brightness. The > other path can control brightness. > My T400 has: vgapci0@pci0:0:2:0: class=0x030000 card=0x20e417aa chip=0x2a428086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Integrated Graphics Controller' class = display And I get glitches in xorg on 9.1 when I have multiple windows of different sizes. Adrian From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 02:24:48 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E81E38FF; Tue, 26 Feb 2013 02:24:48 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8ED5B77E; Tue, 26 Feb 2013 02:24:48 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id kq12so2117315pab.15 for ; Mon, 25 Feb 2013 18:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lzTASf+Zy3LZeA+BAvis46C9DXpDv6awjlbIdYXIsrU=; b=b92iCkTTa6Fw+D594Ii6y+b7EX0gHgLShf8C5ThHtSUV7O92dVH+E1VW24k5S0/s9l CEI2NJYn19gkJwQZ2OiKNEGJusEho5u5+KVS9zuyJgnMmRBuzj3h8C9cPLpSSdZyWFOM XZGG8ogkFmDlEro+4IVGqmJgzOU7h6k3ucromPFGxelEdNPYPfaE1eausjLDEQ/kufUJ mfQOOawYRcAPVXFk72tnXozzJK+AvcZAZOi/oRkM1I40YPUZUKEEoAOBc3ozp7UA1NtV becaS9ThzZVhQ0StllItL0NYjalLA7tGJFmioZ0qnCAmibYXdut8de6ikqLeX84wNsVf P2kQ== X-Received: by 10.68.0.170 with SMTP id 10mr21345691pbf.59.1361845482788; Mon, 25 Feb 2013 18:24:42 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id g4sm15725530pax.4.2013.02.25.18.24.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 18:24:41 -0800 (PST) Message-ID: <512C1C8A.5020104@gmail.com> Date: Mon, 25 Feb 2013 18:23:06 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <201302251330.57034.jhb@freebsd.org> <512C159B.3020707@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 02:24:49 -0000 On 02/25/13 18:19, Adrian Chadd wrote: > > My T400 has: > > > vgapci0@pci0:0:2:0: class=0x030000 card=0x20e417aa chip=0x2a428086 > rev=0x07 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Mobile 4 Series Chipset Integrated Graphics Controller' > class = display > subclass = VGA > vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086 > rev=0x07 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Mobile 4 Series Chipset Integrated Graphics Controller' > class = display > > And I get glitches in xorg on 9.1 when I have multiple windows of > different sizes. > > > > Adrian > Does acpi_video like either one? Does acpi_get_handle return the same path? Matt From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 02:33:17 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 77FB0C1A; Tue, 26 Feb 2013 02:33:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id C64807D2; Tue, 26 Feb 2013 02:33:16 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ez12so4039618wid.6 for ; Mon, 25 Feb 2013 18:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IPI64pSTL/1a92+KftRb0qDWZBPHXrNqPPrcAT8kYQY=; b=UAbpBTTp1JGTYDbvlEjURScub7YeOND6LWgCx9EvNLEe+rXRHwV0eZhRsC+4R+3Mbu yrMk55k9fccu6TDHfW5cgs2fqDHoyiftAO+C959vqSnYuWq3/uVRL2GznbJjLQDVfyIn XDTF7aXtEdAJGn0gSo2415G2tGoRPCKJZ66pFcge+RFhCZqVZqwlHQGEdHAPJ8tKO3iG AmxJXNeN8vS/qY53Oic0gM8PFw/N/M5E3sS9VAFAG9SyMZDY5ieNWpkwottUDqrDRGld 8l7BtGLUQhSQ9KTNYgDHQQnasMPMuxVFvakZTHyR2yr2nywUEJ1jzeQZHGKFFhol/L40 FhDg== MIME-Version: 1.0 X-Received: by 10.194.90.168 with SMTP id bx8mr23011794wjb.59.1361845995658; Mon, 25 Feb 2013 18:33:15 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.74.194 with HTTP; Mon, 25 Feb 2013 18:33:15 -0800 (PST) In-Reply-To: <512C1C8A.5020104@gmail.com> References: <512A6FFF.2060603@gmail.com> <201302251330.57034.jhb@freebsd.org> <512C159B.3020707@gmail.com> <512C1C8A.5020104@gmail.com> Date: Mon, 25 Feb 2013 18:33:15 -0800 X-Google-Sender-Auth: kuHt_VZhfaSdbcx7cpuki_HQ_6A Message-ID: Subject: Re: Fixing X220 Video The Right Way From: Adrian Chadd To: matt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 02:33:17 -0000 [101232] acpi_video0: on vgapci0 found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 And what do I do with acpi_get_handle ? Adrian On 25 February 2013 18:23, matt wrote: > On 02/25/13 18:19, Adrian Chadd wrote: >> >> My T400 has: >> >> >> vgapci0@pci0:0:2:0: class=0x030000 card=0x20e417aa chip=0x2a428086 >> rev=0x07 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Mobile 4 Series Chipset Integrated Graphics Controller' >> class = display >> subclass = VGA >> vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086 >> rev=0x07 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Mobile 4 Series Chipset Integrated Graphics Controller' >> class = display >> >> And I get glitches in xorg on 9.1 when I have multiple windows of >> different sizes. >> >> >> >> Adrian >> > Does acpi_video like either one? > Does acpi_get_handle return the same path? > > Matt From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 03:54:57 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AD007EE9 for ; Tue, 26 Feb 2013 03:54:57 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 82317A7C for ; Tue, 26 Feb 2013 03:54:57 +0000 (UTC) Received: by mail-ia0-f170.google.com with SMTP id k20so3170270iak.29 for ; Mon, 25 Feb 2013 19:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=heaJSQRwwwQtive5r4b7TAN38qojFRnDnfw24ZgEmG4=; b=BK3mdZbs2wGik7p/r92x0KeWpc0PuVseAnQ+KMuvyD8R4ASOXc7Gv+LTTcV5cmmGnC 0hZIoHx1FDOe9dOpIm70qZnpZ/JVtsF41witpMLbi6TygxXRL22hHK3XrkBK76l1hJ9d 1b30ROaDaMp+E3VhIPPrXBn6Iol9/ZmNyfdKkrGYqWIXrlVAfZz16ykWb0I355riqVIw Xpd04SX/eJEP8Yd5zb1t/qnbM2CNxLv33EtJO528TThIG64bLrrivL6IfI9XOird6VJI g7i98lXj5yGJmqL6vzJnWWWBZMcc6wNJ5N+dYQgV04q73MLGuczJFDqbpsJJgxKKeQF+ TihA== MIME-Version: 1.0 X-Received: by 10.50.36.199 with SMTP id s7mr4731076igj.56.1361850897149; Mon, 25 Feb 2013 19:54:57 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.64.20.166 with HTTP; Mon, 25 Feb 2013 19:54:57 -0800 (PST) In-Reply-To: <20130225071929.GM28792@uriah.heep.sax.de> References: <20130225014000.GA6413@aperturescience.org> <20130225071929.GM28792@uriah.heep.sax.de> Date: Mon, 25 Feb 2013 19:54:57 -0800 X-Google-Sender-Auth: Wwj4TAuixyBxf_7_X1cRDRu3GR4 Message-ID: Subject: Re: acpi_termal sysctl interface strange temperature value From: Kevin Oberman To: Joerg Wunsch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 03:54:57 -0000 On Sun, Feb 24, 2013 at 11:19 PM, Joerg Wunsch wrote: > As Kevin Oberman wrote: > > > > Values I'm geting are like this: > > > 3732 > > > > > > while actual is: > > > > > > sysctl -n hw.acpi.thermal.tz0.temperature > > > 55.0C > > > > > > ACPI does not report temperature in degrees Celsius, but in tenths > > of a degree Kelvin. So both agree. > > I wouldn't call it an agreement if one reports 373 K (=3D 100 =C2=B0C), > and the other one 55 =C2=B0C ... > > (Btw., according to SI, Kelvin is a normal unit of measure, without > the "degree".) > -- > cheers, Joerg .-.-. --... ...-- -.. . DL8DTL > Ack! I should have actually LOOKED at the numbers. Silly mistake. But I just looked at the source and ACPI does report temperature in tenths of a degree Kelvin, so I am now baffled as to what is going on. Sorry, but SI or not, "tenths of a Kelvin" is just wrong. Actually, the time you should properly omit the 'degrees' is when specifying a temperature as in 373 K. Still, I can't explain the odd reading of the raw value Dimitry is getting.= . --=20 R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 04:21:41 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A02D234A; Tue, 26 Feb 2013 04:21:41 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by mx1.freebsd.org (Postfix) with ESMTP id 61D49B22; Tue, 26 Feb 2013 04:21:41 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kp14so2169636pab.33 for ; Mon, 25 Feb 2013 20:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=mSTINisJwrFDhUim3BTKR5s2ah2QCDmqqmyMQ7K02Us=; b=KO3hIdLdYxVOUY58JMls1K5gyDMEux5isKBlDzWsq2ICkBhpRSwdjXoofLXVvvMfLa mYSe/NLMLX/7CkNhX/i+ZgnMvMzSXcqJ8ecSc9xyb306ZiJ/ZlGaIorV/KS9Q4k/frRt 6Xs2rW3djObf9WyhNjol/j9blewLIbGxFZ2x81Jaxv33kkoMmAC9btLfYMvSEiKoFNIQ lw22squWn092hiUaeO2Iy8icZ2s6K4PbNOmPBPu88cUJBLALUAIB1qzh6Dt6ibnWrexR ys60MF5BEhCEOW3kZbpJBUky8pVVfU4eiEHQEHIf5I6Oq+RU/Cq4u4RQ5PU8OtuuVYAi 1Jyw== X-Received: by 10.68.75.109 with SMTP id b13mr21804107pbw.25.1361852495787; Mon, 25 Feb 2013 20:21:35 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id qf7sm14978316pbb.2.2013.02.25.20.21.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 20:21:34 -0800 (PST) Message-ID: <512C380D.5030506@gmail.com> Date: Mon, 25 Feb 2013 20:20:29 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <201302251330.57034.jhb@freebsd.org> <512C159B.3020707@gmail.com> <512C1C8A.5020104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 04:21:41 -0000 On 02/25/13 18:33, Adrian Chadd wrote: > [101232] acpi_video0: on vgapci0 > found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 > > And what do I do with acpi_get_handle ? > > > > I threw printfs into acpi_video, not sure if that would work for both vgapci or not. I'm not sure if I wiped out my debug patches yet, I may have a patch. Basically the idea is to figure out which paths in the DSDT are getting attached to the vgapci devices. This dsdt patch from Mitsuru Iwasaki illustrates fixing a similar issue to X220 via a custom dsdt http://people.freebsd.org/~iwasaki/acpi/tpx61.asl.diff It seems like we could either try to find these paths on affected models, or have a tunable override for acpi_video. Matt From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 15:37:51 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 647FAB08 for ; Tue, 26 Feb 2013 15:37:51 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id EADDAAD0 for ; Tue, 26 Feb 2013 15:37:50 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id x8so3644019wey.20 for ; Tue, 26 Feb 2013 07:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=T2SNG6jXFR49ZYHkkhfyr4eeTS7KrpkW0v/Q9Cc/F1k=; b=tZARwCW9twiVF1tFa8txWEomt5U+dPKUoPePEteN2HAjR0/HiRmiWyx4aNwyHtVRvk PiITbduAJyYhNelm6Kwc30lMfwtddOoiN0uwrsVLaXUxqH8HPZ6AP1tfL5yhWUxH8EGe 8jGt5pRrgohCh55VTxuxzUzL3IDlW88ECqOhB81ulPheaOxWowN8QFJz7LtiRqRLUqeH 1DIIl3dlgOR6fFfTmqjq4rTr/YtQXo8FpgttKktYqcooc2qJlFPJslmyNTcZlBCkk6Hj X9vbGNRvVbwAkt300yY3qTmEpC+sI58hLy9kbn/2HXTTRXE7zjCJ4aLPovIsZTWbCSCM itcg== MIME-Version: 1.0 X-Received: by 10.194.156.196 with SMTP id wg4mr27357487wjb.22.1361893070062; Tue, 26 Feb 2013 07:37:50 -0800 (PST) Received: by 10.194.60.147 with HTTP; Tue, 26 Feb 2013 07:37:49 -0800 (PST) In-Reply-To: References: <20130225014000.GA6413@aperturescience.org> <20130225071929.GM28792@uriah.heep.sax.de> Date: Tue, 26 Feb 2013 16:37:49 +0100 Message-ID: Subject: Re: acpi_termal sysctl interface strange temperature value From: David Demelier To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Joerg Wunsch , freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:37:51 -0000 #define TZ_ZEROC 2732 int val =3D (t - TZ_ZEROC) / 10; That should works, I can't remember where I found the TZ_ZEROC value but someone on IRC gave me it a while ago. I use that for 1 year. 2013/2/26 Kevin Oberman > On Sun, Feb 24, 2013 at 11:19 PM, Joerg Wunsch > wrote: > > > As Kevin Oberman wrote: > > > > > > Values I'm geting are like this: > > > > 3732 > > > > > > > > while actual is: > > > > > > > > sysctl -n hw.acpi.thermal.tz0.temperature > > > > 55.0C > > > > > > > > > ACPI does not report temperature in degrees Celsius, but in tenths > > > of a degree Kelvin. So both agree. > > > > I wouldn't call it an agreement if one reports 373 K (=3D 100 =C2=B0C), > > and the other one 55 =C2=B0C ... > > > > (Btw., according to SI, Kelvin is a normal unit of measure, without > > the "degree".) > > -- > > cheers, Joerg .-.-. --... ...-- -.. . DL8DTL > > > > Ack! I should have actually LOOKED at the numbers. Silly mistake. But I > just looked at the source and ACPI does report temperature in tenths of a > degree Kelvin, so I am now baffled as to what is going on. > > Sorry, but SI or not, "tenths of a Kelvin" is just wrong. Actually, the > time you should properly omit the 'degrees' is when specifying a > temperature as in 373 K. > > Still, I can't explain the odd reading of the raw value Dimitry is > getting.. > -- > R. Kevin Oberman, Network Engineer > E-mail: rkoberman@gmail.com > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > --=20 Demelier David From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 15:41:30 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E777B8F for ; Tue, 26 Feb 2013 15:41:30 +0000 (UTC) (envelope-from j@uriah.heep.sax.de) Received: from uriah.heep.sax.de (unknown [IPv6:2a01:170:1047::9]) by mx1.freebsd.org (Postfix) with ESMTP id 2A53DAF4 for ; Tue, 26 Feb 2013 15:41:29 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id AED8B696; Tue, 26 Feb 2013 16:41:28 +0100 (MET) Date: Tue, 26 Feb 2013 16:41:28 +0100 From: Joerg Wunsch To: freebsd-acpi@freebsd.org Subject: Re: acpi_termal sysctl interface strange temperature value Message-ID: <20130226154128.GM68582@uriah.heep.sax.de> References: <20130225014000.GA6413@aperturescience.org> <20130225071929.GM28792@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Joerg Wunsch List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:41:30 -0000 As David Demelier wrote: > #define TZ_ZEROC 2732 > That should works, I can't remember where I found the TZ_ZEROC value but > someone on IRC gave me it a while ago. I use that for 1 year. 0 °C = 273.15 K. Or, in units of 100 mK, it makes 2732. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 15:57:37 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3C277375 for ; Tue, 26 Feb 2013 15:57:37 +0000 (UTC) (envelope-from ait.mlist@gmail.com) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id A224FC1F for ; Tue, 26 Feb 2013 15:57:36 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id ec20so3947402lab.23 for ; Tue, 26 Feb 2013 07:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :x-operating-system:user-agent; bh=k4ynQzNhd+s2Cp3YDIkCECVssExrdA0IVR4Rvyxlqyw=; b=jNt+iqEIpWdX0JR76HCZpv9hWKdend75Np4rIh/GIal/LrbJU8qUKcmT5aGy3bqPNN XpCogoAxZMX1UKVcKiO9aRfdVfqMW9jVVFZXN1aE5ZOJs4YrgZ6kvoo+3sh+XG8eTuVU NIJGhquy/35BigntGughiKkh9fcC2CCw4O/MoKQUf7Vweei138t2vxlH6remmHWYw5UU 7S7NZjfue+4phA1hGHN+X3LcyJ0xLHnHlnOXOI3L624i8v66fBHCvkFJI5JT0S+DiPao RHKZOCJ7p/QqJ6GYKYzqqFlcaI2r2OzKVlsAKGwfoyYVjSam0nLKY7JBaaC0n1c6Dtos fdmA== X-Received: by 10.112.28.4 with SMTP id x4mr333282lbg.33.1361894255557; Tue, 26 Feb 2013 07:57:35 -0800 (PST) Received: from a3500l ([5.139.104.181]) by mx.google.com with ESMTPS id z1sm669447lbk.2.2013.02.26.07.57.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 26 Feb 2013 07:57:34 -0800 (PST) Received: by a3500l (sSMTP sendmail emulation); Tue, 26 Feb 2013 19:57:30 +0400 Date: Tue, 26 Feb 2013 19:57:30 +0400 From: Dmitry Sarkisov To: Kevin Oberman Subject: Re: acpi_termal sysctl interface strange temperature value Message-ID: <20130226155730.GA5335@aperturescience.org> References: <20130225014000.GA6413@aperturescience.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-RELEASE i386 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:57:37 -0000 On 25-02-2013, Mon [22:03:28], Kevin Oberman wrote: > As others have noted, the value you are seeing is 100C, not 55C. So I have > no idea what is going on. > Actually you were right from the beginning. I managed to get the correct value this way, after reading some wiki :) float c; c = (t/10-273.15); /* convert to Celsius */ Thanks for comments everybody. -- Dmitry Sarkisov <-\ Powered by <-------------------o <-/ FreeBSD From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 26 18:53:03 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BB0D7968; Tue, 26 Feb 2013 18:53:03 +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 98E4218DC; Tue, 26 Feb 2013 18:53:03 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 124A5B958; Tue, 26 Feb 2013 13:53:03 -0500 (EST) From: John Baldwin To: matt Subject: Re: Fixing X220 Video The Right Way Date: Tue, 26 Feb 2013 13:46:46 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> <512C380D.5030506@gmail.com> In-Reply-To: <512C380D.5030506@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201302261346.46197.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Feb 2013 13:53:03 -0500 (EST) Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:53:03 -0000 On Monday, February 25, 2013 11:20:29 pm matt wrote: > On 02/25/13 18:33, Adrian Chadd wrote: > > [101232] acpi_video0: on vgapci0 > > found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 > > > > And what do I do with acpi_get_handle ? > > > > > > > > > I threw printfs into acpi_video, not sure if that would work for both > vgapci or not. > I'm not sure if I wiped out my debug patches yet, I may have a patch. > Basically the idea is to figure out which paths in the DSDT are getting > attached to the vgapci devices. devinfo -v already tells you that. For example: nexus0 acpi0 pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 pci0 hostb0 pnpinfo vendor=0x8086 device=0x0100 subvendor=0x8086 subdevice=0x2010 class=0x060000 at slot=0 function=0 pcib1 pnpinfo vendor=0x8086 device=0x0101 subvendor=0x8086 subdevice=0x2010 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.PEG1 pci1 vgapci0 pnpinfo vendor=0x10de device=0x0605 subvendor=0x3842 subdevice=0xc973 class=0x030000 at slot=0 function=0 (My desktop doesn't have acpi_video and doesn't have an ACPI handle for the vgapci device, but you can see how it displays the handle for other PCI devices like pcib1 which are in the ACPI namespace.) > It seems like we could either try to find these paths on affected > models, or have a tunable override for acpi_video. Note that the Linux discussion you posted seems a bit off. The _ADR is not supposed to be unique to the entire system. For PCI devices, _ADR contains the PCI device (slot) and function (as slot << 16 | func), and the domain:bus portion of the address is implied by the parent PCI bus device in the ACPI namespace. Thus, the specific handle assigned by ACPI is for the exact PCI location of the requisite vgapci device. If your BIOS lies it is hard for us to do anything useful, at least automatically. Do the other devices in your system that have _DOD or _DOS methods show up as unknown ACPI devices in your devinfo -v output? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 02:33:46 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9524538C; Wed, 27 Feb 2013 02:33:46 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5D710280; Wed, 27 Feb 2013 02:33:46 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id kq12so112925pab.15 for ; Tue, 26 Feb 2013 18:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8LiL99Bmq+xNM42JSz8TEHPxIx/BMzvsPekUfb/OxSQ=; b=L+K/0iocCn76PA6UsCXnTUfhSLwRqtANzB8Dme6pEQkIg1SjKlBZj6HRT0ErMM5o4W /W6ToTlGtK5QjmgWXJf53+0F78ZnnaDrilz8NvqLPhQvLoM0E+IZAZRnWpnFwLsy4XTE g51+7quBNfKvmNYqEwWp1rc9lPwD06K2e0N6v1tyC/W/hgGWTyDnowL2IxRjzLssPgQa sO+dK+np6ZVgRVxIN3HBzcgtI12QSiVogBJq5DWdnqs48uS3ztkI4EKtXDANp6GYrje6 7OQHghGzCoBc/CTlAx1BTPMgwl+HMM8QLIWzuXGGSQz+Ucos6oTtsu+SrrMVNrzQF3V0 wQwA== X-Received: by 10.66.122.74 with SMTP id lq10mr4902075pab.189.1361932420532; Tue, 26 Feb 2013 18:33:40 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id 1sm2845981pbg.18.2013.02.26.18.33.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 18:33:39 -0800 (PST) Message-ID: <512D7041.50608@gmail.com> Date: Tue, 26 Feb 2013 18:32:33 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <512C380D.5030506@gmail.com> <201302261346.46197.jhb@freebsd.org> In-Reply-To: <201302261346.46197.jhb@freebsd.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 02:33:46 -0000 On 02/26/13 10:46, John Baldwin wrote: > On Monday, February 25, 2013 11:20:29 pm matt wrote: >> On 02/25/13 18:33, Adrian Chadd wrote: >>> [101232] acpi_video0: on vgapci0 >>> found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 >>> >>> And what do I do with acpi_get_handle ? >>> >>> >>> >>> >> I threw printfs into acpi_video, not sure if that would work for both >> vgapci or not. >> I'm not sure if I wiped out my debug patches yet, I may have a patch. >> Basically the idea is to figure out which paths in the DSDT are getting >> attached to the vgapci devices. > devinfo -v already tells you that. > > For example: > > nexus0 > acpi0 > pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 > pci0 > hostb0 pnpinfo vendor=0x8086 device=0x0100 subvendor=0x8086 > subdevice=0x2010 class=0x060000 at slot=0 function=0 > pcib1 pnpinfo vendor=0x8086 device=0x0101 subvendor=0x8086 > subdevice=0x2010 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.PEG1 > pci1 > vgapci0 pnpinfo vendor=0x10de device=0x0605 subvendor=0x3842 > subdevice=0xc973 class=0x030000 at slot=0 function=0 > > (My desktop doesn't have acpi_video and doesn't have an ACPI handle for the > vgapci device, but you can see how it displays the handle for other PCI > devices like pcib1 which are in the ACPI namespace.) > >> It seems like we could either try to find these paths on affected >> models, or have a tunable override for acpi_video. > Note that the Linux discussion you posted seems a bit off. The _ADR is > not supposed to be unique to the entire system. For PCI devices, _ADR > contains the PCI device (slot) and function (as slot << 16 | func), and > the domain:bus portion of the address is implied by the parent PCI bus > device in the ACPI namespace. Thus, the specific handle assigned by ACPI > is for the exact PCI location of the requisite vgapci device. If your > BIOS lies it is hard for us to do anything useful, at least automatically. > > Do the other devices in your system that have _DOD or _DOS methods show > up as unknown ACPI devices in your devinfo -v output? It's not in devinfo at all for me, Adrian may have a different situation. So my laptop has _SB.PCI0.PEG.VID and _SB.PCI0.VID Only _SB.PCI0.VID is represented in devinfo -rv. As far as I know, PEG is not a "real" device, but an abstraction, possibly for Optimus use. It makes calls to \VIGD (integrated graphics?) and \ISOP (isOptimus?) This is potentially the broken bios part of things. I think I have multiple ACPI devices for a single physical device, and pci is attaching the wrong ACPI device to the physical device in an ivar. acpi_video happily uses this ivar to attempt to control video brightness. I could be entirely wrong on that, all I do know is that the working handle doesn't get used and the useless handle does. Matt Matt From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 13:52:35 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 81350747 for ; Wed, 27 Feb 2013 13:52:35 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 18A141CF for ; Wed, 27 Feb 2013 13:52:34 +0000 (UTC) Received: from mail.bitfrost.no (mail.bitfrost.no [46.29.221.36]) by mta.bitpro.no (Postfix) with ESMTP id 54FC47A123 for ; Wed, 27 Feb 2013 14:52:34 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bitfrost.no Received: from smtp.bitfrost.no (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hanspetter) by mail.bitfrost.no (Postfix) with ESMTPSA id 7A77720D01 for ; Wed, 27 Feb 2013 14:52:28 +0100 (CET) From: Hans Petter Selasky Organization: Bitfrost A/S To: freebsd-acpi@freebsd.org Subject: ACPI locking bugs? Date: Wed, 27 Feb 2013 14:53:43 +0100 X-Face: ?p&W)c( =?utf-8?q?+80hU=3B=27=7B=2E=245K+zq=7BoC6y=7C=0A=09/D=27an*6mw?=>j'f:eBsex\Gi, X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 13:52:35 -0000 Hi, What is the reason for using cv_wait_sig() and cv_timedwait_sig() instead of cv_wait() and cv_timedwait() inside of AcpiOsWaitSemaphore(). What signals are supposed to be catched here? switch (Timeout) { case ACPI_DO_NOT_WAIT: if (!ACPISEM_AVAIL(as, Units)) status = AE_TIME; break; case ACPI_WAIT_FOREVER: while (!ACPISEM_AVAIL(as, Units)) { as->as_waiters++; error = cv_wait_sig(&as->as_cv, &as->as_lock); as->as_waiters--; if (error == EINTR || as->as_reset) { status = AE_ERROR; break; } } break; default: tmo = timeout2hz(Timeout); while (!ACPISEM_AVAIL(as, Units)) { prevtick = ticks; as->as_waiters++; error = cv_timedwait_sig(&as->as_cv, &as->as_lock, tmo); as->as_waiters--; if (error == EINTR || as->as_reset) { status = AE_ERROR; break; } if (ACPISEM_AVAIL(as, Units)) break; slptick = ticks - prevtick; if (slptick >= tmo || slptick < 0) { status = AE_TIME; break; } tmo -= slptick; } } I've observed an issue twice on my MacBookPro that some ACPI locking fails during shutdown on 9-stable and then the power-off won't complete. I've been unable to capture the full dmesg, because syslogd is killed at the moment this happens. There are two ACPI error printouts about failed locking. I see that in the case of ACPI_WAIT_FOREVER, it appears to be incorrect to catch signals, because sometimes the return argument is not checked for lock operations: ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); Any comments? Reference: sys/dev/acpica/Osd/OsdSynch.c:AcpiOsWaitSemaphore --HPS From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 14:55:00 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 73221E04 for ; Wed, 27 Feb 2013 14:55:00 +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 AFDDB7EA for ; Wed, 27 Feb 2013 14:54:56 +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 QAA16272; Wed, 27 Feb 2013 16:54:53 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <512E1E3D.7090501@FreeBSD.org> Date: Wed, 27 Feb 2013 16:54:53 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ACPI locking bugs? References: <201302271453.43985.hps@bitfrost.no> In-Reply-To: <201302271453.43985.hps@bitfrost.no> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:55:00 -0000 on 27/02/2013 15:53 Hans Petter Selasky said the following: > Hi, > > What is the reason for using cv_wait_sig() and cv_timedwait_sig() instead of > cv_wait() and cv_timedwait() inside of AcpiOsWaitSemaphore(). What signals are > supposed to be catched here? > > switch (Timeout) { > case ACPI_DO_NOT_WAIT: > if (!ACPISEM_AVAIL(as, Units)) > status = AE_TIME; > break; > case ACPI_WAIT_FOREVER: > while (!ACPISEM_AVAIL(as, Units)) { > as->as_waiters++; > error = cv_wait_sig(&as->as_cv, &as->as_lock); > as->as_waiters--; > if (error == EINTR || as->as_reset) { > status = AE_ERROR; > break; > } > } > break; > default: > tmo = timeout2hz(Timeout); > while (!ACPISEM_AVAIL(as, Units)) { > prevtick = ticks; > as->as_waiters++; > error = cv_timedwait_sig(&as->as_cv, &as->as_lock, > tmo); > as->as_waiters--; > if (error == EINTR || as->as_reset) { > status = AE_ERROR; > break; > } > if (ACPISEM_AVAIL(as, Units)) > break; > slptick = ticks - prevtick; > if (slptick >= tmo || slptick < 0) { > status = AE_TIME; > break; > } > tmo -= slptick; > } > } > > I've observed an issue twice on my MacBookPro that some ACPI locking fails > during shutdown on 9-stable and then the power-off won't complete. I've been > unable to capture the full dmesg, because syslogd is killed at the moment this > happens. There are two ACPI error printouts about failed locking. > > I see that in the case of ACPI_WAIT_FOREVER, it appears to be incorrect to > catch signals, because sometimes the return argument is not checked for lock > operations: > > ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); > ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); > ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); > > Any comments? kib drew my attention to this issue some time ago and I also pinged jkim about it. I completely agree with you that the signal handling should be removed. Are you willing to make the change or would you prefer me doing it? Thank you. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 15:16:31 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 30AD668F; Wed, 27 Feb 2013 15:16:31 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id E74D8921; Wed, 27 Feb 2013 15:16:30 +0000 (UTC) Received: from mail.bitfrost.no (mail.bitfrost.no [46.29.221.36]) by mta.bitpro.no (Postfix) with ESMTP id DFCC87A11C; Wed, 27 Feb 2013 16:16:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bitfrost.no Received: from smtp.bitfrost.no (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hanspetter) by mail.bitfrost.no (Postfix) with ESMTPSA id 7132220764; Wed, 27 Feb 2013 16:16:23 +0100 (CET) From: Hans Petter Selasky Organization: Bitfrost A/S To: Andriy Gapon Subject: Re: ACPI locking bugs? Date: Wed, 27 Feb 2013 16:17:38 +0100 References: <201302271453.43985.hps@bitfrost.no> <512E1E3D.7090501@FreeBSD.org> In-Reply-To: <512E1E3D.7090501@FreeBSD.org> X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:16:31 -0000 On Wednesday 27 February 2013 15:54:53 Andriy Gapon wrote: > kib drew my attention to this issue some time ago and I also pinged jkim > about it. I completely agree with you that the signal handling should be > removed. Are you willing to make the change or would you prefer me doing > it? > > Thank you. Hi, Please make the change and don't forget to MFC. --HPS From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 15:22:56 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DC75F843 for ; Wed, 27 Feb 2013 15:22:56 +0000 (UTC) (envelope-from kron24@gmail.com) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id 5C075985 for ; Wed, 27 Feb 2013 15:22:56 +0000 (UTC) Received: by mail-ea0-f169.google.com with SMTP id d13so53257eaa.14 for ; Wed, 27 Feb 2013 07:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=IW0jM/Zsm0ymRgmQIFux1mLZimSQonQysaK2MvFm2gI=; b=iX1L22aUvIQ1MWwF/XYPnpoGNIslDw5F7M0xCZPC0RF8Xzux79imx2vzTYqZRAUzUs IWB7UHF87ug2Um1DhtAp2pJk6kd77GJLlK1NdCyTmbU7KxzAItDyco0kseDpCXAiaR7P z3itv72SdQ/57igdJS0apaGyvOS8SFtUwJBjocMLJAQEYFVW8t66N9a2NoKb4vwbVaao bB+gcuuLhiynnf6KBqgiO8xBvv+3eCNYr4MQ/cbnDz+zCmQqGMBavZgeWWtB3fuPSZwe M2c2jUFJaN977MNRo2zmgr592fhGMz8y3r87KzscvZ3Zt+WH9GurtzOoBM/Q8Y7pgH1z 8Vgw== X-Received: by 10.14.219.129 with SMTP id m1mr7089149eep.16.1361978575336; Wed, 27 Feb 2013 07:22:55 -0800 (PST) Received: from nbvk.local (uidzr185150.sattnet.cz. [212.96.185.150]) by mx.google.com with ESMTPS id o3sm6941811eem.15.2013.02.27.07.22.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 07:22:54 -0800 (PST) Message-ID: <512E24CD.9090404@gmail.com> Date: Wed, 27 Feb 2013 16:22:53 +0100 From: kron User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130225 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Subject: panics due to buggy ACPI in Dell Latitude E6530? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:22:56 -0000 Hi, I have a Dell notebook (Latitude E6530) on which I track 9-STABLE. It served excellently until mid-Jan when it started to panic a few times a week or so: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x10116 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff802bc360 stack pointer = 0x28:0xffffff848f6db390 frame pointer = 0x28:0xffffff848f6db3c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2199 (conky) trap number = 12 panic: page fault cpuid = 3 Before the panics kernel used to emit messages like: ACPI Error: No object attached to node 0xfffffe00094a51c0 (20110527/exresnte-138) ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node 0xfffffe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113) I suspected it started with a BIOS update (A07 -> A09). Following the handbook, I took a look at acpidump. Sad to say, it all was Greek to me, I could't even compile it back using iasl (35 Errors). However, while skimming it I noticed names of many versions of Windows and in addition to that, "Linux". Just to try, I put hw.acpi.osname="Linux" to /boot/loader.conf. Since that I've never get the panic again (for ~3 weeks). I hope this is not just a coincidence. Maybe this experience can help somebody else. If any of ACPI developers wants to play with the problem I can provide more info (sorry, no crashdump, was not enabled), do tests, etc. BR Oli From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 15:55:42 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5B4041E0 for ; Wed, 27 Feb 2013 15:55:42 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id 45370ABE for ; Wed, 27 Feb 2013 15:55:41 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 27 Feb 2013 07:54:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,747,1355126400"; d="scan'208";a="292575576" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga001.fm.intel.com with ESMTP; 27 Feb 2013 07:54:33 -0800 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.110]) by ORSMSX105.amr.corp.intel.com ([169.254.4.65]) with mapi id 14.01.0355.002; Wed, 27 Feb 2013 07:54:33 -0800 From: "Moore, Robert" To: kron , "freebsd-acpi@freebsd.org" Subject: RE: panics due to buggy ACPI in Dell Latitude E6530? Thread-Topic: panics due to buggy ACPI in Dell Latitude E6530? Thread-Index: AQHOFP6EIv1sLdcnwk6Q2HNM5KvUUpiN21uA Date: Wed, 27 Feb 2013 15:54:33 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E36F476331@ORSMSX101.amr.corp.intel.com> References: <512E24CD.9090404@gmail.com> In-Reply-To: <512E24CD.9090404@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:55:42 -0000 Please forward the acpidump for the machine, thanks. Bob > -----Original Message----- > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > acpi@freebsd.org] On Behalf Of kron > Sent: Wednesday, February 27, 2013 7:23 AM > To: freebsd-acpi@freebsd.org > Subject: panics due to buggy ACPI in Dell Latitude E6530? >=20 > Hi, >=20 > I have a Dell notebook (Latitude E6530) on which I track 9-STABLE. It > served excellently until mid-Jan when it started to panic a few times a > week or so: >=20 > Fatal trap 12: page fault while in kernel mode cpuid =3D 3; apic id =3D 0= 3 > fault virtual address =3D 0x10116 > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff802bc360 > stack pointer =3D 0x28:0xffffff848f6db390 > frame pointer =3D 0x28:0xffffff848f6db3c0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 2199 (conky) > trap number =3D 12 > panic: page fault > cpuid =3D 3 >=20 > Before the panics kernel used to emit messages like: > ACPI Error: No object attached to node 0xfffffe00094a51c0 > (20110527/exresnte-138) > ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node > 0xfffffe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113) >=20 > I suspected it started with a BIOS update (A07 -> A09). > Following the handbook, I took a look at acpidump. Sad to say, it all was > Greek to me, I could't even compile it back using iasl (35 Errors). > However, while skimming it I noticed names of many versions of Windows an= d > in addition to that, "Linux". > Just to try, I put hw.acpi.osname=3D"Linux" to /boot/loader.conf. > Since that I've never get the panic again (for ~3 weeks). > I hope this is not just a coincidence. >=20 > Maybe this experience can help somebody else. >=20 > If any of ACPI developers wants to play with the problem I can provide > more info (sorry, no crashdump, was not enabled), do tests, etc. >=20 > BR > Oli > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 16:51:14 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9ED0916D for ; Wed, 27 Feb 2013 16:51:14 +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 E3EB8E1F for ; Wed, 27 Feb 2013 16:51:13 +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 SAA17174; Wed, 27 Feb 2013 18:51:10 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <512E397D.1070406@FreeBSD.org> Date: Wed, 27 Feb 2013 18:51:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: kron Subject: Re: panics due to buggy ACPI in Dell Latitude E6530? References: <512E24CD.9090404@gmail.com> In-Reply-To: <512E24CD.9090404@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:51:14 -0000 on 27/02/2013 17:22 kron said the following: > Hi, > > I have a Dell notebook (Latitude E6530) on which I track > 9-STABLE. It served excellently until mid-Jan when it started > to panic a few times a week or so: > > Fatal trap 12: page fault while in kernel mode > cpuid = 3; apic id = 03 > fault virtual address = 0x10116 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff802bc360 > stack pointer = 0x28:0xffffff848f6db390 > frame pointer = 0x28:0xffffff848f6db3c0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 2199 (conky) > trap number = 12 > panic: page fault > cpuid = 3 > > Before the panics kernel used to emit messages like: > ACPI Error: No object attached to node 0xfffffe00094a51c0 > (20110527/exresnte-138) > ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node > 0xfffffe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113) This looks very much like a heisenbug reported several times here. E.g.: http://lists.freebsd.org/pipermail/freebsd-acpi/2012-December/007962.html > I suspected it started with a BIOS update (A07 -> A09). > Following the handbook, I took a look at acpidump. Sad to say, > it all was Greek to me, I could't even compile it back using > iasl (35 Errors). However, while skimming it I noticed names > of many versions of Windows and in addition to that, "Linux". > Just to try, I put hw.acpi.osname="Linux" to /boot/loader.conf. > Since that I've never get the panic again (for ~3 weeks). > I hope this is not just a coincidence. It very well could be. > Maybe this experience can help somebody else. > > If any of ACPI developers wants to play with the problem > I can provide more info (sorry, no crashdump, was not enabled), > do tests, etc. Please at least enable printing of a stack trace. Better do get the crash dump. P.S. I suspect that the issue we are discussing with hps in this mailing list could be related to this problem. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 17:12:51 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1106D9B2; Wed, 27 Feb 2013 17:12:51 +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 D5CB7F77; Wed, 27 Feb 2013 17:12:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3E588B976; Wed, 27 Feb 2013 12:12:50 -0500 (EST) From: John Baldwin To: matt Subject: Re: Fixing X220 Video The Right Way Date: Wed, 27 Feb 2013 12:00:22 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> <201302261346.46197.jhb@freebsd.org> <512D7041.50608@gmail.com> In-Reply-To: <512D7041.50608@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201302271200.22976.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Feb 2013 12:12:50 -0500 (EST) Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 17:12:51 -0000 On Tuesday, February 26, 2013 9:32:33 pm matt wrote: > On 02/26/13 10:46, John Baldwin wrote: > > On Monday, February 25, 2013 11:20:29 pm matt wrote: > >> On 02/25/13 18:33, Adrian Chadd wrote: > >>> [101232] acpi_video0: on vgapci0 > >>> found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 > >>> > >>> And what do I do with acpi_get_handle ? > >>> > >>> > >>> > >>> > >> I threw printfs into acpi_video, not sure if that would work for both > >> vgapci or not. > >> I'm not sure if I wiped out my debug patches yet, I may have a patch. > >> Basically the idea is to figure out which paths in the DSDT are getting > >> attached to the vgapci devices. > > devinfo -v already tells you that. > > > > For example: > > > > nexus0 > > acpi0 > > pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 > > pci0 > > hostb0 pnpinfo vendor=0x8086 device=0x0100 subvendor=0x8086 > > subdevice=0x2010 class=0x060000 at slot=0 function=0 > > pcib1 pnpinfo vendor=0x8086 device=0x0101 subvendor=0x8086 > > subdevice=0x2010 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.PEG1 > > pci1 > > vgapci0 pnpinfo vendor=0x10de device=0x0605 subvendor=0x3842 > > subdevice=0xc973 class=0x030000 at slot=0 function=0 > > > > (My desktop doesn't have acpi_video and doesn't have an ACPI handle for the > > vgapci device, but you can see how it displays the handle for other PCI > > devices like pcib1 which are in the ACPI namespace.) > > > >> It seems like we could either try to find these paths on affected > >> models, or have a tunable override for acpi_video. > > Note that the Linux discussion you posted seems a bit off. The _ADR is > > not supposed to be unique to the entire system. For PCI devices, _ADR > > contains the PCI device (slot) and function (as slot << 16 | func), and > > the domain:bus portion of the address is implied by the parent PCI bus > > device in the ACPI namespace. Thus, the specific handle assigned by ACPI > > is for the exact PCI location of the requisite vgapci device. If your > > BIOS lies it is hard for us to do anything useful, at least automatically. > > > > Do the other devices in your system that have _DOD or _DOS methods show > > up as unknown ACPI devices in your devinfo -v output? > It's not in devinfo at all for me, Adrian may have a different situation. > > So my laptop has _SB.PCI0.PEG.VID and _SB.PCI0.VID > Only _SB.PCI0.VID is represented in devinfo -rv. > As far as I know, PEG is not a "real" device, but an abstraction, > possibly for Optimus use. > It makes calls to \VIGD (integrated graphics?) and \ISOP (isOptimus?) > This is potentially the broken bios part of things. > > I think I have multiple ACPI devices for a single physical device, and > pci is attaching the wrong ACPI device to the physical device in an ivar. > acpi_video happily uses this ivar to attempt to control video brightness. > > I could be entirely wrong on that, all I do know is that the working > handle doesn't get used and the useless handle does. If that is true, it's because your BIOS is lying. Do you have a URL to your ASL lying around already? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 18:14:42 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0E1DFEB for ; Wed, 27 Feb 2013 18:14:42 +0000 (UTC) (envelope-from kron24@gmail.com) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by mx1.freebsd.org (Postfix) with ESMTP id A1DA337A for ; Wed, 27 Feb 2013 18:14:41 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id d17so751295eek.38 for ; Wed, 27 Feb 2013 10:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FACXQmBodgKt5EjovJ+TjbU6IEuIRrdga1dIPo6answ=; b=dL5X3HyK6bOC6/oCHlBwcWDf6Dx7hYFNVJ0u0itiFnSr3t5QMaUWCXG/ZyA22kEGRA IOPqd4IaksKPTJKNEAJmk1k0L0SIu0JPbWet/IqZZ8v871e6aKWyV3y56IIUd/XmmScs Jw4tGESQwslOV3OH5OXByEtfyFYJgndLY4Cn5w7G3coiJeqndw2z7fjnL3P20CQNCEVE CbfuhOIxZbepTVakpOKkbJtMXrHUwUcbf0xR9xKI5snzTeUWgrcCgRkOEZS9+M2SDQiQ ec38JfmcWBretrzG/538ElSUarJ8INhJ7Pyhi9Wyd08V70Fi3t7/WDAo7eKRwNp8Eo9b I4NQ== X-Received: by 10.15.100.202 with SMTP id bn50mr8318811eeb.36.1361988874757; Wed, 27 Feb 2013 10:14:34 -0800 (PST) Received: from nbvk.local (uidzr185150.sattnet.cz. [212.96.185.150]) by mx.google.com with ESMTPS id o3sm7716813eem.15.2013.02.27.10.14.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 10:14:34 -0800 (PST) Message-ID: <512E4D08.50303@gmail.com> Date: Wed, 27 Feb 2013 19:14:32 +0100 From: kron User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130225 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Subject: Re: panics due to buggy ACPI in Dell Latitude E6530? References: <512E24CD.9090404@gmail.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36F476331@ORSMSX101.amr.corp.intel.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E36F476331@ORSMSX101.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:14:42 -0000 On 2013/02/27 16:54, Moore, Robert wrote: > Please forward the acpidump for the machine, thanks. > Bob http://pastebin.com/00KwJsEy BR Oli From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 18:32:23 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 922D3A77 for ; Wed, 27 Feb 2013 18:32:23 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id 6F2D26CE for ; Wed, 27 Feb 2013 18:32:23 +0000 (UTC) Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 27 Feb 2013 10:31:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,749,1355126400"; d="scan'208";a="206977820" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by AZSMGA002.ch.intel.com with ESMTP; 27 Feb 2013 10:31:14 -0800 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.110]) by ORSMSX105.amr.corp.intel.com ([169.254.4.65]) with mapi id 14.01.0355.002; Wed, 27 Feb 2013 10:31:14 -0800 From: "Moore, Robert" To: kron , "freebsd-acpi@freebsd.org" Subject: RE: panics due to buggy ACPI in Dell Latitude E6530? Thread-Topic: panics due to buggy ACPI in Dell Latitude E6530? Thread-Index: AQHOFP6EIv1sLdcnwk6Q2HNM5KvUUpiN21uAgACtWAD//35lwA== Date: Wed, 27 Feb 2013 18:31:13 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E36F476404@ORSMSX101.amr.corp.intel.com> References: <512E24CD.9090404@gmail.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36F476331@ORSMSX101.amr.corp.intel.com> <512E4D08.50303@gmail.com> In-Reply-To: <512E4D08.50303@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:32:23 -0000 I need the binary tables, or the actual output of acpidump, not the disasse= mbled code. Thanks, Bob > -----Original Message----- > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > acpi@freebsd.org] On Behalf Of kron > Sent: Wednesday, February 27, 2013 10:15 AM > To: freebsd-acpi@freebsd.org > Subject: Re: panics due to buggy ACPI in Dell Latitude E6530? >=20 > On 2013/02/27 16:54, Moore, Robert wrote: > > Please forward the acpidump for the machine, thanks. > > Bob >=20 > http://pastebin.com/00KwJsEy >=20 > BR > Oli >=20 >=20 > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 18:36:53 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A78D8AE3; Wed, 27 Feb 2013 18:36:53 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by mx1.freebsd.org (Postfix) with ESMTP id 5CBD26F4; Wed, 27 Feb 2013 18:36:53 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id hz10so596853pad.7 for ; Wed, 27 Feb 2013 10:36:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xMKxkaPCNudB3g5ea+qbCl8PotRXE2vhXm1vyKsnB1w=; b=IUM1wlPDAPjlJ1OdH/Mvakbk1INczJitTsEasflGCZxQuf2fCIc3AYxR8P8RlVHTo/ S8KW5CLjEteuI0KduJI07eNkI6NIb0m4S4mGKQkO/d88jGbBAbCxBiy//L5W9dBsEgCj aOFwjBWdEOFqOFuKMNRR6bjb5z+jAvriysc2Z7DizsBnV6dV/LGh3qebPH+x9/ZsQPMN xCpw1PHx5YMcqJs24vm+YH+dfjY8Wk8lvAfY+G0koMbFsKEQv/9O3tC+KJdEOxqSkTkY QF+4a5tPT22w5VyktFM2U1M27pD5si7yNd1XrpIO3degWugP3nqfnk45zAaMhMAepOhb s0Uw== X-Received: by 10.66.157.100 with SMTP id wl4mr9236167pab.84.1361990207614; Wed, 27 Feb 2013 10:36:47 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id mz8sm2799529pbc.9.2013.02.27.10.36.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 10:36:46 -0800 (PST) Message-ID: <512E51FF.5010701@gmail.com> Date: Wed, 27 Feb 2013 10:35:43 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <201302261346.46197.jhb@freebsd.org> <512D7041.50608@gmail.com> <201302271200.22976.jhb@freebsd.org> In-Reply-To: <201302271200.22976.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:36:53 -0000 On 02/27/13 09:00, John Baldwin wrote: > If that is true, it's because your BIOS is lying. Do you have a URL to > your ASL lying around already? Too big for pastebin :( +500k https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing Thanks, Matt From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 19:30:12 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 31699EED for ; Wed, 27 Feb 2013 19:30:12 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E2AD299E; Wed, 27 Feb 2013 19:30:11 +0000 (UTC) Message-ID: <512E5E4C.807@FreeBSD.org> Date: Wed, 27 Feb 2013 14:28:12 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ACPI locking bugs? References: <201302271453.43985.hps@bitfrost.no> In-Reply-To: <201302271453.43985.hps@bitfrost.no> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 19:30:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-02-27 08:53:43 -0500, Hans Petter Selasky wrote: > Hi, > > What is the reason for using cv_wait_sig() and cv_timedwait_sig() > instead of cv_wait() and cv_timedwait() inside of > AcpiOsWaitSemaphore(). What signals are supposed to be catched > here? > > switch (Timeout) { case ACPI_DO_NOT_WAIT: if (!ACPISEM_AVAIL(as, > Units)) status = AE_TIME; break; case ACPI_WAIT_FOREVER: while > (!ACPISEM_AVAIL(as, Units)) { as->as_waiters++; error = > cv_wait_sig(&as->as_cv, &as->as_lock); as->as_waiters--; if (error > == EINTR || as->as_reset) { status = AE_ERROR; break; } } break; > default: tmo = timeout2hz(Timeout); while (!ACPISEM_AVAIL(as, > Units)) { prevtick = ticks; as->as_waiters++; error = > cv_timedwait_sig(&as->as_cv, &as->as_lock, tmo); as->as_waiters--; > if (error == EINTR || as->as_reset) { status = AE_ERROR; break; } > if (ACPISEM_AVAIL(as, Units)) break; slptick = ticks - prevtick; if > (slptick >= tmo || slptick < 0) { status = AE_TIME; break; } tmo -= > slptick; } } > > I've observed an issue twice on my MacBookPro that some ACPI > locking fails during shutdown on 9-stable and then the power-off > won't complete. I've been unable to capture the full dmesg, because > syslogd is killed at the moment this happens. There are two ACPI > error printouts about failed locking. > > I see that in the case of ACPI_WAIT_FOREVER, it appears to be > incorrect to catch signals, because sometimes the return argument > is not checked for lock operations: > > ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); > ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); > ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); > > Any comments? > > Reference: sys/dev/acpica/Osd/OsdSynch.c:AcpiOsWaitSemaphore I don't exactly remember why it was written like that, sorry. Probably it was to work around broken mutex uses in ACPICA at the time. FYI, many ACPICA patches are contributed by Linux developers. Unfortunately, the Linux OS-dependent code does not implement the ACPICA OSL API fully and omits some corner cases. [1] For example, ACPICA mutex is implemented via semaphore: http://lxr.linux.no/#linux+v3.8/include/acpi/platform/aclinux.h#L51 http://lxr.linux.no/#linux+v3.8/include/acpi/actypes.h#L239 And the semaphore does not support unit > 1 and ACPI_WAIT_FOREVER: http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1227 So, a lot of locking related ACPICA patches ignored these corner cases. Another problem is that we are very serious about locking orders but ACPICA doesn't really care much because Linux and others don't care, really. Another example is the ACPICA "cache" allocator. It is actually modeled after Linux's slab allocator, i.e., kmem_cache_*(): http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1636 Unfortunately, it doesn't really fit into our closest KPI, i.e., zone(9). [2] We always tried our best to *fully* implement OSL but it is not an easy task. :-( Jung-uk Kim 1. For the official ACPICA OS-dependent API, please see "ACPI Component Architecture User Guide and Programmer Reference". You can get it from here: https://www.acpica.org/documentation/ 2. There were some patches but I am not really comfortable with any of these patches yet. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRLl5MAAoJECXpabHZMqHOyi0IAMbzAggbm+XRlVeSFaEtZpvc 6VyceBmTh/OBgO8rdUEXbWuY/CpyQixYBlKIowDa+vJrzhAbA1louywWRvLXlfCc sbw6yGsX8gMbucU648duTDTePw80JxMLs/Rl7aSXm4Rq+wVNRlnBzs/pOrLjdhfU 0ChK+atphQED9DKNfa7aYAlkANaQ6pDgI03E8Te8Bu5zeflaaSpj2rE7VLlXH/kK XBbO+83Tsy7/gBdWqdTXtVP2FQQvg39M932ZeD0qFaefd25R9yVr6UppqIF4BtIO dq9yavmZbkmkM9bstWPdu6D8pV9UlsbyAk6dseXNwpiL1adkacAsigwcXoSa6mE= =o9HQ -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 20:35:03 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A63EBF1; Wed, 27 Feb 2013 20:35:03 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx1.freebsd.org (Postfix) with ESMTP id 421F9DB9; Wed, 27 Feb 2013 20:35:03 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 27 Feb 2013 12:33:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,750,1355126400"; d="scan'208";a="292704295" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga001.fm.intel.com with ESMTP; 27 Feb 2013 12:33:55 -0800 Received: from orsmsx151.amr.corp.intel.com (10.22.226.38) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 27 Feb 2013 12:33:55 -0800 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.110]) by ORSMSX151.amr.corp.intel.com ([169.254.7.6]) with mapi id 14.01.0355.002; Wed, 27 Feb 2013 12:33:54 -0800 From: "Moore, Robert" To: Jung-uk Kim , Hans Petter Selasky Subject: RE: ACPI locking bugs? Thread-Topic: ACPI locking bugs? Thread-Index: AQHOFPHG6NrttiKZBk2hHOKVWhXgJpiOnWIA//+K//A= Date: Wed, 27 Feb 2013 20:33:53 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E36F4764A6@ORSMSX101.amr.corp.intel.com> References: <201302271453.43985.hps@bitfrost.no> <512E5E4C.807@FreeBSD.org> In-Reply-To: <512E5E4C.807@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:35:03 -0000 A couple comments below. > -----Original Message----- > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > acpi@freebsd.org] On Behalf Of Jung-uk Kim > Sent: Wednesday, February 27, 2013 11:28 AM > To: Hans Petter Selasky > Cc: freebsd-acpi@freebsd.org > Subject: Re: ACPI locking bugs? >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 2013-02-27 08:53:43 -0500, Hans Petter Selasky wrote: > > Hi, > > > > What is the reason for using cv_wait_sig() and cv_timedwait_sig() > > instead of cv_wait() and cv_timedwait() inside of > > AcpiOsWaitSemaphore(). What signals are supposed to be catched here? > > > > switch (Timeout) { case ACPI_DO_NOT_WAIT: if (!ACPISEM_AVAIL(as, > > Units)) status =3D AE_TIME; break; case ACPI_WAIT_FOREVER: while > > (!ACPISEM_AVAIL(as, Units)) { as->as_waiters++; error =3D > > cv_wait_sig(&as->as_cv, &as->as_lock); as->as_waiters--; if (error =3D= =3D > > EINTR || as->as_reset) { status =3D AE_ERROR; break; } } break; > > default: tmo =3D timeout2hz(Timeout); while (!ACPISEM_AVAIL(as, > > Units)) { prevtick =3D ticks; as->as_waiters++; error =3D > > cv_timedwait_sig(&as->as_cv, &as->as_lock, tmo); as->as_waiters--; if > > (error =3D=3D EINTR || as->as_reset) { status =3D AE_ERROR; break; } if > > (ACPISEM_AVAIL(as, Units)) break; slptick =3D ticks - prevtick; if > > (slptick >=3D tmo || slptick < 0) { status =3D AE_TIME; break; } tmo -= =3D > > slptick; } } > > > > I've observed an issue twice on my MacBookPro that some ACPI locking > > fails during shutdown on 9-stable and then the power-off won't > > complete. I've been unable to capture the full dmesg, because syslogd > > is killed at the moment this happens. There are two ACPI error > > printouts about failed locking. > > > > I see that in the case of ACPI_WAIT_FOREVER, it appears to be > > incorrect to catch signals, because sometimes the return argument is > > not checked for lock operations: > > > > ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex > > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); > > ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex > > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); > > ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex > > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); > > > > Any comments? > > > > Reference: sys/dev/acpica/Osd/OsdSynch.c:AcpiOsWaitSemaphore >=20 > I don't exactly remember why it was written like that, sorry. > Probably it was to work around broken mutex uses in ACPICA at the time. >=20 > FYI, many ACPICA patches are contributed by Linux developers. > Unfortunately, the Linux OS-dependent code does not implement the ACPICA > OSL API fully and omits some corner cases. [1] >=20 > For example, ACPICA mutex is implemented via semaphore: >=20 > http://lxr.linux.no/#linux+v3.8/include/acpi/platform/aclinux.h#L51 > http://lxr.linux.no/#linux+v3.8/include/acpi/actypes.h#L239 >=20 > And the semaphore does not support unit > 1 and ACPI_WAIT_FOREVER: >=20 > http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1227 >=20 > So, a lot of locking related ACPICA patches ignored these corner cases. > Another problem is that we are very serious about locking orders but > ACPICA doesn't really care much because Linux and others don't care, > really. I believe that ACPICA does in fact worry about locking order. We have an or= dered list of the mutex objects that are used internally, and at least in d= ebug mode, it checks to make sure that the ordering is correct, for both ac= quire and release. >=20 > Another example is the ACPICA "cache" allocator. It is actually modeled > after Linux's slab allocator, i.e., kmem_cache_*(): >=20 > http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1636 >=20 > Unfortunately, it doesn't really fit into our closest KPI, i.e., zone(9). > [2] >=20 You can, of course do one of these: 1) Use the default ACPICA cache allocator 2) Configure ACPICA to just not use any caching (if your memory allocat= or will suffice.) > We always tried our best to *fully* implement OSL but it is not an easy > task. :-( >=20 > Jung-uk Kim >=20 > 1. For the official ACPICA OS-dependent API, please see "ACPI Component > Architecture User Guide and Programmer Reference". You can get it from > here: >=20 > https://www.acpica.org/documentation/ >=20 > 2. There were some patches but I am not really comfortable with any of > these patches yet. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (FreeBSD) >=20 > iQEcBAEBAgAGBQJRLl5MAAoJECXpabHZMqHOyi0IAMbzAggbm+XRlVeSFaEtZpvc > 6VyceBmTh/OBgO8rdUEXbWuY/CpyQixYBlKIowDa+vJrzhAbA1louywWRvLXlfCc > sbw6yGsX8gMbucU648duTDTePw80JxMLs/Rl7aSXm4Rq+wVNRlnBzs/pOrLjdhfU > 0ChK+atphQED9DKNfa7aYAlkANaQ6pDgI03E8Te8Bu5zeflaaSpj2rE7VLlXH/kK > XBbO+83Tsy7/gBdWqdTXtVP2FQQvg39M932ZeD0qFaefd25R9yVr6UppqIF4BtIO > dq9yavmZbkmkM9bstWPdu6D8pV9UlsbyAk6dseXNwpiL1adkacAsigwcXoSa6mE=3D > =3Do9HQ > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 22:08:53 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5FC33D6B; Wed, 27 Feb 2013 22:08:53 +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 3D5803C9; Wed, 27 Feb 2013 22:08:53 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 747FAB97C; Wed, 27 Feb 2013 17:08:52 -0500 (EST) From: John Baldwin To: matt Subject: Re: Fixing X220 Video The Right Way Date: Wed, 27 Feb 2013 15:27:36 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> <201302271200.22976.jhb@freebsd.org> <512E51FF.5010701@gmail.com> In-Reply-To: <512E51FF.5010701@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302271527.37079.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Feb 2013 17:08:52 -0500 (EST) Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 22:08:53 -0000 On Wednesday, February 27, 2013 1:35:43 pm matt wrote: > On 02/27/13 09:00, John Baldwin wrote: > > If that is true, it's because your BIOS is lying. Do you have a URL to > > your ASL lying around already? > Too big for pastebin :( +500k > > https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing Here is where I find _DOD and _DOS methods: Device (PCI0) Device (VID) Name (_ADR, 0x00020000) // _ADR: Address Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices Device (PEG) Name (_ADR, 0x00010000) // _ADR: Address Device (VID) Name (_ADR, 0x00) // _ADR: Address Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices PCI0.VID is a PCI device at pci0:0:2:0. PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0. It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the X220 have a switchable GPU (e.g. it has built-in Intel graphics, but also has an Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel graphics and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to determine that. If both PCI devices exist you shoudl have both acpi_video0 and acpi_video1. However, it may be that the acpi_video driver doesn't cope well with having multiple devices. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 00:54:59 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9576F8A8; Thu, 28 Feb 2013 00:54:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by mx1.freebsd.org (Postfix) with ESMTP id D77D3E30; Thu, 28 Feb 2013 00:54:58 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id dr13so973291wgb.26 for ; Wed, 27 Feb 2013 16:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yCgCqUxiYjEvQWOoqPXzCV6uPTMmMZvnQgVWrW0PO9w=; b=VbtNdn6Vq4GgDfmEmbuYHDDIGXEEHafQjwkgEI2Hj1W/rZK2pmJDYgPC/tPJ32F7JW Dni1Ec3/aUmKr/MuYOz97GHsvJTHUuofGI28OW6AW9Xc8kgJs/XsxuJWImGwqNB8+tTH HkyM1nvIKLrYa9W17NrlgVnv5Q2fMcrd25qMjJLdc3AVMSdc/ICWU4H588f+kawsCJFX SOyjXfuCeZXmzZ2K7/w1BFQxlTVEJ5rDD1XH6TNupRcSXhcm7u/XfTeMrbniY7D5cNic PsJ8DnILvvuRGDM+1orhyCENa+YL52o/QB1CVSos0GdkY46e4wWpKRXZtkFt9GIPLI0L E4QA== MIME-Version: 1.0 X-Received: by 10.194.110.69 with SMTP id hy5mr7636507wjb.1.1362012897696; Wed, 27 Feb 2013 16:54:57 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Wed, 27 Feb 2013 16:54:57 -0800 (PST) In-Reply-To: <201302271527.37079.jhb@freebsd.org> References: <512A6FFF.2060603@gmail.com> <201302271200.22976.jhb@freebsd.org> <512E51FF.5010701@gmail.com> <201302271527.37079.jhb@freebsd.org> Date: Wed, 27 Feb 2013 16:54:57 -0800 X-Google-Sender-Auth: 10Le-jUNLA285hl3EjvWs9YXCoA Message-ID: Subject: Re: Fixing X220 Video The Right Way From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 00:54:59 -0000 I'll email later, but I do have two PCI devices show up in pciconf -lv; but acpi_video() only attaches to one. I don't know why two PCI devices show up.. guess there's more digging to do. ADrian From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 02:07:12 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8BE01488; Thu, 28 Feb 2013 02:07:12 +0000 (UTC) (envelope-from erich@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id B78AF1B0; Thu, 28 Feb 2013 02:07:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=AKwR7iI059Jq3kJy6WTnv83JYf70UOw4BKDdgQj2h+M=; b=PArHlRHYD+vttBmCRk+TMOwp1YLqny0pqxaDB/eleAeJf5zZERCx0GdBCrZVShv+47VsbRdq7AJdC1Kq9bkynUZGzoR/UoMmQKc42WN53fHOEYtQ/eQzFrXfnI37SgdI; Received: from [122.129.203.50] (port=50591 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UAsTK-00244A-SC; Wed, 27 Feb 2013 18:39:49 -0700 Date: Thu, 28 Feb 2013 08:39:22 +0700 From: Erich Dollansky To: John Baldwin Subject: Re: Fixing X220 Video The Right Way Message-ID: <20130228083922.31229fe0@X220.ovitrap.com> In-Reply-To: <201302271527.37079.jhb@freebsd.org> References: <512A6FFF.2060603@gmail.com> <201302271200.22976.jhb@freebsd.org> <512E51FF.5010701@gmail.com> <201302271527.37079.jhb@freebsd.org> Organization: ALO Green Technologies X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erich@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 02:07:12 -0000 Hi, On Wed, 27 Feb 2013 15:27:36 -0500 John Baldwin wrote: > On Wednesday, February 27, 2013 1:35:43 pm matt wrote: > > On 02/27/13 09:00, John Baldwin wrote: > > > If that is true, it's because your BIOS is lying. Do you have a > > > URL to your ASL lying around already? > > Too big for pastebin :( +500k > > > > https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing > > the X220 have a switchable GPU (e.g. it has built-in Intel graphics, it has. > but also has an Nvidia GPU or some such?). If so, I imagine that No, it does not. > PCI0.VID is the Intel graphics and PEG is the non-Intel. The output > of 'pciconf -lcv' would be useful to determine that. If both PCI > devices exist you shoudl have both acpi_video0 and acpi_video1. > However, it may be that the acpi_video driver doesn't cope well with > having multiple devices. > Erich PS Here is the output: hostb0@pci0:0:0:0: class=0x060000 card=0x21da17aa chip=0x01048086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family DRAM Controller' class = bridge subclass = HOST-PCI cap 09[e0] = vendor (length 12) Intel cap 0 version 1 vgapci0@pci0:0:2:0: class=0x030000 card=0x21da17aa chip=0x01268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA cap 05[90] = MSI supports 1 message enabled with 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP none0@pci0:0:22:0: class=0x078000 card=0x21da17aa chip=0x1c3a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family MEI Controller' class = simple comms cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[8c] = MSI supports 1 message, 64 bit uart2@pci0:0:22:3: class=0x070002 card=0x21da17aa chip=0x1c3d8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family KT Controller' class = simple comms subclass = UART cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit em0@pci0:0:25:0: class=0x020000 card=0x21ce17aa chip=0x15028086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82579LM Gigabit Network Connection' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP ehci0@pci0:0:26:0: class=0x0c0320 card=0x21da17aa chip=0x1c2d8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family USB Enhanced Host Controller' class = serial bus subclass = USB cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP hdac0@pci0:0:27:0: class=0x040300 card=0x21da17aa chip=0x1c208086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family High Definition Audio Controller' class = multimedia subclass = HDA cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[60] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[70] = PCI-Express 1 root endpoint max data 128(128) FLR link x0(x0) ecap 0002[100] = VC 1 max VC1 ecap 0005[130] = Root Complex Link Declaration 1 pcib1@pci0:0:28:0: class=0x060400 card=0x21da17aa chip=0x1c108086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 1' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x0(x1) speed 0.0(5.0) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib2@pci0:0:28:1: class=0x060400 card=0x21da17aa chip=0x1c128086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 2' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x1(x1) speed 2.5(5.0) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib3@pci0:0:28:3: class=0x060400 card=0x21da17aa chip=0x1c168086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 4' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x0(x1) speed 0.0(5.0) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib4@pci0:0:28:4: class=0x060400 card=0x21da17aa chip=0x1c188086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 5' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x1(x1) speed 2.5(5.0) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib5@pci0:0:28:6: class=0x060400 card=0x21da17aa chip=0x1c1c8086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 7' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x1(x1) speed 5.0(5.0) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 ehci1@pci0:0:29:0: class=0x0c0320 card=0x21da17aa chip=0x1c268086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family USB Enhanced Host Controller' class = serial bus subclass = USB cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP isab0@pci0:0:31:0: class=0x060100 card=0x21da17aa chip=0x1c4f8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'QM67 Express Chipset Family LPC Controller' class = bridge subclass = PCI-ISA cap 09[e0] = vendor (length 12) Intel cap 1 version 0 features: AMT, 4 PCI-e x1 slots ahci0@pci0:0:31:2: class=0x010601 card=0x21da17aa chip=0x1c038086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller' class = mass storage subclass = SATA cap 05[80] = MSI supports 1 message enabled with 1 message cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair cap 13[b0] = PCI Advanced Features: FLR TP none1@pci0:0:31:3: class=0x0c0500 card=0x21da17aa chip=0x1c228086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family SMBus Controller' class = serial bus subclass = SMBus iwn0@pci0:3:0:0: class=0x028000 card=0x13118086 chip=0x00858086 rev=0x34 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Advanced-N 6205 [Taylor Peak]' class = network cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(128) FLR link x1(x1) speed 2.5(2.5) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 100ba9ffffa36ef0 sdhci_pci0@pci0:13:0:0: class=0x088001 card=0x21da17aa chip=0xe8231180 rev=0x04 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'PCIe SDXC/MMC Host Controller' class = base peripheral cap 05[50] = MSI supports 1 message, 64 bit cap 01[78] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[80] = PCI-Express 1 endpoint max data 128(128) link x1(x1) speed 2.5(2.5) ecap 0002[100] = VC 1 max VC0 ecap 0001[800] = AER 1 0 fatal 0 non-fatal 4 corrected xhci0@pci0:14:0:0: class=0x0c0330 card=0x21da17aa chip=0x01941033 rev=0x04 hdr=0x00 vendor = 'NEC Corporation' device = 'uPD720200 USB 3.0 Host Controller' class = serial bus subclass = USB cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[70] = MSI supports 8 messages, 64 bit cap 11[90] = MSI-X supports 8 messages in map 0x10 cap 10[a0] = PCI-Express 2 endpoint max data 128(128) link x1(x1) speed 5.0(5.0) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 ffffffffffffffff ecap 0018[150] = LTR 1 From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 05:15:57 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C6D2D3E5; Thu, 28 Feb 2013 05:15:57 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 63DE9ABD; Thu, 28 Feb 2013 05:15:57 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rr4so839152pbb.41 for ; Wed, 27 Feb 2013 21:15:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vcHuXRbQzGqGK8WDMgXub26s45yCbS+b6a1SmNNamD8=; b=XVe1qAQvhuaIfpxcgGymfCZu4oUT9r/cJop6TK3UkpGgyBfHZGEmBSuNQunnt2SLme up52l26YPt53+cDqXTRopEZZXrO5dNvbFh1FKjZI1wBq91PTB/t+7Llrki4oBUVyEIXD zKbgDVn5+8ow8pF8P61ewt+xsx5zq3nLZGRsfqUyzyw4SM1g8lVhTT2Owjc/jhVOhnmJ bGVQTvyiEoOEdRorA5Iv67fQ7hZCawGMRCjdIcXYThbtEtBJiP/qEVm8YhOBKyr9qHCg FXraDhjCd5UkQgnvMvtTmY8osqp494xXSMq1r5GU43+pBktR1wQf0muhBs4P8ZkcVuqY lePg== X-Received: by 10.66.88.164 with SMTP id bh4mr11397218pab.41.1362028551377; Wed, 27 Feb 2013 21:15:51 -0800 (PST) Received: from ghost.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id bi8sm7849292pab.15.2013.02.27.21.15.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 21:15:50 -0800 (PST) Message-ID: <512F5882.7080004@gmail.com> Date: Thu, 28 Feb 2013 05:15:46 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130228 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <201302271200.22976.jhb@freebsd.org> <512E51FF.5010701@gmail.com> <201302271527.37079.jhb@freebsd.org> In-Reply-To: <201302271527.37079.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 05:15:57 -0000 On 02/27/13 12:27, John Baldwin wrote: > On Wednesday, February 27, 2013 1:35:43 pm matt wrote: >> On 02/27/13 09:00, John Baldwin wrote: >>> If that is true, it's because your BIOS is lying. Do you have a URL to >>> your ASL lying around already? >> Too big for pastebin :( +500k >> >> https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing > Here is where I find _DOD and _DOS methods: > > Device (PCI0) > Device (VID) > Name (_ADR, 0x00020000) // _ADR: Address > Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching > Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices > Device (PEG) > Name (_ADR, 0x00010000) // _ADR: Address > Device (VID) > Name (_ADR, 0x00) // _ADR: Address > Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching > Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices > > PCI0.VID is a PCI device at pci0:0:2:0. > PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0. > It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the X220 > have a switchable GPU (e.g. it has built-in Intel graphics, but also has an > Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel graphics > and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to determine > that. If both PCI devices exist you shoudl have both acpi_video0 and acpi_video1. > However, it may be that the acpi_video driver doesn't cope well with having multiple > devices. Only Intel graphics, there is no option for switchable graphics. I initially thought that PEG was for Optimus usage, and left in the bios by accident (i.e. Lenovo using a generic DSDT for many machines) Here is pciconf -lcf, truncated hostb0@pci0:0:0:0: class=0x060000 card=0x21da17aa chip=0x01048086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family DRAM Controller' class = bridge subclass = HOST-PCI cap 09[e0] = vendor (length 12) Intel cap 0 version 1 vgapci0@pci0:0:2:0: class=0x030000 card=0x21da17aa chip=0x01268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA cap 05[90] = MSI supports 1 message enabled with 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP none0@pci0:0:22:0: class=0x078000 card=0x21da17aa chip=0x1c3a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' As you can see there is no device at pci0:0:1:0. So no dev_t with for acpi_video to probe or attach to. Nonetheless, only PEGs ACPI methods work, which is quite broken. This is true for a large number of Lenovo devices, back to x61 (non-attaching AGP adr) and probably including some other x series and t series. Unfortunately the ASL will not compile which makes fixing the DSDT an exercise in fixing broken ACPI. What I find interesting is that as far as I can tell, there's no special case handling for this device in Linux, yet backlight controls work out of the box since about 3.0. Installing Linux as the OSI via loader.conf is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs _BCM... :( Is Linux getting this to work by doing it wrong, essentially? Matt From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 06:04:20 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B049E3F1 for ; Thu, 28 Feb 2013 06:04:20 +0000 (UTC) (envelope-from kron24@gmail.com) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by mx1.freebsd.org (Postfix) with ESMTP id 4E686D42 for ; Thu, 28 Feb 2013 06:04:19 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id e52so1098322eek.6 for ; Wed, 27 Feb 2013 22:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=b/gBk8fIiVgJgt7RhzPuAoCSjJpdkhvIvGT5U5ErvAs=; b=mnRlgkh13bvRuB6aNtNE6YPatNMI2OCcKpy2iMAv8HAlK8IrW/u24LIyPF/MZ8VLpE 4yCfWBi49DX84+yS3Xrx5PJ1RJlNBNwAShTLVXh4ZOBA7OHJkkdX5PZnAHYPnSF0rrHT SDvyDt9OooW4joyQeBK1SpeStJ8zDlF0pGfvayAC5PMgD+4UM8XHKFFnmtf+91S5adkW X+SyUWbGIqwoVGIt0R+6GDvDt5IC9S5VrrACqMmtAp8FX1d4xK/DdJcjlB7BKN9MvhQ/ pzjICG12oFihhwzI/vpntfo+qcZwDp5ibcoZrYwxErNTHacp+by33Ti1B5yiLuRPRO+D lgrw== X-Received: by 10.14.5.6 with SMTP id 6mr13332181eek.42.1362031459074; Wed, 27 Feb 2013 22:04:19 -0800 (PST) Received: from [127.0.0.1] (uidzr185150.sattnet.cz. [212.96.185.150]) by mx.google.com with ESMTPS id 3sm10074434eej.6.2013.02.27.22.04.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 22:04:18 -0800 (PST) Message-ID: <512EF34F.70903@gmail.com> Date: Thu, 28 Feb 2013 07:03:59 +0100 From: kron User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130225 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Subject: Re: panics due to buggy ACPI in Dell Latitude E6530? References: <512E24CD.9090404@gmail.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36F476331@ORSMSX101.amr.corp.intel.com> <512E4D08.50303@gmail.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36F476404@ORSMSX101.amr.corp.intel.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E36F476404@ORSMSX101.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 06:04:20 -0000 On 2013/02/27 19:31, Moore, Robert wrote: > I need the binary tables, or the actual output of acpidump, not the disassembled code. > Thanks, > Bob oh, sorry... now acpidump -t: 1. raw dump http://www.filedropper.com/delllatitudee6530a09acpidump 2. stdout http://www.filedropper.com/delllatitudee6530a09acpidump-t Thanks for your interest Oli From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 15:44:21 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3C39C12A for ; Thu, 28 Feb 2013 15:44:21 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id 42C5FD0E for ; Thu, 28 Feb 2013 15:44:20 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 28 Feb 2013 07:44:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,755,1355126400"; d="scan'208";a="293087077" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga001.fm.intel.com with ESMTP; 28 Feb 2013 07:44:19 -0800 Received: from orsmsx151.amr.corp.intel.com (10.22.226.38) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 28 Feb 2013 07:44:18 -0800 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.110]) by ORSMSX151.amr.corp.intel.com ([169.254.7.6]) with mapi id 14.01.0355.002; Thu, 28 Feb 2013 07:44:18 -0800 From: "Moore, Robert" To: kron , "freebsd-acpi@freebsd.org" Subject: RE: panics due to buggy ACPI in Dell Latitude E6530? Thread-Topic: panics due to buggy ACPI in Dell Latitude E6530? Thread-Index: AQHOFP6EIv1sLdcnwk6Q2HNM5KvUUpiPafmQ Date: Thu, 28 Feb 2013 15:44:17 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E36F4769F4@ORSMSX101.amr.corp.intel.com> References: <512E24CD.9090404@gmail.com> In-Reply-To: <512E24CD.9090404@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 15:44:21 -0000 > ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node > 0xfffffe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113) Sorry, could not reproduce the problem here: - ex _SB_.BAT0._UID Evaluating \_SB_.BAT0._UID Evaluation of \_SB_.BAT0._UID returned object 000342A0, external buffer len= gth 10 [Integer] =3D 0000000000000001 Please send a full list of all such ACPI errors. > -----Original Message----- > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > acpi@freebsd.org] On Behalf Of kron > Sent: Wednesday, February 27, 2013 7:23 AM > To: freebsd-acpi@freebsd.org > Subject: panics due to buggy ACPI in Dell Latitude E6530? >=20 > Hi, >=20 > I have a Dell notebook (Latitude E6530) on which I track 9-STABLE. It > served excellently until mid-Jan when it started to panic a few times a > week or so: >=20 > Fatal trap 12: page fault while in kernel mode cpuid =3D 3; apic id =3D 0= 3 > fault virtual address =3D 0x10116 > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff802bc360 > stack pointer =3D 0x28:0xffffff848f6db390 > frame pointer =3D 0x28:0xffffff848f6db3c0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 2199 (conky) > trap number =3D 12 > panic: page fault > cpuid =3D 3 >=20 > Before the panics kernel used to emit messages like: > ACPI Error: No object attached to node 0xfffffe00094a51c0 > (20110527/exresnte-138) > ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node > 0xfffffe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113) >=20 > I suspected it started with a BIOS update (A07 -> A09). > Following the handbook, I took a look at acpidump. Sad to say, it all was > Greek to me, I could't even compile it back using iasl (35 Errors). > However, while skimming it I noticed names of many versions of Windows an= d > in addition to that, "Linux". > Just to try, I put hw.acpi.osname=3D"Linux" to /boot/loader.conf. > Since that I've never get the panic again (for ~3 weeks). > I hope this is not just a coincidence. >=20 > Maybe this experience can help somebody else. >=20 > If any of ACPI developers wants to play with the problem I can provide > more info (sorry, no crashdump, was not enabled), do tests, etc. >=20 > BR > Oli > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 16:38:17 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A758A446 for ; Thu, 28 Feb 2013 16:38:17 +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 0603361 for ; Thu, 28 Feb 2013 16:38:16 +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 SAA29534; Thu, 28 Feb 2013 18:38:11 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <512F87F2.4000605@FreeBSD.org> Date: Thu, 28 Feb 2013 18:38:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Moore, Robert" Subject: Re: panics due to buggy ACPI in Dell Latitude E6530? References: <512E24CD.9090404@gmail.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36F4769F4@ORSMSX101.amr.corp.intel.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E36F4769F4@ORSMSX101.amr.corp.intel.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , kron X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 16:38:17 -0000 on 28/02/2013 17:44 Moore, Robert said the following: >> ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node >> 0xfffffe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113) > > Sorry, could not reproduce the problem here: > > > - ex _SB_.BAT0._UID > Evaluating \_SB_.BAT0._UID > Evaluation of \_SB_.BAT0._UID returned object 000342A0, external buffer length 10 > [Integer] = 0000000000000001 To me it is semi-obvious that the reported problem is a consequence of the FreeBSD "heisenbug" that I reported before. The one that messes up the internal state of ACPICA and which I previously blamed either on ACPICA object cache or ACPICA reference counting. But now I am inclined to think that it is caused by something in FreeBSD adaptation layer. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 17:09:56 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA1C1C12; Thu, 28 Feb 2013 17:09:56 +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 7EBAA280; Thu, 28 Feb 2013 17:09:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B1B93B94F; Thu, 28 Feb 2013 12:09:55 -0500 (EST) From: John Baldwin To: matt Subject: Re: Fixing X220 Video The Right Way Date: Thu, 28 Feb 2013 12:09:44 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> <201302271527.37079.jhb@freebsd.org> <512F5882.7080004@gmail.com> In-Reply-To: <512F5882.7080004@gmail.com> MIME-Version: 1.0 Message-Id: <201302281209.45170.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 28 Feb 2013 12:09:55 -0500 (EST) Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 17:09:56 -0000 On Thursday, February 28, 2013 8:15:46 am matt wrote: > On 02/27/13 12:27, John Baldwin wrote: > > On Wednesday, February 27, 2013 1:35:43 pm matt wrote: > >> On 02/27/13 09:00, John Baldwin wrote: > >>> If that is true, it's because your BIOS is lying. Do you have a URL to > >>> your ASL lying around already? > >> Too big for pastebin :( +500k > >> > >> https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing > > Here is where I find _DOD and _DOS methods: > > > > Device (PCI0) > > Device (VID) > > Name (_ADR, 0x00020000) // _ADR: Address > > Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching > > Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices > > Device (PEG) > > Name (_ADR, 0x00010000) // _ADR: Address > > Device (VID) > > Name (_ADR, 0x00) // _ADR: Address > > Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching > > Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices > > > > PCI0.VID is a PCI device at pci0:0:2:0. > > PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0. > > It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the X220 > > have a switchable GPU (e.g. it has built-in Intel graphics, but also has an > > Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel graphics > > and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to determine > > that. If both PCI devices exist you shoudl have both acpi_video0 and acpi_video1. > > However, it may be that the acpi_video driver doesn't cope well with having multiple > > devices. > Only Intel graphics, there is no option for switchable graphics. > I initially thought that PEG was for Optimus usage, and left in the bios > by accident (i.e. Lenovo using a generic DSDT for many machines) > > Here is pciconf -lcf, truncated > hostb0@pci0:0:0:0: class=0x060000 card=0x21da17aa chip=0x01048086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '2nd Generation Core Processor Family DRAM Controller' > class = bridge > subclass = HOST-PCI > cap 09[e0] = vendor (length 12) Intel cap 0 version 1 > vgapci0@pci0:0:2:0: class=0x030000 card=0x21da17aa chip=0x01268086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '2nd Generation Core Processor Family Integrated > Graphics Controller' > class = display > subclass = VGA > cap 05[90] = MSI supports 1 message enabled with 1 message > cap 01[d0] = powerspec 2 supports D0 D3 current D0 > cap 13[a4] = PCI Advanced Features: FLR TP > none0@pci0:0:22:0: class=0x078000 card=0x21da17aa chip=0x1c3a8086 > rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > > As you can see there is no device at pci0:0:1:0. So no dev_t with for > acpi_video to probe or attach to. > > Nonetheless, only PEGs ACPI methods work, which is quite broken. This is > true for a large number of Lenovo devices, back to x61 (non-attaching > AGP adr) and probably including some other x series and t series. > > Unfortunately the ASL will not compile which makes fixing the DSDT an > exercise in fixing broken ACPI. > > What I find interesting is that as far as I can tell, there's no special > case handling for this device in Linux, yet backlight controls work out > of the box since about 3.0. Installing Linux as the OSI via loader.conf > is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows > 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs > _BCM... :( > > Is Linux getting this to work by doing it wrong, essentially? Yes. I think the best way to fix this is to add a way to specify a hint to override the ACPI path associated with a PCI device. Something like: hw.pci0.0.2.0.handle="\_SB_.PCI0.PEG.VID" I think this patch should do the trick: Index: sys/dev/acpica/acpi_pci.c =================================================================== --- acpi_pci.c (revision 247320) +++ acpi_pci.c (working copy) @@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le return_ACPI_STATUS (AE_OK); } +static void +acpi_pci_override_handles(device_t dev) +{ + struct acpi_pci_devinfo *dinfo; + device_t *devlist; + int error, i, numdevs; + char tunable_name[64], *path; + ACPI_HANDLE handle; + + error = device_get_children(dev, &devlist, &numdevs); + if (error) + return; + for (i = 0; i < numdevs; i++) { + dinfo = device_get_ivars(devlist[i]); + snprintf(tunable_name, sizeof(tunable_name), + "hw.pci%d.%d.%d.%d.handle", dinfo->ap_dinfo.cfg.domain, + dinfo->ap_dinfo.cfg.bus, dinfo->ap_dinfo.cfg.slot, + dinfo->ap_dinfo.cfg.func); + path = getenv(tunable_name); + if (path == NULL) + continue; + if (ACPI_SUCCESS(AcpiGetHandle(NULL, path, &handle))) { + device_printf(dev, + "Forcing device at %d.%d to use path %s\n", + dinfo->ap_dinfo.cfg.slot, + dinfo->ap_dinfo.cfg.func, path); + dinfo->ap_handle = handle; + acpi_pci_update_device(handle, devlist[i]); + } + freeenv(path); + } + free(devlist, M_TEMP); +} + static int acpi_pci_probe(device_t dev) { @@ -306,5 +340,10 @@ acpi_pci_attach(device_t dev) AcpiWalkNamespace(ACPI_TYPE_DEVICE, acpi_get_handle(dev), 1, acpi_pci_save_handle, NULL, dev, NULL); + /* + * Perform another pass over child devices to allow their + * handles to be overridden via a hint from the user. + */ + acpi_pci_override_handles(dev); return (bus_generic_attach(dev)); } -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 17:38:26 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 632C5EE8 for ; Thu, 28 Feb 2013 17:38:26 +0000 (UTC) (envelope-from kron24@gmail.com) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by mx1.freebsd.org (Postfix) with ESMTP id ED002658 for ; Thu, 28 Feb 2013 17:38:25 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id d41so1690456eek.22 for ; Thu, 28 Feb 2013 09:38:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZvQwAgjxYsJ2lQxcq1a8EW48Kj/nG6a1kGAYjBp9UqE=; b=lkggAHVZzZwBUqlqF5MM/7kES51fbMLhXoq7kKZlhpBiNLTE80fYo2bJLs344GDuKo PcMypYJ4j9ODiztAf/xyKqJvsVWNZHRblowRa/MIJfYyDIxYEHo8TotFWqDHKkxvKbZm 8rod+UVUzoHKvTjbEX3wzzfgclOdL5XFY1NLbN/De4Sy4MdCg90O3PtregMSDrmF2/pU 7R34hB3IC17gIrCJtqgGHf3ZIRSNK5KyVYz4W3LMJdP8LZqLp8GCZa5fyg+YO0JrRY46 ZM9k4cYlMdtINzeExyAWKweX8Bt6PXYut+CVVjnvutNusO7zLB1fdSAkwP1pNUAa7s3h Wmqw== X-Received: by 10.14.207.200 with SMTP id n48mr19078316eeo.4.1362073099135; Thu, 28 Feb 2013 09:38:19 -0800 (PST) Received: from nbvk.local (uidzr185150.sattnet.cz. [212.96.185.150]) by mx.google.com with ESMTPS id q5sm12947703eeo.17.2013.02.28.09.38.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 09:38:18 -0800 (PST) Message-ID: <512F9609.3080005@gmail.com> Date: Thu, 28 Feb 2013 18:38:17 +0100 From: kron User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130225 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Subject: Re: panics due to buggy ACPI in Dell Latitude E6530? References: <512E24CD.9090404@gmail.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36F4769F4@ORSMSX101.amr.corp.intel.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E36F4769F4@ORSMSX101.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 17:38:26 -0000 On 2013/02/28 16:44, Moore, Robert wrote: >> ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node >> 0xfffffe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113) > > Sorry, could not reproduce the problem here: > > > - ex _SB_.BAT0._UID > Evaluating \_SB_.BAT0._UID > Evaluation of \_SB_.BAT0._UID returned object 000342A0, external buffer length 10 > [Integer] = 0000000000000001 > > > > Please send a full list of all such ACPI errors. /var/log/messages of my last crash is at http://www.filedropper.com/messages Picking the best (I hope): Feb 16 11:33:00 dlat kernel: ACPI APIC Table: Feb 16 11:33:00 dlat kernel: ACPI Warning: FADT (revision 5) is longer than ACPI 2.0 version, truncating length 268 to 244 (20110527/tbfadt-317) ... Feb 16 11:33:00 dlat kernel: battery0: on acpi0 Feb 16 11:33:00 dlat kernel: battery1: on acpi0 Feb 16 11:33:00 dlat kernel: battery2: on acpi0 Feb 16 12:36:11 dlat kernel: ACPI Error: No object attached to node 0xfffffe00094a51c0 (20110527/exresnte-138) Feb 16 12:36:11 dlat kernel: ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node 0xfffffe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113) The last two messages repeated with some variations repeated in thousands. Other than that: Feb 16 12:43:41 dlat kernel: ACPI Error: Object not a Integer, type Buffer (20110527/exresnte-209) ... Feb 16 12:47:51 dlat kernel: ACPI Warning: For \_SB_.BAT0._HID: Return type mismatch - found UNDEFINED, expected Integer/String (20110527/nspredef-1116) ... Feb 16 12:47:51 dlat kernel: ACPI Error: Return object type is incorrect [\_SB_.BAT0._HID] (Node 0xfffffe00094a5200), AE_TYPE (20110527/uteval-176) Feb 16 12:47:51 dlat kernel: ACPI Error: Type returned from _HID was incorrect: UNDEFINED, expected Btypes: 0x3 (20110527/uteval-178) ... (in about tens) and the final word was: Feb 16 12:58:15 dlat kernel: ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node 0xfffffe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113) Feb 16 12:58:15 dlat kernel: ACPI Error: No object attached to node 0xfffffe00094a9400 (20110527/exresnte-138) Feb 16 12:58:15 dlat kernel: ACPI Error: Method execution failed [\_SB_.BAT1._UID] (Node 0xfffffe00094a9400), AE_AML_NO_OPERAND (20110527/uteval-113) Feb 16 12:58:15 dlat kernel: ACPI Warning: Large Reference Count (0x94D) in object 0xfffffe00094d2000 (20110527/utdelete-480) Feb 16 12:58:15 dlat kernel: ACPI Error: Return object type is incorrect [\_SB_.BAT0._HID] (Node 0xfffffe00094a5200), AE_TYPE (20110527/uteval-176) Feb 16 12:58:15 dlat kernel: ACPI Error: Type returned from _HID was incorrect: UNDEFINED, expected Btypes: 0x3 (20110527/uteval-178) Feb 16 12:58:15 dlat kernel: ACPI Error: No object attached to node 0xfffffe00094a51c0 (20110527/exresnte-138) Feb 16 12:58:15 dlat kernel: ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node 0xfffffe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113) Feb 16 12:58:15 dlat kernel: Feb 16 12:58:15 dlat kernel: Feb 16 12:58:15 dlat kernel: Fatal trap 12: page fault while in kernel mode Feb 16 12:58:15 dlat kernel: cpuid = 3; apic id = 03 Feb 16 12:58:15 dlat kernel: fault virtual address = 0x10116 Feb 16 12:58:15 dlat kernel: fault code = supervisor read data, page not present Feb 16 12:58:15 dlat kernel: instruction pointer = 0x20:0xffffffff802bc360 Feb 16 12:58:15 dlat kernel: stack pointer = 0x28:0xffffff848f6db390 Feb 16 12:58:15 dlat kernel: frame pointer = 0x28:0xffffff848f6db3c0 Feb 16 12:58:15 dlat kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Feb 16 12:58:15 dlat kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Feb 16 12:58:15 dlat kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Feb 16 12:58:15 dlat kernel: current process = 2199 (conky) Feb 16 12:58:15 dlat kernel: trap number = 12 Feb 16 12:58:15 dlat kernel: panic: page fault Feb 16 12:58:15 dlat kernel: cpuid = 3 Feb 16 12:58:15 dlat kernel: Uptime: 1h21m11s Now I see I overestimated time since the last crash - I'm approaching hardly two weeks. Anyway, no further crash since Feb 16 == the day I'm using hw.acpi.osname="Linux". There may be other factors involved as well: - I update to 9-STABLE 1-2 times a week - I often switch compilers (gcc x clang) to build the system Since the last crash the only "bad" message I get from ACPI is: ACPI Warning: FADT (revision 5) is longer than ACPI 2.0 version, truncating length 268 to 244 (20110527/tbfadt-320) on system startup. BR, Oli From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 17:57:48 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3E3C8963 for ; Thu, 28 Feb 2013 17:57:48 +0000 (UTC) (envelope-from kron24@gmail.com) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by mx1.freebsd.org (Postfix) with ESMTP id D1AD1730 for ; Thu, 28 Feb 2013 17:57:47 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id b15so1614692eek.25 for ; Thu, 28 Feb 2013 09:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Oo3S+1Zpxqt0mNaM1GiZuACAdJsgDk38Kp9wcMf1yMU=; b=Ccyu88/5fFnCqBLQDC5riA/7CyY/l2WaOa7+ZnQ/WkAltgFYLSRHuz1V4g/Fo9kD1i EiUHsLBWVIh060IBM8GgGMWzvMH8A3sT4a9hjLiGzLfhHgVI0k01cT2RWulhX05piQLF wju+Sy/OBm9qC3010t1fgzlp/2+JdQZlEC3JvRcxJZljHx6gRhCHJ1hgQuDQE/Qctat1 aXErvpRiCpKz/1/0wLTlWUVut35ZjKXgw0nDbKcegH8BwI5SzDjPO4aWwMmTD0iiwb6g qBCZ/TzE60C5+EmlUk7Jz3s8NBOxbsEY7EPQyYUCIqzmlYNmo+laAkLoXqMKFsjjq35t HeiA== X-Received: by 10.14.1.130 with SMTP id 2mr18979467eed.15.1362073956118; Thu, 28 Feb 2013 09:52:36 -0800 (PST) Received: from nbvk.local (uidzr185150.sattnet.cz. [212.96.185.150]) by mx.google.com with ESMTPS id f47sm13005964eep.13.2013.02.28.09.52.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 09:52:35 -0800 (PST) Message-ID: <512F9962.4030007@gmail.com> Date: Thu, 28 Feb 2013 18:52:34 +0100 From: kron User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130225 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Subject: Re: panics due to buggy ACPI in Dell Latitude E6530? References: <512E24CD.9090404@gmail.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36F4769F4@ORSMSX101.amr.corp.intel.com> <512F87F2.4000605@FreeBSD.org> In-Reply-To: <512F87F2.4000605@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 17:57:48 -0000 On 2013/02/28 17:38, Andriy Gapon wrote: > on 28/02/2013 17:44 Moore, Robert said the following: >>> ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node >>> 0xfffffe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113) >> >> Sorry, could not reproduce the problem here: >> >> >> - ex _SB_.BAT0._UID >> Evaluating \_SB_.BAT0._UID >> Evaluation of \_SB_.BAT0._UID returned object 000342A0, external buffer length 10 >> [Integer] = 0000000000000001 > > To me it is semi-obvious that the reported problem is a consequence of the FreeBSD > "heisenbug" that I reported before. The one that messes up the internal state of > ACPICA and which I previously blamed either on ACPICA object cache or ACPICA > reference counting. But now I am inclined to think that it is caused by something > in FreeBSD adaptation layer. > Yes, I looked at David Demelier's report - the ACPI errors are nearly identical. I'll enable crash dumps, just in case... BR Oli From owner-freebsd-acpi@FreeBSD.ORG Fri Mar 1 07:51:08 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0F5C32B5; Fri, 1 Mar 2013 07:51:08 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 9B19EE03; Fri, 1 Mar 2013 07:51:07 +0000 (UTC) Received: from mail.bitfrost.no (mail.bitfrost.no [46.29.221.36]) by mta.bitpro.no (Postfix) with ESMTP id 7A2087A075; Fri, 1 Mar 2013 08:51:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bitfrost.no Received: from smtp.bitfrost.no (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hanspetter) by mail.bitfrost.no (Postfix) with ESMTPSA id 65EF21FF46; Fri, 1 Mar 2013 08:51:03 +0100 (CET) From: Hans Petter Selasky To: Jung-uk Kim Subject: Re: ACPI locking bugs? Date: Fri, 01 Mar 2013 08:52:12 +0100 Message-ID: <6951816.YIytQN410a@laptop015.hselasky.homeunix.org> Organization: Bitfrost A/S X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, References: <201302271453.43985.hps@bitfrost.no> <512E5E4C.807@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 07:51:08 -0000 On Wednesday 27 February 2013 14:28:12 Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2013-02-27 08:53:43 -0500, Hans Petter Selasky wrote: > > Hi, > > > > What is the reason for using cv_wait_sig() and cv_timedwait_sig() > > instead of cv_wait() and cv_timedwait() inside of > > AcpiOsWaitSemaphore(). What signals are supposed to be catched > > here? > > > > switch (Timeout) { case ACPI_DO_NOT_WAIT: if (!ACPISEM_AVAIL(as, > > Units)) status = AE_TIME; break; case ACPI_WAIT_FOREVER: while > > (!ACPISEM_AVAIL(as, Units)) { as->as_waiters++; error = > > cv_wait_sig(&as->as_cv, &as->as_lock); as->as_waiters--; if (error > > == EINTR || as->as_reset) { status = AE_ERROR; break; } } break; > > default: tmo = timeout2hz(Timeout); while (!ACPISEM_AVAIL(as, > > Units)) { prevtick = ticks; as->as_waiters++; error = > > cv_timedwait_sig(&as->as_cv, &as->as_lock, tmo); as->as_waiters--; > > if (error == EINTR || as->as_reset) { status = AE_ERROR; break; } > > if (ACPISEM_AVAIL(as, Units)) break; slptick = ticks - prevtick; if > > (slptick >= tmo || slptick < 0) { status = AE_TIME; break; } tmo -= > > slptick; } } > > > > I've observed an issue twice on my MacBookPro that some ACPI > > locking fails during shutdown on 9-stable and then the power-off > > won't complete. I've been unable to capture the full dmesg, because > > syslogd is killed at the moment this happens. There are two ACPI > > error printouts about failed locking. > > > > I see that in the case of ACPI_WAIT_FOREVER, it appears to be > > incorrect to catch signals, because sometimes the return argument > > is not checked for lock operations: > > > > ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex > > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); > > ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex > > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); > > ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex > > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); > > > > Any comments? > > > > Reference: sys/dev/acpica/Osd/OsdSynch.c:AcpiOsWaitSemaphore > > I don't exactly remember why it was written like that, sorry. > Probably it was to work around broken mutex uses in ACPICA at the time. > > FYI, many ACPICA patches are contributed by Linux developers. > Unfortunately, the Linux OS-dependent code does not implement the > ACPICA OSL API fully and omits some corner cases. [1] > > For example, ACPICA mutex is implemented via semaphore: > > http://lxr.linux.no/#linux+v3.8/include/acpi/platform/aclinux.h#L51 > http://lxr.linux.no/#linux+v3.8/include/acpi/actypes.h#L239 > > And the semaphore does not support unit > 1 and ACPI_WAIT_FOREVER: > > http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1227 > > So, a lot of locking related ACPICA patches ignored these corner > cases. Another problem is that we are very serious about locking > orders but ACPICA doesn't really care much because Linux and others > don't care, really. > > Another example is the ACPICA "cache" allocator. It is actually > modeled after Linux's slab allocator, i.e., kmem_cache_*(): Hi, The problem is not locking or locking order, but that the locking wait for signals. You know when you have a thread, you kan kill it using a signal. I think at shutdown all threads and processes gets a KILL signal, and that confuses ACPICA if it is about to grab a mutex. > http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1636 > > Unfortunately, it doesn't really fit into our closest KPI, i.e., > zone(9). [2] > > We always tried our best to *fully* implement OSL but it is not an > easy task. :-( > > Jung-uk Kim > > 1. For the official ACPICA OS-dependent API, please see "ACPI > Component Architecture User Guide and Programmer Reference". You can > get it from here: > > https://www.acpica.org/documentation/ > > 2. There were some patches but I am not really comfortable with any > of these patches yet. --HPS From owner-freebsd-acpi@FreeBSD.ORG Fri Mar 1 21:01:15 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B98085B4; Fri, 1 Mar 2013 21:01:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4617717C3; Fri, 1 Mar 2013 21:01:15 +0000 (UTC) Message-ID: <513116A1.4070406@FreeBSD.org> Date: Fri, 01 Mar 2013 15:59:13 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: ACPI locking bugs? References: <201302271453.43985.hps@bitfrost.no> <512E1E3D.7090501@FreeBSD.org> In-Reply-To: <512E1E3D.7090501@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/mixed; boundary="------------010703080808040408030302" Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 21:01:15 -0000 This is a multi-part message in MIME format. --------------010703080808040408030302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-02-27 09:54:53 -0500, Andriy Gapon wrote: > on 27/02/2013 15:53 Hans Petter Selasky said the following: >> Hi, >> >> What is the reason for using cv_wait_sig() and cv_timedwait_sig() >> instead of cv_wait() and cv_timedwait() inside of >> AcpiOsWaitSemaphore(). What signals are supposed to be catched >> here? >> >> switch (Timeout) { case ACPI_DO_NOT_WAIT: if (!ACPISEM_AVAIL(as, >> Units)) status = AE_TIME; break; case ACPI_WAIT_FOREVER: while >> (!ACPISEM_AVAIL(as, Units)) { as->as_waiters++; error = >> cv_wait_sig(&as->as_cv, &as->as_lock); as->as_waiters--; if >> (error == EINTR || as->as_reset) { status = AE_ERROR; break; } } >> break; default: tmo = timeout2hz(Timeout); while >> (!ACPISEM_AVAIL(as, Units)) { prevtick = ticks; >> as->as_waiters++; error = cv_timedwait_sig(&as->as_cv, >> &as->as_lock, tmo); as->as_waiters--; if (error == EINTR || >> as->as_reset) { status = AE_ERROR; break; } if (ACPISEM_AVAIL(as, >> Units)) break; slptick = ticks - prevtick; if (slptick >= tmo || >> slptick < 0) { status = AE_TIME; break; } tmo -= slptick; } } When something is miserably waiting forever to grab a mutex/semaphore, I wanted to be able to kill the misbehaving application, e.g., 'sysctl - -a' from /etc/rc.d/initrandom. Often times, it is caused by buggy DSDTs. >> I've observed an issue twice on my MacBookPro that some ACPI >> locking fails during shutdown on 9-stable and then the power-off >> won't complete. I've been unable to capture the full dmesg, >> because syslogd is killed at the moment this happens. There are >> two ACPI error printouts about failed locking. I suspect there's a bug in DSDT. >> I see that in the case of ACPI_WAIT_FOREVER, it appears to be >> incorrect to catch signals, because sometimes the return argument >> is not checked for lock operations: >> >> ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex >> (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); >> ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex >> (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); >> ./components/utilities/utosi.c: (void) AcpiOsAcquireMutex >> (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER); It should be fixed in ACPICA. FYI, here is a patch to address the problem: https://github.com/otcshare/acpica/pull/5 IMHO, using ACPI_WAIT_FOREVER is really foot-shooting. In fact, I believe it should be removed from ACPI specification altogether. >> Any comments? > > kib drew my attention to this issue some time ago and I also pinged > jkim about it. I completely agree with you that the signal handling > should be removed. Are you willing to make the change or would you > prefer me doing it? Although I don't 100% agree with you, I decided to be more practical. Please try the attached patch. It is also available from here: http://people.freebsd.org/~jkim/OsdSynch.diff I don't think it will fix anything, though. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRMRagAAoJECXpabHZMqHO+S8H/RnYNxLlLKM2u3s/VdRKXL1I +WLgfdUpQoWU8RZvb9Kf7QzpiOsmEkEnUIiwYRkEos7YNUSObt8ivWsuxQx/Sxat nzRl160HOHf9azgz9hlOfmWl1PLK12gMh/wX6E4WvYJLNQed5OXXlkqq9X4DSJ/Q CVzxcLcKZYkoMFg1wvQcB1nSP4uGHkdtGQc0qB9WWNt4Gmb5T3wfLiy6T3j2YN3x gchMhvJVTbbGTb5K1eZyahdacXpW3Ost2z/q/mB1eAjUwnsjF0Q95MzGInvIq3n6 wHizY8RHNDWfAyQMPAyqYFIPdbFjDHX6NFHQIIQw3ewn8fKylMi2npls7a9y51k= =y21z -----END PGP SIGNATURE----- --------------010703080808040408030302 Content-Type: text/x-patch; name="OsdSynch.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="OsdSynch.diff" Index: sys/dev/acpica/Osd/OsdSynch.c =================================================================== --- sys/dev/acpica/Osd/OsdSynch.c (revision 247571) +++ sys/dev/acpica/Osd/OsdSynch.c (working copy) @@ -1,7 +1,7 @@ /*- * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi - * Copyright (c) 2007-2009 Jung-uk Kim + * Copyright (c) 2007-2013 Jung-uk Kim * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -45,6 +45,19 @@ __FBSDID("$FreeBSD$"); #define _COMPONENT ACPI_OS_SERVICES ACPI_MODULE_NAME("SYNCH") +/* + * Allow the user to tune the maximum seconds to destroy mutex and semaphore. + */ +static int acpi_wait_destroy = 10; +TUNABLE_INT("debug.acpi.sync_wait_destroy", &acpi_wait_destroy); + +/* + * Allow the user to tune the maximum seconds for ACPI_WAIT_FOREVER. + * Note it must be larger than 65 seconds. + */ +static int acpi_wait_forever = 120; +TUNABLE_INT("debug.acpi.sync_wait_forever", &acpi_wait_forever); + static MALLOC_DEFINE(M_ACPISEM, "acpisem", "ACPI semaphore"); /* @@ -54,7 +67,15 @@ static int timeout2hz(UINT16 Timeout) { struct timeval tv; + int tmo; + if (Timeout == ACPI_WAIT_FOREVER) { + tmo = acpi_wait_forever * hz; + KASSERT(tmo > 0 && acpi_wait_forever > UINT16_MAX / 1000, + ("invalid timeout %d", tmo)); + return (tmo); + } + tv.tv_sec = (time_t)(Timeout / 1000); tv.tv_usec = (suseconds_t)(Timeout % 1000) * 1000; @@ -106,6 +127,7 @@ ACPI_STATUS AcpiOsDeleteSemaphore(ACPI_SEMAPHORE Handle) { struct acpi_sema *as = (struct acpi_sema *)Handle; + int retry; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -122,20 +144,23 @@ AcpiOsDeleteSemaphore(ACPI_SEMAPHORE Handle) as->as_name, as->as_units, as->as_waiters)); as->as_reset = 1; cv_broadcast(&as->as_cv); - while (as->as_waiters > 0) { - if (mtx_sleep(&as->as_reset, &as->as_lock, - PCATCH, "acsrst", hz) == EINTR) { - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "failed to reset %s, waiters %d\n", - as->as_name, as->as_waiters)); - mtx_unlock(&as->as_lock); - return_ACPI_STATUS (AE_ERROR); - } + retry = acpi_wait_destroy; + while (as->as_waiters > 0 && retry > 0) { + mtx_sleep(&as->as_reset, &as->as_lock, PWAIT, + "acsrst", hz); ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "wait %s, units %u, waiters %d\n", as->as_name, as->as_units, as->as_waiters)); + retry--; } } + if (as->as_waiters > 0) { + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "failed to reset %s, waiters %d\n", + as->as_name, as->as_waiters)); + mtx_unlock(&as->as_lock); + return_ACPI_STATUS (AE_ERROR); + } mtx_unlock(&as->as_lock); @@ -152,7 +177,7 @@ ACPI_STATUS AcpiOsWaitSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units, UINT16 Timeout) { struct acpi_sema *as = (struct acpi_sema *)Handle; - int error, prevtick, slptick, tmo; + int error, prev, tmo; ACPI_STATUS status = AE_OK; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -167,50 +192,38 @@ AcpiOsWaitSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units, as->as_name, as->as_units, as->as_waiters, Timeout)); if (as->as_maxunits != ACPI_NO_UNIT_LIMIT && as->as_maxunits < Units) { - mtx_unlock(&as->as_lock); - return_ACPI_STATUS (AE_LIMIT); + status = AE_LIMIT; + goto out; } - - switch (Timeout) { - case ACPI_DO_NOT_WAIT: - if (!ACPISEM_AVAIL(as, Units)) + if (ACPISEM_AVAIL(as, Units)) { + as->as_units -= Units; + goto out; + } + if (Timeout == ACPI_DO_NOT_WAIT) { + status = AE_TIME; + goto out; + } + tmo = timeout2hz(Timeout); + for (;;) { + prev = ticks; + as->as_waiters++; + error = cv_timedwait(&as->as_cv, &as->as_lock, tmo); + as->as_waiters--; + if (ACPISEM_AVAIL(as, Units)) { + as->as_units -= Units; + break; + } + if (as->as_reset || error == EWOULDBLOCK) { status = AE_TIME; - break; - case ACPI_WAIT_FOREVER: - while (!ACPISEM_AVAIL(as, Units)) { - as->as_waiters++; - error = cv_wait_sig(&as->as_cv, &as->as_lock); - as->as_waiters--; - if (error == EINTR || as->as_reset) { - status = AE_ERROR; - break; - } + break; } - break; - default: - tmo = timeout2hz(Timeout); - while (!ACPISEM_AVAIL(as, Units)) { - prevtick = ticks; - as->as_waiters++; - error = cv_timedwait_sig(&as->as_cv, &as->as_lock, tmo); - as->as_waiters--; - if (error == EINTR || as->as_reset) { - status = AE_ERROR; - break; - } - if (ACPISEM_AVAIL(as, Units)) - break; - slptick = ticks - prevtick; - if (slptick >= tmo || slptick < 0) { - status = AE_TIME; - break; - } - tmo -= slptick; + tmo -= ticks - prev; + if (tmo <= 0) { + status = AE_TIME; + break; } } - if (ACPI_SUCCESS(status)) - as->as_units -= Units; - +out: mtx_unlock(&as->as_lock); return_ACPI_STATUS (status); @@ -296,6 +309,7 @@ void AcpiOsDeleteMutex(ACPI_MUTEX Handle) { struct acpi_mutex *am = (struct acpi_mutex *)Handle; + int retry; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -313,15 +327,10 @@ AcpiOsDeleteMutex(ACPI_MUTEX Handle) "reset %s, owner %p\n", am->am_name, am->am_owner)); am->am_reset = 1; wakeup(am); - while (am->am_waiters > 0) { - if (mtx_sleep(&am->am_reset, &am->am_lock, - PCATCH, "acmrst", hz) == EINTR) { - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "failed to reset %s, waiters %d\n", - am->am_name, am->am_waiters)); - mtx_unlock(&am->am_lock); - return_VOID; - } + retry = acpi_wait_destroy; + while (am->am_waiters > 0 && retry > 0) { + mtx_sleep(&am->am_reset, &am->am_lock, PWAIT, + "acmrst", hz); if (ACPIMTX_AVAIL(am)) ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "wait %s, waiters %d\n", @@ -330,8 +339,16 @@ AcpiOsDeleteMutex(ACPI_MUTEX Handle) ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "wait %s, owner %p, waiters %d\n", am->am_name, am->am_owner, am->am_waiters)); + retry--; } } + if (am->am_waiters > 0) { + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "failed to reset %s, waiters %d\n", + am->am_name, am->am_waiters)); + mtx_unlock(&am->am_lock); + return_VOID; + } mtx_unlock(&am->am_lock); @@ -343,7 +360,7 @@ ACPI_STATUS AcpiOsAcquireMutex(ACPI_MUTEX Handle, UINT16 Timeout) { struct acpi_mutex *am = (struct acpi_mutex *)Handle; - int error, prevtick, slptick, tmo; + int error, prev, tmo; ACPI_STATUS status = AE_OK; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -360,51 +377,37 @@ AcpiOsAcquireMutex(ACPI_MUTEX Handle, UINT16 Timeo ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "acquire nested %s, depth %d\n", am->am_name, am->am_nested)); - mtx_unlock(&am->am_lock); - return_ACPI_STATUS (AE_OK); + goto out; } - - switch (Timeout) { - case ACPI_DO_NOT_WAIT: - if (!ACPIMTX_AVAIL(am)) + if (ACPIMTX_AVAIL(am)) { + am->am_owner = curthread; + goto out; + } + if (Timeout == ACPI_DO_NOT_WAIT) { + status = AE_TIME; + goto out; + } + tmo = timeout2hz(Timeout); + for (;;) { + prev = ticks; + am->am_waiters++; + error = mtx_sleep(am, &am->am_lock, 0, "acmtx", tmo); + am->am_waiters--; + if (ACPIMTX_AVAIL(am)) { + am->am_owner = curthread; + break; + } + if (am->am_reset || error == EWOULDBLOCK) { status = AE_TIME; - break; - case ACPI_WAIT_FOREVER: - while (!ACPIMTX_AVAIL(am)) { - am->am_waiters++; - error = mtx_sleep(am, &am->am_lock, PCATCH, "acmtx", 0); - am->am_waiters--; - if (error == EINTR || am->am_reset) { - status = AE_ERROR; - break; - } + break; } - break; - default: - tmo = timeout2hz(Timeout); - while (!ACPIMTX_AVAIL(am)) { - prevtick = ticks; - am->am_waiters++; - error = mtx_sleep(am, &am->am_lock, PCATCH, - "acmtx", tmo); - am->am_waiters--; - if (error == EINTR || am->am_reset) { - status = AE_ERROR; - break; - } - if (ACPIMTX_AVAIL(am)) - break; - slptick = ticks - prevtick; - if (slptick >= tmo || slptick < 0) { - status = AE_TIME; - break; - } - tmo -= slptick; + tmo -= ticks - prev; + if (tmo <= 0) { + status = AE_TIME; + break; } } - if (ACPI_SUCCESS(status)) - am->am_owner = curthread; - +out: mtx_unlock(&am->am_lock); return_ACPI_STATUS (status); --------------010703080808040408030302-- From owner-freebsd-acpi@FreeBSD.ORG Fri Mar 1 21:24:03 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 90FBBD47 for ; Fri, 1 Mar 2013 21:24:03 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3A7971875; Fri, 1 Mar 2013 21:24:03 +0000 (UTC) Message-ID: <51311BF8.8060602@FreeBSD.org> Date: Fri, 01 Mar 2013 16:22:00 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ACPI locking bugs? References: <201302271453.43985.hps@bitfrost.no> <512E5E4C.807@FreeBSD.org> <6951816.YIytQN410a@laptop015.hselasky.homeunix.org> In-Reply-To: <6951816.YIytQN410a@laptop015.hselasky.homeunix.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 21:24:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-03-01 02:52:12 -0500, Hans Petter Selasky wrote: > The problem is not locking or locking order, but that the locking > wait for signals. You know when you have a thread, you kan kill it > using a signal. I think at shutdown all threads and processes gets > a KILL signal, and that confuses ACPICA if it is about to grab a > mutex. Hmm... That's an interesting thought. It can happen if a thread gets killed while holding a ACPI mutex/semaphore. However, I am not sure how to fix that situation. With or without PCATCH, it can happen anyway. :-( Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRMRv4AAoJECXpabHZMqHOG/EH/3JBUZrkTpybpD6IfdtK5zHP qsTz4YQ0tX5JQUs2mWVdg24fINJ8pRMTKll5WpwHA6qB9lgzVyMFWTNZKwJ/dbLs HY9O1qkYem5a9H7rqU5E8Z1tKUeVlzyQFt7aTuIRbeHAYNseDi1qWZfesNHXk8yD zqSqnMNv0+9a39ct8BLoRBTNa3jaRMrlqf7Ks1skph4e6kQExtoEG5e+rjq39Oiv HZiJbMqcVos+xhDc921NOGgQtHH++aLkhMvimrOhPAnTD/7iNU4uFuSQ5nxeQoDS G6vwJJqMDeHdBdZzW398RIUbJNHQcUJTiLT1U7VQx2QIXhUKNMuKIREQJQwI8rY= =4qjW -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Sat Mar 2 01:36:53 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63ACE48B; Sat, 2 Mar 2013 01:36:53 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by mx1.freebsd.org (Postfix) with ESMTP id E51A8167; Sat, 2 Mar 2013 01:36:52 +0000 (UTC) Received: by mail-da0-f46.google.com with SMTP id z8so1664781dad.19 for ; Fri, 01 Mar 2013 17:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WINdfxl1BDHFpdoQjwESYbHPe/rOzpSWMepdfeFmUfU=; b=t6IkzkKZonWPFi0dbh36Z0gShCMT+zNh8cepZ70Bd7ny8UPSZgWw0R1WWhPRzxAUvw bQg11znj9C/mlV2KChGjhULdi3pdSyewy6cVyReNs03k7VT45cMw5StnxtvrUvhxQz2c QZEQ6I/1JGuAZFPBytRxU0bAhiXExOE11uOlUd8XrSwDdbLoTDtwtq6RptuvA08kmuZ4 iR7fBNuzy0BEq0TaL2iBVFIEp/F5MRsHHwj/AfEwOTWoIdN3RzNEO5Zs+DQUDHD2ptN6 t2GEkHrBSLw8X8txrHqwbsHQwG89jbeB2oL9YSTYMVC+LNlIwJ0LHpOKYe+bHLD5/mvM SKnQ== X-Received: by 10.66.151.226 with SMTP id ut2mr21489306pab.53.1362188206527; Fri, 01 Mar 2013 17:36:46 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id hs8sm13757378pbc.27.2013.03.01.17.36.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 17:36:45 -0800 (PST) Message-ID: <5131576E.2080403@gmail.com> Date: Fri, 01 Mar 2013 17:35:42 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <201302271527.37079.jhb@freebsd.org> <512F5882.7080004@gmail.com> <201302281209.45170.jhb@freebsd.org> In-Reply-To: <201302281209.45170.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 01:36:53 -0000 On 02/28/13 09:09, John Baldwin wrote: > On Thursday, February 28, 2013 8:15:46 am matt wrote: >> On 02/27/13 12:27, John Baldwin wrote: >>> On Wednesday, February 27, 2013 1:35:43 pm matt wrote: >>>> On 02/27/13 09:00, John Baldwin wrote: >>>>> If that is true, it's because your BIOS is lying. Do you have a URL to >>>>> your ASL lying around already? >>>> Too big for pastebin :( +500k >>>> >>>> https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing >>> Here is where I find _DOD and _DOS methods: >>> >>> Device (PCI0) >>> Device (VID) >>> Name (_ADR, 0x00020000) // _ADR: Address >>> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching >>> Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices >>> Device (PEG) >>> Name (_ADR, 0x00010000) // _ADR: Address >>> Device (VID) >>> Name (_ADR, 0x00) // _ADR: Address >>> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching >>> Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices >>> >>> PCI0.VID is a PCI device at pci0:0:2:0. >>> PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0. >>> It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the X220 >>> have a switchable GPU (e.g. it has built-in Intel graphics, but also has an >>> Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel graphics >>> and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to determine >>> that. If both PCI devices exist you shoudl have both acpi_video0 and acpi_video1. >>> However, it may be that the acpi_video driver doesn't cope well with having multiple >>> devices. >> Only Intel graphics, there is no option for switchable graphics. >> I initially thought that PEG was for Optimus usage, and left in the bios >> by accident (i.e. Lenovo using a generic DSDT for many machines) >> >> Here is pciconf -lcf, truncated >> hostb0@pci0:0:0:0: class=0x060000 card=0x21da17aa chip=0x01048086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '2nd Generation Core Processor Family DRAM Controller' >> class = bridge >> subclass = HOST-PCI >> cap 09[e0] = vendor (length 12) Intel cap 0 version 1 >> vgapci0@pci0:0:2:0: class=0x030000 card=0x21da17aa chip=0x01268086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '2nd Generation Core Processor Family Integrated >> Graphics Controller' >> class = display >> subclass = VGA >> cap 05[90] = MSI supports 1 message enabled with 1 message >> cap 01[d0] = powerspec 2 supports D0 D3 current D0 >> cap 13[a4] = PCI Advanced Features: FLR TP >> none0@pci0:0:22:0: class=0x078000 card=0x21da17aa chip=0x1c3a8086 >> rev=0x04 hdr=0x00 >> vendor = 'Intel Corporation' >> >> As you can see there is no device at pci0:0:1:0. So no dev_t with for >> acpi_video to probe or attach to. >> >> Nonetheless, only PEGs ACPI methods work, which is quite broken. This is >> true for a large number of Lenovo devices, back to x61 (non-attaching >> AGP adr) and probably including some other x series and t series. >> >> Unfortunately the ASL will not compile which makes fixing the DSDT an >> exercise in fixing broken ACPI. >> >> What I find interesting is that as far as I can tell, there's no special >> case handling for this device in Linux, yet backlight controls work out >> of the box since about 3.0. Installing Linux as the OSI via loader.conf >> is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows >> 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs >> _BCM... :( >> >> Is Linux getting this to work by doing it wrong, essentially? > Yes. I think the best way to fix this is to add a way to specify a > hint to override the ACPI path associated with a PCI device. Something > like: > > hw.pci0.0.2.0.handle="\_SB_.PCI0.PEG.VID" > > I think this patch should do the trick: > > Index: sys/dev/acpica/acpi_pci.c > =================================================================== > --- acpi_pci.c (revision 247320) > +++ acpi_pci.c (working copy) > @@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le > return_ACPI_STATUS (AE_OK); > } > > +static void > +acpi_pci_override_handles(device_t dev) > +{ > + struct acpi_pci_devinfo *dinfo; > + device_t *devlist; > + int error, i, numdevs; > + char tunable_name[64], *path; > + ACPI_HANDLE handle; > + > + error = device_get_children(dev, &devlist, &numdevs); > + if (error) > + return; > + for (i = 0; i < numdevs; i++) { > + dinfo = device_get_ivars(devlist[i]); > + snprintf(tunable_name, sizeof(tunable_name), > + "hw.pci%d.%d.%d.%d.handle", dinfo->ap_dinfo.cfg.domain, > + dinfo->ap_dinfo.cfg.bus, dinfo->ap_dinfo.cfg.slot, > + dinfo->ap_dinfo.cfg.func); > + path = getenv(tunable_name); > + if (path == NULL) > + continue; > + if (ACPI_SUCCESS(AcpiGetHandle(NULL, path, &handle))) { > + device_printf(dev, > + "Forcing device at %d.%d to use path %s\n", > + dinfo->ap_dinfo.cfg.slot, > + dinfo->ap_dinfo.cfg.func, path); > + dinfo->ap_handle = handle; > + acpi_pci_update_device(handle, devlist[i]); > + } > + freeenv(path); > + } > + free(devlist, M_TEMP); > +} > + > static int > acpi_pci_probe(device_t dev) > { > @@ -306,5 +340,10 @@ acpi_pci_attach(device_t dev) > AcpiWalkNamespace(ACPI_TYPE_DEVICE, acpi_get_handle(dev), 1, > acpi_pci_save_handle, NULL, dev, NULL); > > + /* > + * Perform another pass over child devices to allow their > + * handles to be overridden via a hint from the user. > + */ > + acpi_pci_override_handles(dev); > return (bus_generic_attach(dev)); > } > > Initial attempt with this patch failed to change the result in devinfo -rv...I will hopefully have more info tonight. Thanks, Matt