What are rules for acpi_ex_enter_interpreter?

What are rules for acpi_ex_enter_interpreter?

[Petr Vandrovec]

Hi Andrew,
  ACPI was reporting no S* states on my machine (ASUS A7V) for some time
and today I finally got some time to debug it. Problem is that during
initialization namespace init calls acpi_walk_namespace without
interpreter lock held - but it is wrong - as you can see from stack
trace, acpi_walk_namespace can call down to acpi_ev_address_space_dispatch,
which can call acpi_ex_exit_interpreter - and this is fatal on unlocked
lock :-(

  This points us to another problem - when acpi is compiled into kernel,
for some reason there is pending signal in thread doing ospm_busmgr and 
ospm_system initialization, so it fails to acquire lock because of
down_interruptible fails... but does not print any message, just no
valid S states are found. When acpi is compiled as module, modprobe
hangs until you hit ^C - then it is converted to previous case - module
says OK, but did nothing in reality.

  I did NOT verified other callers of acpi_walk_namespace... And there
is still some problem left, as although now S5 is listed as available,
poweroff still does nothing instead of poweroff.
					Best regards,
						Petr Vandrovec
						vandrove@vc.cvut.cz

Jul  4 02:03:02 ppc kernel: CPU:    0
Jul  4 02:03:02 ppc kernel: EIP:    0010:[printstate+9/48]
Jul  4 02:03:02 ppc kernel: EFLAGS: 00000202
Jul  4 02:03:02 ppc kernel: eax: 0000000e   ebx: c01680d0   ecx: c020e996   edx: 00000001
Jul  4 02:03:02 ppc kernel: esi: cff75e3c   edi: c1428a4c   ebp: c1428c8c   esp: c140dc34
Jul  4 02:03:02 ppc kernel: ds: 0018   es: 0018   ss: 0018
Jul  4 02:03:02 ppc kernel: Process swapper (pid: 1, stackpage=c140d000)
Jul  4 02:03:02 ppc kernel: Stack: c140dc38 00000018 c016955a c016206c 000fdf00 00000000 00000000 00000000 
Jul  4 02:03:02 ppc kernel:        c1428a4c c140dcd4 c0166438 c1428a4c 00000001 000fdf00 00000000 00000020 
Jul  4 02:03:02 ppc kernel:        c140dcd4 c140e50c c020c5cc c015c8a5 c140e50c c020c685 00000001 c020e320 
Jul  4 02:03:02 ppc kernel: Call Trace: [acpi_ex_exit_interpreter+26/48] [acpi_ev_address_space_dispatch+124/208] [acpi_ex_read_field_datum+120/224] [debug_print+21/160] [function_status_exit+49/64] 
Jul  4 02:03:02 ppc kernel:    [acpi_ex_extract_from_field+123/432] [acpi_ex_common_access_field+56/64] [acpi_ex_access_region_field+36/64] [acpi_ex_read_data_from_field+220/288] [acpi_ex_resolve_node_to_value+411/560] [acpi_ex_resolve_to_value+42/80] 
Jul  4 02:03:02 ppc kernel:    [acpi_ex_resolve_operands+282/768] [acpi_ds_eval_region_operands+56/144] [acpi_ds_exec_end_op+705/752] [acpi_ps_parse_loop+945/1904] [acpi_ut_release_mutex+103/144] [acpi_ut_create_generic_state+63/128] 
Jul  4 02:03:02 ppc kernel:    [acpi_ps_parse_aml+519/640] [acpi_ds_get_region_arguments+222/256] [acpi_ds_exec_begin_op+0/304] [acpi_ds_exec_end_op+0/752] [acpi_ns_init_one_object+91/96] [acpi_ns_walk_namespace+193/288] 
Jul  4 02:03:02 ppc kernel:    [acpi_ns_init_one_object+0/96] [acpi_walk_namespace+85/128] [acpi_ns_init_one_object+0/96] [acpi_ns_initialize_objects+61/80] [acpi_ns_init_one_object+0/96] [acpi_enable_subsystem+149/320] 
Jul  4 02:03:02 ppc kernel:    [acpi_enable_subsystem+188/320] [acpi_init+283/352] [rest_init+0/48] [init+11/320] [rest_init+0/48] [kernel_thread+38/48] 
Jul  4 02:03:02 ppc kernel:    [init+0/320] 
Jul  4 02:03:02 ppc kernel: 
Jul  4 02:03:02 ppc kernel: Code: 50 1e 06 50 55 57 56 52 51 53 89 e0 50 e8 b5 fe ff ff 83 c4 

diff -urdN linux/drivers/acpi/namespace/nsinit.c linux/drivers/acpi/namespace/nsinit.c
--- linux/drivers/acpi/namespace/nsinit.c	Tue Jul  3 15:58:35 2001
+++ linux/drivers/acpi/namespace/nsinit.c	Wed Jul  4 02:20:49 2001
@@ -27,6 +27,7 @@
 #include "acpi.h"
 #include "acnamesp.h"
 #include "acdispat.h"
+#include "acinterp.h"
 
 #define _COMPONENT          ACPI_NAMESPACE
 	 MODULE_NAME         ("nsinit")
@@ -62,10 +63,17 @@
 
 	/* Walk entire namespace from the supplied root */
 
+	status = acpi_ex_enter_interpreter();
+	if (ACPI_FAILURE(status)) {
+		return status;
+	}
+	
 	status = acpi_walk_namespace (ACPI_TYPE_ANY, ACPI_ROOT_OBJECT,
 			  ACPI_UINT32_MAX, acpi_ns_init_one_object,
 			  &info, NULL);
 
+	acpi_ex_exit_interpreter();
+	
 	return (AE_OK);
 }
 

Re: What are rules for acpi_ex_enter_interpreter?

[Petr Vandrovec]

On Wed, Jul 04, 2001 at 03:38:07AM +0200, Petr Vandrovec wrote:
> 
>   I did NOT verified other callers of acpi_walk_namespace... And there
> is still some problem left, as although now S5 is listed as available,
> poweroff still does nothing instead of poweroff.

Replying to myself, after following change in additon to acpi_ex_...
poweroff on my machine works. It should probably map type 0 => 0, 3 => 1
and 7 => 2, but it is hard to decide without VIA datasheet, so change
below is minimal change needed to get poweroff through ACPI to work on my 
ASUS A7V.
						Best regards,
							Petr Vandrovec
							vandrove@vc.cvut.cz
 
diff -urdN linux/drivers/acpi/hardware/hwsleep.c linux/drivers/acpi/hardware/hwsleep.c
--- linux/drivers/acpi/hardware/hwsleep.c	Tue Jul  3 15:58:35 2001
+++ linux/drivers/acpi/hardware/hwsleep.c	Wed Jul  4 16:07:47 2001
@@ -146,6 +146,13 @@
 		return status;
 	}
 
+	/* Broken ACPI table on ASUS A7V... it reports type 7, but poweroff is type 2... 
+	   sleep is type 1 while ACPI reports type 3, but as I was not able to get 
+	   machine to wake from this state without unplugging power cord... */
+	if (type_a == 7 && type_b == 7 && sleep_state == ACPI_STATE_S5 && !memcmp(acpi_gbl_DSDT->oem_id, "ASUS\0\0", 6)
+			&& !memcmp(acpi_gbl_DSDT->oem_table_id, "A7V     ", 8)) {
+		type_a = type_b = 2;
+	}
 	/* run the _PTS and _GTS methods */
 
 	MEMSET(&arg_list, 0, sizeof(arg_list));

> diff -urdN linux/drivers/acpi/namespace/nsinit.c linux/drivers/acpi/namespace/nsinit.c
> --- linux/drivers/acpi/namespace/nsinit.c	Tue Jul  3 15:58:35 2001
> +++ linux/drivers/acpi/namespace/nsinit.c	Wed Jul  4 02:20:49 2001
> @@ -27,6 +27,7 @@
>  #include "acpi.h"
>  #include "acnamesp.h"
>  #include "acdispat.h"
> +#include "acinterp.h"
>  
>  #define _COMPONENT          ACPI_NAMESPACE
>  	 MODULE_NAME         ("nsinit")
> @@ -62,10 +63,17 @@
>  
>  	/* Walk entire namespace from the supplied root */
>  
> +	status = acpi_ex_enter_interpreter();
> +	if (ACPI_FAILURE(status)) {
> +		return status;
> +	}
> +	
>  	status = acpi_walk_namespace (ACPI_TYPE_ANY, ACPI_ROOT_OBJECT,
>  			  ACPI_UINT32_MAX, acpi_ns_init_one_object,
>  			  &info, NULL);
>  
> +	acpi_ex_exit_interpreter();
> +	
>  	return (AE_OK);
>  }
>  

Re: What are rules for acpi_ex_enter_interpreter?

[Pavel Machek]

Hi!

> >   I did NOT verified other callers of acpi_walk_namespace... And there
> > is still some problem left, as although now S5 is listed as available,
> > poweroff still does nothing instead of poweroff.
> 
> Replying to myself, after following change in additon to acpi_ex_...
> poweroff on my machine works. It should probably map type 0 => 0, 3 => 1
> and 7 => 2, but it is hard to decide without VIA datasheet, so change
> below is minimal change needed to get poweroff through ACPI to work on my 
> ASUS A7V.

You should printk loudly during bootup, so people know their hw is b0rken.

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: What are rules for acpi_ex_enter_interpreter?

[Mario 'BitKoenig' Holbe]

Hoi,

i'm not on the linux-kernel@ list, so the references are
broken, sorry for that :)

You wrote:
> On Wed, Jul 04, 2001 at 03:38:07AM +0200, Petr Vandrovec wrote:
> Replying to myself, after following change in additon to acpi_ex_...
> poweroff on my machine works. It should probably map type 0 => 0, 3 => 1
> and 7 => 2, but it is hard to decide without VIA datasheet, so change
> below is minimal change needed to get poweroff through ACPI to work on
> my ASUS A7V.
> diff -urdN linux/drivers/acpi/hardware/hwsleep.c
> > diff -urdN linux/drivers/acpi/namespace/nsinit.c

Yeah, this fixes the ACPI Power off "Cannot enter S5" problem
on my ASUS CUV4X-D too.

Of course, I applied the patch without the memcmp()s :)


regards,
   Mario
-- 
Mario 'BitKoenig' Holbe <Mario.Holbe@RZ.TU-Ilmenau.DE>

So long and thanks for all the books.

RE: What are rules for acpi_ex_enter_interpreter?

[Grover, Andrew]

Thanks for the report on the locking issue. A fix is checked in locally.

> From: Petr Vandrovec [mailto:vandrove@vc.cvut.cz]
> Replying to myself, after following change in additon to acpi_ex_...
> poweroff on my machine works. It should probably map type 0 
> => 0, 3 => 1
> and 7 => 2, but it is hard to decide without VIA datasheet, so change
> below is minimal change needed to get poweroff through ACPI 
> to work on my 
> ASUS A7V.

How did you discover slp typ values of 2 worked, where 7 did not? Did you
just try all possibilities (0-7)?

Regards -- Andy

Re: What are rules for acpi_ex_enter_interpreter?

[Petr Vandrovec]

On Thu, Jul 05, 2001 at 04:05:43PM -0700, Grover, Andrew wrote:
> Thanks for the report on the locking issue. A fix is checked in locally.
> 
> > From: Petr Vandrovec [mailto:vandrove@vc.cvut.cz]
> > Replying to myself, after following change in additon to acpi_ex_...
> > poweroff on my machine works. It should probably map type 0 
> > => 0, 3 => 1
> > and 7 => 2, but it is hard to decide without VIA datasheet, so change
> > below is minimal change needed to get poweroff through ACPI 
> > to work on my 
> > ASUS A7V.
> 
> How did you discover slp typ values of 2 worked, where 7 did not? Did you
> just try all possibilities (0-7)?

Yes, in Borland TurboDebugger under MSDOS. 

0 and 7 do nothing, 
1 power offs, but power led blinks and I was not able to get machine back 
  to life without unplugging power cord (it did not react to reset or 
  power button). Maybe when it is correctly suspended, or when there is
  running ACPI interpreter, it can return back to life, but not under MSDOS.
2 power offs and LED is off
3 did nothing and 
4-6 locked machine up just after outw(). Maybe it does something, but
  when tried from TD it just stopped react to anything (incl. poweroff)
  except reset button.

If bit 0x2000 is not set, it does nothing, and if you write random values
to SLP port, it somehow switches to another mode where it reads back
as 0x0000 and does not react to any outw values :-( Reset fixes this state...

I hope that I remember states 3-6 correctly, but at least two of them
are lockup, and at least one of them was nothing. But I'm 100% sure on
0,1,2 and 7.
					Best regards,
						Petr Vandrovec
						vandrove@vc.cvut.cz