Date: Tue, 24 Jun 2014 20:51:17 -0400 From: Eric McCorkle <eric@metricspace.net> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI error messages on Lenovo W540 Message-ID: <53AA1D05.6000304@metricspace.net> In-Reply-To: <201406241000.35812.jhb@freebsd.org> References: <53A048B1.1080108@metricspace.net> <201406230953.16496.jhb@freebsd.org> <53A8AD54.8040908@metricspace.net> <201406241000.35812.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/24/2014 10:00, John Baldwin wrote:
> 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: <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?
>
> 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?
It looks like this is the definition:
Method (_DSM, 4, NotSerialized) // _DSM:
Device-Specific Method
{
If (\CMPB (Arg0, Buffer (0x10)
{
/* 0000 */ 0xF8, 0xD8, 0x86,
0xA4, 0xDA, 0x0B, 0x1B, 0x47,
/* 0008 */ 0xA7, 0x2B, 0x60,
0x42, 0xA6, 0xB5, 0xBE, 0xE0
}))
{
Return (NVOP (Arg0, Arg1, Arg2, Arg3))
}
If (\CMPB (Arg0, Buffer (0x10)
{
/* 0000 */ 0x01, 0x2D, 0x13,
0xA3, 0xDA, 0x8C, 0xBA, 0x49,
/* 0008 */ 0xA5, 0x2E, 0xBC,
0x9D, 0x46, 0xDF, 0x6B, 0x81
}))
{
Return (NVPS (Arg0, Arg1, Arg2, Arg3))
}
If (\WIN8)
{
If (\CMPB (Arg0, Buffer (0x10)
{
/* 0000 */ 0x75, 0x0B, 0xA5,
0xD4, 0xC7, 0x65, 0xF7, 0x46,
/* 0008 */ 0xBF, 0xB7, 0x41,
0x51, 0x4C, 0xEA, 0x02, 0x44
}))
{
Return (NBCI (Arg0, Arg1, Arg2, Arg3))
}
}
Return (Buffer (0x04)
{
0x01, 0x00, 0x00, 0x80
})
}
Not sure if that's helpful at all...
> 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.
Will do. Is there a preferred point of contact?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53AA1D05.6000304>