From mboxrd@z Thu Jan 1 00:00:00 1970 From: Len Brown Subject: RE: stack overflow Date: 10 Mar 2004 13:40:05 -0500 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: <1078944005.2549.50.camel@dhcppc4> 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-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Stuart_Hayes-DYMqY+WieiM@public.gmane.org Cc: Robert Moore , Andi Kleen , ACPI Developers List-Id: linux-acpi@vger.kernel.org Stuart, not that I expect it to make a difference, but note that you can update to the latest ACPI interpreter by applying the ACPI patch here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/ I do have a patch there for 2.4.25. Thanks for all the info -- I'm sure that Bob will be able to use it to find out why the interpreter erroneously went recursive. thanks, -Len On Wed, 2004-03-10 at 12:08, Stuart_Hayes-DYMqY+WieiM@public.gmane.org wrote: > Here is the console output that occurred right before the lowest > stack pointer occurred (the point where the system output the list > of ACPI functions that I sent earlier). You can see from this > which methods were being executed, and where the code was in > evaluating ...VPR0.D0F0._STA. > > Also, I should probably mention that this is a 2.4 kernel. It's > RHEL3, which is based on 2.4.21, but I've tested this with the > latest 2.4 kernel (2.4.25), and the results were the same. > > Thanks > Stuart > > > in acpi_ns_init_one_device for D0F0 (ptr=0000010001ddacf0) > . in acpi_ns_evaluate_relative to execute D0F0, method _STA > ...internalized path=_STA > ...looked up node, pointer=0000010001dd91f0 > (in apci_ns_execute_control_method _STA) > (method aml: a4 4d 53 54 41 56 44 49 44 ) > in acpi_ns_evaluate_relative to execute D0F0, method _ADR > ...internalized path=_ADR > ...looked up node, pointer=0000010001ddad70 > (in apci_ns_execute_control_method _ADR) > (method aml: a4 4d 41 44 52 a 0 ) > in acpi_ns_evaluate_relative to execute VPR0, method _ADR > ...internalized path=_ADR > ...looked up node, pointer=0000010001ddbaf0 > (in apci_ns_execute_control_method _ADR) > (method aml: 70 c 0 0 6 0 60 70 5c 2f 4 5f 53 42 5f 50 43 49 30 49 53 41 > 5f 43 50 54 50 61 a0 c 93 61 a 1 70 c 0 0 a 0 60 70 60 44 45 56 4e 70 60 5b > 31 a4 60 ) > [ACPI Debug] Integer: 0000000000060000 > ...exiting acpi_ns_evaluate_relative for obj=_ADR > in acpi_ns_evaluate_relative to execute PCI0, method _SEG > ...internalized path=_SEG > ...looked up node, pointer=0000000000000000 > [PCI0._SEG] was not found > in acpi_ns_evaluate_relative to execute PCI0, method _BBN > ...internalized path=_BBN > ...looked up node, pointer=0000010001de64f0 > ...exiting acpi_ns_evaluate_relative for obj=_BBN > in acpi_ns_evaluate_relative to execute VPR0, method _ADR > ...internalized path=_ADR > ...looked up node, pointer=0000010001ddbaf0 > (in apci_ns_execute_control_method _ADR) > (method aml: 70 c 0 0 6 0 60 70 5c 2f 4 5f 53 42 5f 50 43 49 30 49 53 41 > 5f 43 50 54 50 61 a0 c 93 61 a 1 70 c 0 0 a 0 60 70 60 44 45 56 4e 70 60 5b > 31 a4 60 > > --(function list I sent earlier was here)-- > > > Hayes, Stuart wrote: > > Here is the relevant method, and all of the fields, regions, and > > methods needed to execute it (I think). If this isn't sufficient, > > let me know. The method being run is ...VPR0.D0F0._STA. > > > > This is cut from the output from Phoenix's "ad" program, and it is > > showing both the disassembled code and the AML itself. Sorry about > > the long lines. > > > > Thanks > > Stuart > > > > > > > > > > Moore, Robert wrote: > >> Can you please post your DSDT and give us some idea of which _STA > >> method is executing? > >> > >> I seem to remember that there may be a bit of leftover recursion in > >> the operation region/field handling code, but something looks very > >> odd about the way the ev_pci_config_region_setup function is getting > >> called twice. > >> > >> > >>>> It seems to work with CONFIG_ACPI_DEBUG off. I'm guessing we're > >>>> just > >> squeaking by with that, though. Wouldn't more complex ACPI methods > >> cause the stack usage to go up, causing it to break again? > >> > >> I think this is an odd case (i.e., bug), since the interpreter has > >> been specifically architected to not use recursion -- however, the > >> original version of the interpreter did recurse based on the > >> complexity of the ASL code (when the interpreter was running as an > >> application.) This was removed in all obvious cases, but I do think > >> that there may be a couple that were missed - fields being perhaps > >> one of them. > >> > >> Bob > >> > >> -----Original Message----- > >> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > >> [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of > >> Stuart_Hayes-DYMqY+WieiM@public.gmane.org Sent: Tuesday, March 09, 2004 12:00 PM > >> To: Brown, Len; ak-l3A5Bk7waGM@public.gmane.org > >> Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > >> Subject: RE: [ACPI] stack overflow > >> > >> > >> I am in the process of trying this without CONFIG_ACPI_DEBUG now. > >> > >> I put a little extra debug stuff in utilities/utdebug.c to keep track > >> of all the nested functions, and added the ACPI_FUNCTION_TRACE to > >> some more of the functions, and this is what I get when the stack > >> pointer is lowest (the number by each is the address of the first > >> argument of the acpi_ut_trace(_*) function, which I store along with > >> the function name). This gives a pretty good picture of what's > >> going on with the recursion and the deep nesting of functions. > >> > >> acpi_init 0000010001e0defc > >> acpi_bus_init 0000010001e0deac > >> acpi_initialize_objects 0000010001e0de6c > >> ns_initialize_devices 0000010001e0de1c > >> ns_walk_namespace 0000010001e0dd8c > >> ns_init_one_device 0000010001e0dd2c > >> ut_execute_STA 0000010001e0dccc > >> ut_evaluate_object 0000010001e0dc5c > >> ns_evaluate_relative 0000010001e0db8c > >> ns_evaluate_by_handle 0000010001e0db1c > >> ns_execute_control_method 0000010001e0dacc > >> psx_execute 0000010001e0da5c > >> ps_parse_aml 0000010001e0da0c > >> ps_parse_loop 0000010001e0d8fc > >> ds_exec_end_op 0000010001e0d89c > >> ds_resolve_operands 0000010001e0d85c > >> ex_resolve_to_value 0000010001e0d80c > >> ex_resolve_node_to_value 0000010001e0d7ac > >> ex_read_data_from_field 0000010001e0d71c > >> ex_extract_from_field 0000010001e0d69c > >> ex_field_datum_io 0000010001e0d61c > >> ex_access_region 0000010001e0d5ac > >> ev_address_space_dispatch 0000010001e0d52c > >> ev_pci_config_region_setup 0000010001e0d4ac > >> ut_evaluate_numeric_object 0000010001e0d44c > >> ut_evaluate_object 0000010001e0d3dc > >> ns_evaluate_relative 0000010001e0d30c > >> ns_evaluate_by_handle 0000010001e0d29c > >> ns_execute_control_method 0000010001e0d24c > >> psx_execute 0000010001e0d1dc > >> ps_parse_aml 0000010001e0d18c > >> ps_parse_loop 0000010001e0d07c > >> ds_exec_end_op 0000010001e0d01c > >> ex_resolve_operands 0000010001e0cf9c > >> ex_resolve_to_value 0000010001e0cf4c > >> ex_resolve_node_to_value 0000010001e0ceec > >> ex_read_data_from_field 0000010001e0ce5c > >> ex_extract_from_field 0000010001e0cddc > >> ex_field_datum_io 0000010001e0cd5c > >> ex_access_region 0000010001e0ccec > >> ev_address_space_dispatch 0000010001e0cc6c > >> ev_pci_config_region_setup 0000010001e0cbec > >> acpi_evaluate_integer 0000010001e0caac > >> acpi_evaluate_object 0000010001e0ca2c > >> ns_evaluate_relative 0000010001e0c95c > >> ns_evaluate_by_handle 0000010001e0c8ec > >> ns_execute_control_method 0000010001e0c89c > >> psx_execute 0000010001e0c82c > >> ps_parse_aml 0000010001e0c7dc > >> ps_parse_loop 0000010001e0c6cc > >> ds_exec_end_op 0000010001e0c66c > >> ex_resolve_operands 0000010001e0c5ec > >> ex_resolve_to_value 0000010001e0c59c > >> ex_resolve_node_to_value 0000010001e0c53c > >> ex_read_data_from_field 0000010001e0c4ac > >> ex_extract_from_field 0000010001e0c42c > >> ex_field_datum_io 0000010001e0c3ac > >> ex_access_region 0000010001e0c33c > >> ev_address_space_dispatch 0000010001e0c2bc > >> ex_enter_interpreter 0000010001e0c27c > >> ut_acquire_mutex 0000010001e0c21c > >> os_wait_semaphore 0000010001e0c1cc > >> > >> Thanks > >> Stuart > >> > >> > >> > >> Len Brown wrote: > >>> Stuart, > >>> Does CONFIG_ACPI_DEBUG change the results of your measurements? > >>> > >>> Is it possible to run an i386 kernel on the same system to see if > >>> we've got an x86_64-specific issue? > >>> > >>> There is some run-time stack tracing code in ACPI (see > >>> acpi_gbl_lowest_stack_pointer) but it hasn't been used in a while. > >>> > >>> thanks, > >>> -Len > >>> > >>> On Mon, 2004-03-08 at 13:26, Andi Kleen wrote: > >>>>> Here are some of the reasons I believe the stack is overflowing: > >>>>> > >>>>> I've added some "printk"s to the kernel, and I've found that the > >>>>> stack pointer goes down by ~6K between > >>>>> namespace/nseval.c:acpi_ns_evaluate_relative() and > >>>>> executer/exstore.c:acpi_ex_store(). > >>>> > >>>> The usual way to start is do > >>>> > >>>> objdump -S | grep sub.*rsp > >>>> > >>>> then sort by the biggest stack pigs and fix them one by one (e.g. > >>>> by kmallocing local data instead of allocating it on the stack) > >>>> When afterwards the problem still occurs it is most likely > >>>> recursion or to deep nesting. I have an old 2.4 patch that can > >>>> catch these, but it would need porting to 2.6. > >>>> > >>>> -Andi > >>>> > >>>> > >>>> ------------------------------------------------------- > >>>> This SF.Net email is sponsored by: IBM Linux Tutorials > >>>> Free Linux tutorial presented by Daniel Robbins, President and CEO > >>>> of GenToo technologies. Learn everything from fundamentals to > >>>> system > >>>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > >>>> _______________________________________________ > >>>> Acpi-devel mailing list > >>>> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > >>>> https://lists.sourceforge.net/lists/listinfo/acpi-devel > >> > >> > >> > >> > >> ------------------------------------------------------- > >> This SF.Net email is sponsored by: IBM Linux Tutorials > >> Free Linux tutorial presented by Daniel Robbins, President and CEO of > >> GenToo technologies. Learn everything from fundamentals to system > >> administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=ick > >> _______________________________________________ > >> Acpi-devel mailing list > >> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > >> https://lists.sourceforge.net/lists/listinfo/acpi-devel > ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click