From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 21 14:54:59 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 803D3F2D; Sat, 21 Jun 2014 14:54:59 +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 97CA7295C; Sat, 21 Jun 2014 14:54:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5LEsmY2072724; Sun, 22 Jun 2014 00:54:49 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 22 Jun 2014 00:54:48 +1000 (EST) From: Ian Smith To: Eric McCorkle Subject: Re: ACPI error messages on Lenovo W540 In-Reply-To: <53A4ED85.2050904@metricspace.net> Message-ID: <20140622000435.R609@sola.nimnet.asn.au> References: <53A048B1.1080108@metricspace.net> <20140618163410.C609@sola.nimnet.asn.au> <53A4ED85.2050904@metricspace.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-mobile@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: Sat, 21 Jun 2014 14:54:59 -0000 On Fri, 20 Jun 2014 22:27:17 -0400, Eric McCorkle wrote: > On 06/18/2014 03:17, Ian Smith wrote: > > On Tue, 17 Jun 2014 09:54:57 -0400, Eric McCorkle wrote: > > > > > I'm trying to set up on a lenovo W540 mobile workstation I recently > > > purchased. Things work well for the most part (including > > suspend/resume), > > > however there's some error messages that I suspect are at the root of > > why the > > > nvidia Xorg driver doesn't work, and possibly also at the root of why > > USB 3.0 > > > won't work either. > > > > > > At suspend/resume, the following error messages show up: > > > > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: > > > AE_BAD_PARAMETER > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: > > > AE_BAD_PARAMETER > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: > > > AE_BAD_PARAMETER > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3: > > > AE_BAD_PARAMETER > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: > > > AE_BAD_PARAMETER > > > > > > I suspect these might have something to do with the USB 3.0 system not > > > working, though I don't have experience with either the ACPI or USB > > > subsystems. > > > > > > Also, the nvidia Xorg driver fails to work, and causes a similar error > > > message: > > > > > > ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - > > > Found [Buffer], APCI requires [Package] (20130823/nsarguments-97) > > > (the same message gets repeated about 10 times) > > > > > > Again, I don't have any experience with ACPI, but this looks to me like > > a > > > vendor-specific quirk. > > > > > > Any advice on how to go about fixing/working around this? > > > > Hi Eric, > > > > I refer you to freebsd-mobile@ archives for May re these 'failed to set > > ACPI power state D2' messages, in thread 'Thinkpad T410: resume broken'. > > I'm also cross-posting this back there. > > I ran across those also. > > > These appear on the suspend path on (AFAICT) all modern Lenovos; X2xx, > > T4xx and T5xx at least, though I get similar messages for the Cardbus > > bridges on my old T23s. The EXPn messages at least do appear to be > > harmless though they keep causing your sort of concern, and it would be > > good in the long run to find out why attempts are being made to set > > state D2 on devices that (should indicate that they) don't support it. > > > > John Baldwin (cc'd) explains in that thread that the EXPn devices are > > "probably PCI-PCI bridges that represent the downstream ports of your > > PCI-e root complex)" though I can't say I understand what that means .. > > with verbose boot messages you may also see that these are initialised > > back into D0 state twice, unlike the other devices. > > Whatever they do, the messages suggest that it might just be what amounts to > a type error in the ACPI code (apologies for any inaccuracies; I have only > cursory knowledge of ACPI, but I know there's some kind of interpreted > language in there somewhere). It's more a virtual machine than an interpreter, in the sense that Java isn't interpreted but runs precompiled bytecode, but yes, there could be a problem in the AML, derived from the source ASL .. see acpidump(8). I am (it seems) fortunate that my X200 has pre-KMS i915 graphics that work fine including suspend/resume from X or (old) console, so I can't speculate about nvidea Xorg issues. > Again, sorry for lack of knowledge, but does FreeBSD have any sort of > functionality for working around these sort of vendor quirks? If you could clearly identify the/a problem in the ASL, someone might be inspired to help fix it, though ASL-savvy people are thin on the ground; ACPI code is a non-trivial learning curve, for this old codger anyway :) > > The PEG_ message seems to appear on the more recent ones with integrated > > graphics. I don't know if that message represents a problem or not, > > though the later warnings re \134_SB_.PCI0.PEG_.VID_._DSM seem ominous. > > Some poking around on google seems to show other lenovos (the T440p) having > similar problems with the nvidia drivers. > > I suppose a worthwhile experiment might be to remove ACPI from the kernel and > see if the driver works successfully. If the driver issues persist, I'm not > sure what to do other than contact nvidia directly. You can boot without ACPI from the loader prompt already, but I'm not sure anything modern will run at all without it. I don't go there, but expect that the Xorg list might have more eyes on video driver problems. > If it does work, however, that suggests digging into the ACPI stuff on the > lenovo as a possible way forward. I'd be willing to try, and again, the > messages suggest it's a relatively simple programming error somewhere in the > Lenovo ACPI stuff. Well, disassemble your ACPI according to acpidump(8) to start hunting. The old ACPI debugging page in the Handbook has been merged into the (imho) less well-named section '12.13. Power and Resource Management', http://www.freebsd.org/doc/handbook/acpi-overview.html which may help. > > It would be good to know if your USB3 issues are connected to the more > > generic issue all these Lenovos appear to have of USB failing entirely, > > only on the external ports, after - depending on model - one or two > > suspend/resume cycles. There's not even any 5V on these ports, whether > > or not the BIOS has been set to provide 5V on these ports in suspend or > > power-off states. Does that also happen on yours? > > The apparent connection to the USB issues seems likely to be a red herring at > this point. The messages show up near some USB error messages, but that > seems to just be "luck". Mmm, and the ACPI PEG_ messages may not really be the main issue at all. > I found some other threads about USB 3.0 issues, but in general, USB seems to > work. There were serious issues when I first installed, but after an update > and a kernel compile, they went away. I can mount a thumb drive and my phone > starts charging if I plug it in. There's still an error message, but > honestly, I'm more interested in getting the nvidia driver working at this > point. Fair enough, but if you can suspend and resume more than once and still have working USB ports, that may be the first recent Lenovo that can .. cheers, Ian