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?
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[email protected]"
