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