From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 24 14:27:30 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 08437907 for ; Tue, 24 Jun 2014 14:27:30 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9D312FB0 for ; Tue, 24 Jun 2014 14:27:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D44A6B94A; Tue, 24 Jun 2014 10:27:28 -0400 (EDT) From: John Baldwin To: Eric McCorkle Subject: Re: ACPI error messages on Lenovo W540 Date: Tue, 24 Jun 2014 10:00:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <53A048B1.1080108@metricspace.net> <201406230953.16496.jhb@freebsd.org> <53A8AD54.8040908@metricspace.net> In-Reply-To: <53A8AD54.8040908@metricspace.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201406241000.35812.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 24 Jun 2014 10:27:28 -0400 (EDT) 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: Tue, 24 Jun 2014 14:27:30 -0000 On Monday, June 23, 2014 6:42:28 pm Eric McCorkle wrote: > On 06/23/2014 09:53, John Baldwin wrote: > > On Tuesday, June 17, 2014 9:54:57 am Eric McCorkle wrote: > >> 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. > > > > Does it not work in general, or does it not work after resume? > > Actually, USB seems to be working quite well. It even detects an > already plugged-in mouse during the ith resume. > > The sign of trouble are some messages that show up during resume: > > usb_alloc_device: device init 2 failed (USB_ERR_IOERROR, ignored) > ugen0.2: at usbus2 (disconnected) > uhub_reattach_port: could not allocate new device > > There had been some timeout messages, which googling seemed to implicate > was a USB 3.0 issue with lenovos, but those seem to have disappeared (I > did do a kernel update). > > Maybe I should test USB 3.0-specific features to see if they are > working. Unfortunately, I'm not that familiar with the gritty details > of USB. Any ideas for how to do that? There was a recent fix to acpi_pwrres.c that fixed USB issues on resume for several ThinkPads because the kernel wasn't properly turning certain things back on during resume, so if your problems were only with resume, then there's a good chance they should now be fixed (and it sounds like they did after you updated). > > > >> 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) > > > > That is a very different error, but it might explain nvidia driver problems. > > The ACPI spec explains how _DSM works (there's an example method in section 9 > > of the 5.0 spec which you can get from acpi.info). In this case the warning > > is complaining that the return type is incorrect. Of course, the spec says > > that this function should return a Buffer, but ACPICA seems to think it should > > return a Package. It would be good to track down which specific arguments > > were passed to _DSM and then examine the acpidump to see which path that would > > take. > > I looked at acpidump, and I was able to find the definition of _DSM. Is > there a way to get better ACPI debugging info out of the kernel (aside > from adding debug messages directly)? Probably not in this case, though just looking at the source of the _DSM method might be a start. However, re-reading this warning (and checking the source), the problem is not in the _DSM method, but in some code calling the _DSM method. Are there any calls to _DSM in your acpidump? Ah, the nvidia driver calls _DSM and it has the bug. In its nvidia_acpi.c file it uses a Buffer instead of a Package for the fourth argument to _DSM. OTOH, the warning doesn't prevent the method from running, so the warning may be harmless. You can try contacting the nvidia folks to tell them about the warning and point out the bug in their _DSM wrapper in nvidia_acpi.c to see what they say. -- John Baldwin