On Tuesday, August 07, 2012 07:31:09 PM Sean Bruno wrote: > 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 meant that with the limit jacked up to something that silences the warning (such as 128), what is the max number of tasks queued? -- John Baldwin _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "[email protected]"
