On Tue, 2012-08-07 at 14:30 -0700, John Baldwin wrote: > On Tuesday, August 07, 2012 2:43:17 pm Sean Bruno wrote: > > On Tue, 2012-07-31 at 09:13 -0700, Sean Bruno wrote: > > > On Mon, 2012-07-30 at 05:07 -0700, John Baldwin wrote: > > > > > I am currently running with a value of 128 and doing a bit of > > > > testing. > > > > > > > > I think it should be something like MAX(32, MAXCPU). > > > > > > Ah, that sounds WAY more reasonable. I shall test thusly. > > > > > > Sean > > > > > > > This did *not* work on a dual socket machine with MAXCPU at 64. > > Hmm, can you find out how many tasks it wanted? I know part of > it is a function of the number of CPUs (we queue a task for each > CPU at one point before tasks are running). >
I extended the log message in acpi_task enqueue() with the current task count, max task setting and max thread setting when the error occurs. It appears that we are definitely going above max tasks from my review: AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable acpi_task_count(64), acpi_max_tasks(64) max_threads(3) I don't see any evidence that the log message in acpi_taskq_init() is firing at any point. "if (acpi_task_count > 0) ..." Sean _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "[email protected]"
