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