From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 4 17:15:32 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 E0879393; Wed, 4 Jun 2014 17:15:31 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACE0C2942; Wed, 4 Jun 2014 17:15:31 +0000 (UTC) Received: from [192.168.200.104] (c-50-131-4-11.hsd1.ca.comcast.net [50.131.4.11]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 712F119294A; Wed, 4 Jun 2014 17:15:30 +0000 (UTC) Subject: Re: Investigating failed suspend/resume T61 From: Sean Bruno Reply-To: sbruno@freebsd.org To: Adrian Chadd In-Reply-To: References: <1400861698.1126.0.camel@bruno> <538666AE.4030501@FreeBSD.org> <1401369401.1100.1.camel@bruno> <201405290930.00425.jhb@freebsd.org> <1401898025.1123.17.camel@bruno> Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Jun 2014 10:15:28 -0700 Message-ID: <1401902128.1123.26.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:15:32 -0000 On Wed, 2014-06-04 at 09:35 -0700, Adrian Chadd wrote: > Which devices? > > > -a > > On 4 June 2014 09:07, Sean Bruno wrote: > > On Thu, 2014-05-29 at 09:30 -0400, John Baldwin wrote: > >> On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote: > >> > On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote: > >> > > -----BEGIN PGP SIGNED MESSAGE----- > >> > > Hash: SHA1 > >> > > > >> > > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > >> > > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > >> > > > length of zero (and is thus invalid)? > >> > > > >> > > BTW, ACPI 5.0a (page 121) says: > >> > > > >> > > "This is an optional field; if this register block is not supported, > >> > > this field contains zero." > >> > > > >> > > Therefore, we must assume X_GPE1_BLK it is NOT supported. > >> > > > >> > > Jung-uk Kim > >> > > >> > So, reverting John's changes and applying yours seems to do new things > >> > while not quieting the old error messages. Perhaps this is significant? > >> > > >> > real memory = 2147483648 (2048 MB) > >> > avail memory = 2007089152 (1914 MB) > >> > Event timer "LAPIC" quality 400 > >> > ACPI APIC Table: > >> > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > >> > FreeBSD/SMP: 1 package(s) x 2 core(s) > >> > cpu0 (BSP): APIC ID: 0 > >> > cpu1 (AP): APIC ID: 1 > >> > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > >> > (20130823/tbfadt-601) > >> > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > >> > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) > >> > ioapic0: Changing APIC ID to 1 > >> > ioapic0 irqs 0-23 on motherboard > >> > random: initialized > >> > kbd1 at kbdmux0 > >> > acpi0: on motherboard > >> > CPU0: local APIC error 0x40 > >> > ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to > >> > 15) - Ignoring GPE1 (20130823/evgpeinit-178) > >> > >> Actually, I think all these patches are changing nothing, and this actually > >> points out that I misread your FADT at the first. GPE1 should actually be > >> ignored since it does in fact overlap. Can you just try reverting all your > >> changes and seeing if suspend/resume works? > >> > > > > > > Boy oh boy ... talk about a waste of time. > > > > trasz@ and I have the same laptop and I just confirmed with him that the > > patch does nothing useful (as both of you suggested). The *ACTUAL* > > problem seems to be related to disabling devices in the Thinkpad BIOS. > > > > Disabling devices seems to cause the resume to not work correctly, but > > whatever. So none of these patches are actually needed. > > > > sean > > It looks like the on board modem is a bit touchy. sean hdacc1: at cad 1 on hdac0 unknown: at nid 2 on hdacc1 (no driver attached)