Andrew Morton wrote:
On Sun, 03 Dec 2006 12:06:54 +0300
Alexey Starikovskiy <alexey.y.starikovskiy@xxxxxxxxxxxxxxx> wrote:
This is a patch reverted by Linus from rc6-git2 because it broke his
Compaq n620c, it refers to #5534 bug. Basically, kacpid deadlocks on
some new HP notebooks, and all incoming requests would be queued until
memory is over if this patch is not applied. On a bright side -- it's
not a memory leak...
Patch, which works for Linus laptop and "looks acceptable" to Linus is
the last in #5534 list.
hm, if you say so.
I forwarded Linus' mail to you...
The description in that patch is nowhere near complete
enough for me to be able to work out what it does.
Will update.
The sys_sched_yield() is particularly incomprehensible and needs good
commenting. You are, I hope, aware of the severe problems which yield()
causes when the system is busy? The process which calls it will get
practically no CPU at all.
On Linus' machine, as soon as we execute deferred work, it's GPE becomes
enabled again and BIOS sends us a new event.
So kacpid is always ready to run, while kacpi_notify don't have a chance
to run. sys_sched_yield() was added to
give kacpi_notify a chance to run.
I was thinking about lowering the priority of kacpid, is it better?
Minor point: that patch has several unneded (and undesirable) casts of void*:
+static void acpi_os_execute_notify(void *context)
+{
+ struct acpi_os_dpc *dpc = (struct acpi_os_dpc *)context;
please remove those.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
