>>>>> On Wed, 17 Mar 2004 20:48:00 +0800, "Yu, Luming" <luming.yu@intel.com> said: >> The main difference with 2.4 is signal_pending. From ACPI log, I >> also noticed that the thread waiting on acpi_bus_event_queue >> didn't resume proberly, because there is no exit message of >> acpi_bus_receive_event in ACPI log as expected if you turn on >> full debug flag of acpi. Luming> After comparing the disassembly code of Luming> acpi_bus_receive_event() , I find the following difference Luming> introduced by my workaround: Luming> 155c155 Luming> 12d0: 00 00 00 1a b8 11 [MII] st8.rel [r13]=r0 Luming> --- Luming> 12d0: 00 40 00 1a b8 15 [MII] st8.rel [r13]=r0,8 Luming> Perhaps, gcc did something wrong with Luming> set_current_state(TASK_RUNNING). Because r13 intend for Luming> pointer to the current task. How nasty! Your hunch about bad code-generation was right, after all! Luming> The following is my patch, which can fix this issue. Luming> - { Luming> \ Luming> - register __u64 ia64_r13 asm ("r13"); Luming> \ Luming> - ia64_intri_res = ia64_r13; Luming> \ Luming> - } Luming> \ Luming> + asm volatile ("mov %0=r13" : "=r"(ia64_intri_res)); Unfortunately, this leads to worse-quality code. I think we may have to resort to an #ifdef __INTEL_COMPILER in <asm-ia64/current.h> so that we can use a global register for GCC as we used to. I'll look into this today. Thanks, --david - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Mar 17 10:58:35 2004
This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:24 EST