From owner-freebsd-acpi@FreeBSD.ORG Sun Jan 26 21:18:04 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64B2B4B5 for ; Sun, 26 Jan 2014 21:18:04 +0000 (UTC) Received: from kazi.fit.vutbr.cz (kazi6.fit.vutbr.cz [IPv6:2001:67c:1220:808::93e5:80c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F0CBD1B0F for ; Sun, 26 Jan 2014 21:18:03 +0000 (UTC) Received: from kazi.fit.vutbr.cz (localhost [127.0.0.1]) by kazi.fit.vutbr.cz (8.14.7/8.14.6) with ESMTP id s0QLI0Zw087160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Jan 2014 22:18:01 +0100 (CET) Received: (from cejkar@localhost) by kazi.fit.vutbr.cz (8.14.7/8.14.5/Submit) id s0QLI0kv087159 for freebsd-acpi@freebsd.org; Sun, 26 Jan 2014 22:18:00 +0100 (CET) (envelope-from cejkar@fit.vutbr.cz) X-Authentication-Warning: kazi.fit.vutbr.cz: cejkar set sender to cejkar@fit.vutbr.cz using -f Date: Sun, 26 Jan 2014 22:18:00 +0100 From: Cejka Rudolf To: freebsd-acpi@freebsd.org Subject: PS/2 Keyboard disappeared after upgrade from 8.2 to 9.2 Message-ID: <20140126211800.GA84919@fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-Scanned-By: MIMEDefang 2.74 on 147.229.8.12 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 21:18:04 -0000 Hello, maybe it will be interesting for you. I had a problem with disappeared PS/2 keyboard after upgrade from 8.2 to 9.2. It is on old Intel ECG3510M motherboard, but it is possible that the same ACPI bug could be on some other motherboards and maybe there would be beneficial to implement a workaround, atleast because 8.2 had no problem with this DSDT. Full DSDT dump is downloadable from ftp://ftp.FreeBSD.cz/pub/FreeBSD-local/acpi-ecg3510m/acpi-ecg3510m.asl If you look inside, there is PS2M before PS2K, and PS2M unconditionally allocates ports 0x60-0x64 and stoles them from subsequent PS2K, even if PS2K is enabled, so PS2K fails to detect/activate. Result on 8.2, which is resistant to this DSDT bug (is it really bug?): psmcpnp0 pnpinfo _HID=PNP0F03 _UID=0 at handle=\_SB_.PCI0.LPC_.PS2M Interrupt request lines: 12 atkbdc0 pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.LPC_.PS2K I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 1 psm0 Interrupt request lines: 12 Result on 9.2: psmcpnp0 pnpinfo _HID=PNP0F03 _UID=0 at handle=\_SB_.PCI0.LPC_.PS2M I/O ports: 0x60 0x64 unknown pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.LPC_.PS2K I tried to swap the PS2M and PS2K definitions, so that PS2K is before PS2M, and it solves the problem under 9.2 and it detects PS/2 Keyboard again. Best regards. -- Rudolf Cejka http://www.fit.vutbr.cz/~cejkar Brno University of Technology, Faculty of Information Technology Bozetechova 2, 612 66 Brno, Czech Republic From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 27 11:06:42 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEFA3C2D for ; Mon, 27 Jan 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B4861A78 for ; Mon, 27 Jan 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0RB6gi4012913 for ; Mon, 27 Jan 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0RB6gIb012911 for freebsd-acpi@FreeBSD.org; Mon, 27 Jan 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Jan 2014 11:06:42 GMT Message-Id: <201401271106.s0RB6gIb012911@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.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 11:06:42 -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/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/165381 acpi [cpufreq] powerd(8) eats CPUs for breakfast o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v 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/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 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 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/73823 acpi [request] acpi / power-on by timer support 28 problems total. From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 28 17:35:14 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9214713 for ; Tue, 28 Jan 2014 17:35:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A1DEB14F2 for ; Tue, 28 Jan 2014 17:35:14 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2FD46B94F; Tue, 28 Jan 2014 12:35:13 -0500 (EST) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: ACPI issues with PC engines APU beta board Date: Tue, 28 Jan 2014 10:53:08 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140122163215.GA46029@gta.com> In-Reply-To: <20140122163215.GA46029@gta.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201401281053.08242.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Jan 2014 12:35:13 -0500 (EST) Cc: Larry Baird X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 17:35:14 -0000 On Wednesday, January 22, 2014 11:32:15 am Larry Baird wrote: > I have a protoype board from PC Engines for their upcoming APU board. > The board runs fine under FreeBSD 8.4 release but fails to boot using either > FreeBSD 9.2 release or FreeBSD 10.0 release. Verbose boot seems to indicate > issue is with ACPI. I am working with PC Engines to get FreeBSD up and > running on their board. Hopefully attached information is enough to > determine issue with BIOS. I'll then feed this information back to PC > Engines so they can provide the information to their BIOS provider. > > Attached is a verbose dmesg from 9.2. In case it gets stripped you > can also find dmesg at: ftp://ftp.gta.com/pub/apu/FreeBSD9.2/bootVerbose.txt > > Dmesg from booting 8.4 is at: ftp://ftp.gta.com/pub/apu/FreeBSD8.4/dmesg.boot > > Dump of sysctl.hw.acpi from FreeBSD 8.4 is: > > hw.acpi.supported_sleep_state: S1 S2 S3 S4 S5 > hw.acpi.power_button_state: S5 > hw.acpi.sleep_button_state: S1 > hw.acpi.lid_switch_state: NONE > hw.acpi.standby_state: S1 > hw.acpi.suspend_state: S3 > hw.acpi.sleep_delay: 1 > hw.acpi.s4bios: 0 > hw.acpi.verbose: 0 > hw.acpi.disable_on_reboot: 0 > hw.acpi.handle_reboot: 1 > hw.acpi.reset_video: 0 > hw.acpi.cpu.cx_lowest: C1 > > acpidump -dt from from FreeBSD 8.4 is at: > ftp://ftp.gta.com/pub/apu/FreeBSD8.4/lab-pcengines-apu1b.asl The BIOS is busted. The resource ranges that the Host-PCI bridge decodes are marked as regular resources when they should be ResourceProducer ranges instead. They have this correct for I/O port resources, but not memory. You can try this workaround: Index: sys/dev/acpica/acpi.c =================================================================== --- acpi.c (revision 261235) +++ acpi.c (working copy) @@ -1190,6 +1190,7 @@ acpi_set_resource(device_t dev, device_t child, in struct acpi_softc *sc = device_get_softc(dev); struct acpi_device *ad = device_get_ivars(child); struct resource_list *rl = &ad->ad_rl; + ACPI_DEVICE_INFO *devinfo; u_long end; /* Ignore IRQ resources for PCI link devices. */ @@ -1196,6 +1197,21 @@ acpi_set_resource(device_t dev, device_t child, in if (type == SYS_RES_IRQ && ACPI_ID_PROBE(dev, child, pcilink_ids) != NULL) return (0); + /* + * Ignore memory resources for PCI root bridges. Some BIOSes + * incorrectly enumerate the memory ranges they decode as plain + * memory resources instead of as a ResourceProducer range. + */ + if (type == SYS_RES_MEMORY) { + if (ACPI_SUCCESS(AcpiGetObjectInfo(ad->ad_handle, &devinfo))) { + if ((devinfo->Flags & ACPI_PCI_ROOT_BRIDGE) != 0) { + AcpiOsFree(devinfo); + return (0); + } + AcpiOsFree(devinfo); + } + } + /* If the resource is already allocated, fail. */ if (resource_list_busy(rl, type, rid)) return (EBUSY); -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 31 00:08:39 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AAB9EEA0; Fri, 31 Jan 2014 00:08:39 +0000 (UTC) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 44BB213C9; Fri, 31 Jan 2014 00:08:39 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id cm18so5334585qab.37 for ; Thu, 30 Jan 2014 16:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pVDYzSm3FHQS5dd+M+Gqbk8kliQGuExTZS8kK/aARZM=; b=abJZa0WlJa7J7UItfPWUN2wcZCqcCSkUGMgXiBRcdyuYme9xhEY+nfSq+qIuv8dPjm /3fPr5gPhD17Uq8IH9C7rZTJQwBl11Z6EE17wQC0iBG4FuNTZem6Q/KsJriAjlAncPoK PQqUdD9i1st40l60pN/gnmfVj/DhiSkft+CyP4W/TlND0lDpt4wS7OKB5+u6STnYXZ3m IDtxcfZKhhHGsfXRs4IR/HC4y+ZFclhJ78bxGiKjCNYcE1l/0BTG+UnmjARy/aF27yW8 5hjZqLds4AReXTfZIsvZNAkNB+FOEXwKC65cVzoogpG41BZj+M6dGYfQyWSsYBES/eOO c3vQ== MIME-Version: 1.0 X-Received: by 10.140.108.74 with SMTP id i68mr24980651qgf.87.1391126917887; Thu, 30 Jan 2014 16:08:37 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Thu, 30 Jan 2014 16:08:37 -0800 (PST) In-Reply-To: <201306141139.16728.jhb@freebsd.org> References: <512A6FFF.2060603@gmail.com> <201302281209.45170.jhb@freebsd.org> <51394952.9030700@gmail.com> <201306141139.16728.jhb@freebsd.org> Date: Thu, 30 Jan 2014 16:08:37 -0800 X-Google-Sender-Auth: B1J0jTsW1tIamZkKvxYPlW_f0oA 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 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 00:08:39 -0000 So now that i have everything else working on this x230, I'm taking a fresh look at the acpi brightness support. I'm in the same boat - only PEG works. But I have integrated graphics only, rather than both integrated and nvidia graphics. A cursory reading of the linux acpi and video / video-detect code doesn't show anything terribly obvious. I may end up downloading and booting ubuntu on USB at some point to see what the ACPI device tree looks like, in case they are somehow linking vgapci0 correctly to SB.PCI0.PEG.VID. Any other ideaS? -a