Re: ACPI debug messages
On Sat, 11 Oct 2014 14:10:07 -0400, Eric McCorkle wrote: Hello, I decided to try tracing through the evaluation of the DSM method in order to track down where the graphics driver failure I mentioned earlier is coming from. However, it looks like there's already an extensive debug logging system in place in the acpica system. Can this be controlled from user space (presumably through sysctls), or does it need to be compiled in? It's all in acpi(4), and in the Handbook in the nowadays rather poorly-named Power and Resource Management at section 12.13.4: http://www.freebsd.org/doc/handbook/acpi-overview.html You can add it to your kernel, but I think acpi is now always loaded as a module, therefore you just need to rebuild the module, as described. cheers, Ian ___ 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
Re: ACPI debug messages
On 10/11/2014 14:10, Eric McCorkle wrote: Hello, I decided to try tracing through the evaluation of the DSM method in order to track down where the graphics driver failure I mentioned earlier is coming from. However, it looks like there's already an extensive debug logging system in place in the acpica system. Can this be controlled from user space (presumably through sysctls), or does it need to be compiled in? My experience has been you at least need to recompile the kernel with 'options ACPI_DEBUG'. Then you can control debug output with loader tunables 'debug.acpi.layer' and 'debug.acpi.layer' (you can probably use sysctl(8) with these too, but don't think I tried). Anthony Jenkins ___ 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 ___ 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
Re: ACPI debug messages
Thanks. I turned on maximum logging, tried starting X, and walked through the traces. I think I can definitely rule out the ACPI error messages as being relevant at this point. The argument type check fails, but the methods all execute normally. The actual issue seems to be optimus-related instead. Thanks for all the help, though. On 10/12/2014 07:14, Ian Smith wrote: On Sat, 11 Oct 2014 14:10:07 -0400, Eric McCorkle wrote: Hello, I decided to try tracing through the evaluation of the DSM method in order to track down where the graphics driver failure I mentioned earlier is coming from. However, it looks like there's already an extensive debug logging system in place in the acpica system. Can this be controlled from user space (presumably through sysctls), or does it need to be compiled in? It's all in acpi(4), and in the Handbook in the nowadays rather poorly-named Power and Resource Management at section 12.13.4: http://www.freebsd.org/doc/handbook/acpi-overview.html You can add it to your kernel, but I think acpi is now always loaded as a module, therefore you just need to rebuild the module, as described. cheers, Ian ___ 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
ACPI debug messages
Hello, I decided to try tracing through the evaluation of the DSM method in order to track down where the graphics driver failure I mentioned earlier is coming from. However, it looks like there's already an extensive debug logging system in place in the acpica system. Can this be controlled from user space (presumably through sysctls), or does it need to be compiled in? ___ 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
