From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [BUG] test9 ACPI bad: scheduling while atomic! Date: Mon, 27 Oct 2003 09:47:09 -0700 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: <1067273229.7497.30.camel@patsy.fc.hp.com> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: "Noah J. Misch" Cc: linux-kernel , acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, jon-fdRWMHV75ajk1uMJSBkQmQ@public.gmane.org List-Id: linux-acpi@vger.kernel.org On Mon, 2003-10-27 at 01:22, Noah J. Misch wrote: > This problem stems from the changes in revision 1.26 of drivers/acpi/ec.c. > They come from a patch Shaohua Li submitted for kernel bug 1171 at > bugme.osdl.org. That patch can cause acpi_ec_gpe_query to run in interrupt > context, whereas before it always ran from a workqueue. It does non-interrupt > like things, like sleeping and kmalloc'ing with GFP_KERNEL. > > 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? 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. 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? Alex -- Alex Williamson HP Linux & Open Source Lab ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/