[PATCH] current ( was RE: cat /proc/acpi/events bad for your system's health!)

[PATCH] current ( was RE: cat /proc/acpi/events bad for your system's health!)

[Yu, Luming]

> 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.

After comparing the disassembly code of acpi_bus_receive_event() , I
find the following difference
introduced by my workaround:

155c155
<     12d0:     00 00 00 1a b8 11       [MII]       st8.rel [r13]=r0
---
>     12d0:     00 40 00 1a b8 15       [MII]       st8.rel [r13]=r0,8


Perhaps, gcc did something wrong with set_current_state(TASK_RUNNING).
Because r13 intend for pointer to the current task.

The following is my patch, which can fix this issue.

--Luming

diff -Bru 2.6.new/include/asm-ia64/gcc_intrin.h
patched/include/asm-ia64/gcc_intrin.h
--- 2.6.new/include/asm-ia64/gcc_intrin.h	2004-03-17
11:57:34.000000000 +0800
+++ patched/include/asm-ia64/gcc_intrin.h	2004-03-17
20:39:44.000000000 +0800
@@ -67,10 +67,7 @@
 		asm volatile ("mov %0=psr" : "=r"(ia64_intri_res));
\
 		break;
\
 	case _IA64_REG_TP:	/* for current() */
\
-		{
\
-			register __u64 ia64_r13 asm ("r13");
\
-			ia64_intri_res = ia64_r13;
\
-		}
\
+		asm volatile ("mov %0=r13" : "=r"(ia64_intri_res));
\
 		break;
\
 	case _IA64_REG_AR_KR0 ... _IA64_REG_AR_EC:
\
 		asm volatile ("mov %0=ar%1" : "=r" (ia64_intri_res)
\

Re: [PATCH] current ( was RE: cat /proc/acpi/events bad for your system's health!)

[David Mosberger]

>>>>> 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

Re: [PATCH] current ( was RE: cat /proc/acpi/events bad for your system's health!)

[David Mosberger]

>>>>> On Wed, 17 Mar 2004 20:48:00 +0800, "Yu, Luming" <luming.yu@intel.com> said:

  Luming> Perhaps, gcc did something wrong with
  Luming> set_current_state(TASK_RUNNING).  Because r13 intend for
  Luming> pointer to the current task.

OK, the problem was that r13 should have been declared as a _global_
register variable in gcc_intrin.h.  This is fixed now.

Thanks,

	--david