ACPI error messages on Lenovo W540
Eric McCorkle
eric at metricspace.net
Mon Jun 23 22:42:32 UTC 2014
On 06/23/2014 09:53, John Baldwin wrote:
> On Tuesday, June 17, 2014 9:54:57 am Eric McCorkle wrote:
>> Hello,
>>
>> 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 think these are harmless and you can ignore them. Probably these devices
> only support D0 (on) and D3 (off) and not D2 (low power).
That makes sense. It'd be nice if we could quiet the messages, but that
wouldn't even be a second-order concern for me at this point.
>
>> 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: <Unknown> 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?
>
>> 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)?
More information about the freebsd-acpi
mailing list