Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 27 Oct 2003 10:02:37 -0800 (PST) | From | "Noah J. Misch" <> | Subject | Re: [BUG] test9 ACPI bad: scheduling while atomic! |
| |
On Mon, 27 Oct 2003, Alex Williamson wrote:
> > This was obvious on my system because it has no ECDT table, and as such > > acpi_ec_gpe_query was _always_ running in interrupt context, whereas with an > > ECDT it would only do so for a brief time during boot, and the problem would be > > much more subtle. That's probably why nobody noticed this in earlier tests. > > > > I don't have an ECDT either. Is it possible that the setting of > ec_device_init = 1 is simply misplaced?
It is misplaced. If revision 1.26 of ec.c were otherwise sound, I would place ec_device_init = 1 right before the call to acpi_install_gpe_handler in acpi_ec_start. Anywhere outside that if and between where _add removes the handlers and _start installs them would work. This would fix your crash, but it's not the right fix.
> I can see why we wouldn't want to call acpi_os_queue_for_execution() early in > bootup, but there ought to be a fixed point after which it's ok, regardless of > whether the system has the ECDT table.
I don't think early calls to schedule_work (via acpi_os_queue_for_execution) are a problem. The call to init_workqueues is just before do_initcalls in do_basic_setup, so it happens earlier than all this stuff.
The more general problem is that acpi_ec_gpe_query cannot run in an interrupt handler as written. It used to always run from a queue. We can either fix it so it can run from an interrupt handler or change it back to never doing so. I favor the latter, especially because I don't see how the recent change fixed the problem T40 users were experiencing.
> Would it be sufficient to set ec_device_init to 1 at the beginning of > acpi_ec_add(), with no dependency on the ECDT table?
That particular placement looks racy. I would do it after removing the handlers, as explained above.
Thanks, Noah
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |