From owner-freebsd-mobile@FreeBSD.ORG Wed Sep 17 10:09:40 2014 Return-Path: Delivered-To: freebsd-mobile@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 E19AFE46 for ; Wed, 17 Sep 2014 10:09:40 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F1A68A4 for ; Wed, 17 Sep 2014 10:09:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s8HA9IFm024885; Wed, 17 Sep 2014 20:09:19 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 17 Sep 2014 20:09:17 +1000 (EST) From: Ian Smith To: isdtor Subject: Re: ThinkPad support In-Reply-To: <20140916213835.GA4575@localhost.localdomain> Message-ID: <20140917193232.K61666@sola.nimnet.asn.au> References: <20140916213835.GA4575@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-mobile@freebsd.org X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 10:09:41 -0000 On Tue, 16 Sep 2014 22:38:35 +0100, isdtor wrote: [.. I can't comment on your devd issue/s ..] > Sep 16 21:48:23 host kernel: pci0: failed to set ACPI power state D2 on > \_SB_.PCI0.EXP1: AE_BAD_PARAMETER This appears to be common to all Thinkpads for the last 6 years or so, when booting with verbose messages. This message is emitted late on the suspend path, and seems to indicate some device that has advertised D2 as an available state, where D2 isn't apparently really supported. On the resume path, not much later in the messages sequence, you should see power being set back to D0 state, successfully. Perhaps - as in the case of my X200 - twice in a row, for devices \_SB_.PCI0.EXP0 thru .EXP3 I don't know if this failure means that the device was left in D0 state (run) or in D3 state (off) when power was removed in S3 suspend state. I never have been able to connect the dots between these .EXPn devices and particular PCI devices in dmesg. So far they appear to be harmless. cheers, Ian