KDL booting hrev49947 x86_gcc2

[kim1963]

Welcome to Kernel Debugging Land...
Thread 18 "main2" running on CPU 2
stack trace for thread 18 "main2"
    kernel stack: 0x81c2f000 to 0x81c33000
frame               caller     <image>:function + offset
 0 81c326d4 (+  32) 80148712   <kernel_x86> arch_debug_stack_trace() + 0x12
 1 81c326f4 (+  16) 800a7ef7   <kernel_x86> stack_trace_trampoline__FPv() + 0x0b
 2 81c32704 (+  12) 8013a49e   <kernel_x86> arch_debug_call_with_fault_handler() + 0x1b
 3 81c32710 (+  48) 800a9a1a   <kernel_x86> debug_call_with_fault_handler() + 0x5a
 4 81c32740 (+  64) 800a8113   <kernel_x86> kernel_debugger_loop__FPCcT0Pcl() + 0x217
 5 81c32780 (+  48) 800a848f   <kernel_x86> kernel_debugger_internal__FPCcT0Pcl() + 0x53
 6 81c327b0 (+  48) 800a9da6   <kernel_x86> panic() + 0x3a
 7 81c327e0 (+ 144) 8011ef7d   <kernel_x86> vm_page_fault() + 0x145
 8 81c32870 (+  80) 80149f43   <kernel_x86> x86_page_fault_exception() + 0x177
 9 81c328c0 (+  12) 8013ce5c   <kernel_x86> int_bottom() + 0x3c
kernel iframe at 0x81c328cc (end = 0x81c3291c)
 eax 0x8189b720    ebx 0x81899f6c     ecx 0x82a9a500  edx 0x73
 esi 0x656d5f6c    edi 0xa            ebp 0x81c32944  esp 0x81c32900
 eip 0x8186d9ad eflags 0x10206   
 vector: 0xe, error code: 0x0
10 81c328cc (+ 120) 8186d9ad   <acpi> AcpiNsBuildNormalizedPath() + 0x51
11 81c32944 (+  64) 8186d908   <acpi> AcpiNsHandleToPathname() + 0x44
12 81c32984 (+  48) 81870445   <acpi> AcpiGetName() + 0x65
13 81c329b4 (+  64) 81867033   <acpi> get_next_entry() + 0x9b
14 81c329f4 (+ 544) 818679f7   <acpi> acpi_enumerate_child_devices__FP11device_nodePCc() + 0x237
15 81c32c14 (+ 144) 81867b17   <acpi> acpi_module_register_child_devices__FPv() + 0x103
16 81c32ca4 (+  48) 800bc14d   <kernel_x86> Register__11device_nodeP11device_node() + 0x8d
17 81c32cd4 (+  64) 800baa62   <kernel_x86> register_node__FP11device_nodePCcPC11device_attrPC11io_resourcePP11device_node() + 0xfe
18 81c32d14 (+ 112) 818677b5   <acpi> acpi_module_register_device__FP11device_node() + 0x49
19 81c32d84 (+  64) 800bc8a9   <kernel_x86> _RegisterPath__11device_nodePCc() + 0x4d
20 81c32dc4 (+  96) 800bca9f   <kernel_x86> _RegisterDynamic__11device_nodeP11device_node() + 0x147
21 81c32e24 (+  48) 800bc177   <kernel_x86> Register__11device_nodeP11device_node() + 0xb7
22 81c32e54 (+  64) 800baa62   <kernel_x86> register_node__FP11device_nodePCcPC11device_attrPC11io_resourcePP11device_node() + 0xfe
23 81c32e94 (+ 192) 800bd519   <kernel_x86> init_node_tree__Fv() + 0x41
24 81c32f54 (+  16) 800bd6f1   <kernel_x86> device_manager_init() + 0xfd
25 81c32f64 (+  80) 80066942   <kernel_x86> main2__FPv() + 0x76
26 81c32fb4 (+  48) 80087563   <kernel_x86> common_thread_entry__FPv() + 0x3b
kdebug> 

[waddlesplash]

Not exactly sure what's going on here. All the functions here look normal; I guess I should look at the diffs to see what changed...

[waddlesplash]

Can you retry with x86_gcc4 (hybrid OK, if you want), and see if the same thing happens? Thanks.

[jua]

Same here, since upgrading it crashes with same KDL as above during boot.

I propose we revert the recent ACPI code update and go back to the version previously used (which is, as pointed out by korli, also the one used by FreeBSD).

[rudolfc]

Hi,

A shame we have trouble with this version :-/ Anyhow, if we revert to the previous version, I would strongly suggest adding one patch to it being:

​https://github.com/acpica/acpica/commit/a3267967c8bd3938e9aa98e8a267315cd609c477#diff-6c6887495e1022722758f5a9104b668d

This patch fixes ACPI not working on older systems (i.e. my laptop.. :-)

Bye!

Rudolf

[HAL]

I have the same kdl booting hrev49950 in x86_64 and x86_gcc2.

[HAL]

Replying to waddlesplash:

Can you retry with x86_gcc4 (hybrid OK, if you want), and see if the same thing happens? Thanks.

I tried with hrev49948 x86_gcc4 hybrid and got a very similar kdl at boot.

[waddlesplash]

Can you upload a syslog from a successful boot (on an earlier rev)? Thanks. EDIT: Scratch that, don't need it.

[HAL]

syslog successful boot of hrev49944 x86_gcc4 hybrid

[HAL]

Replying to waddlesplash:

Can you upload a syslog from a successful boot (on an earlier rev)? Thanks. EDIT: Scratch that, don't need it.

I did that before seeing your edit.

[waddlesplash]

Can you try again with hrev49953 or later?

[kim1963]

hrev49956 - KDL booting

[waddlesplash]

A friend of mine who knows more about assembly than I do actually spent some time looking at this. Here's what he sent me:

Here is what I discovered to be true, looking at the backtrace and the disassembly:

1. In AcpiNsBuildNormalizedPath() %esi is used for the variable NextNode.

2. In the stack trace %esi=0x656d5f6c looks suspiciously like it is a pointer loaded after a buffer overrun. The ascii would be 'l_me'

3. It is unlikely that the parameter, Node, is bad, because the caller used a handle validate routine.

4. When walking the tree, NextNode is loaded from each .Parent in turn. This means that one of the .Parents is bad.

5. %edi is used for the variable Length. At the time of the stack trace, it is 0xa. I think that means that it walked up at least two nodes before it hit the bad one.

6. Inserting a little debugging code right there might help provide a clue to track down the problem. if (NextNode==0x656d5f6c), then you want to dump what is at FullPath so far, and then panic. Better yet, start at Node, and walk forward, dumping each block [Node,sizeof(*Node)].

[waddlesplash]

Reverted in hrev49963.

[tqh]

This was a bug in ACPICA, I could reproduce the problem on my laptop with a tree from before it was reverted. ACPICA has since released a bug fixed version, and upgrading to that version made it go away:

Fixed a regression introduced in version 20151218 concerning the 
execution of so-called module-level ASL/AML code. Namespace objects 
created under a module-level If() construct were not properly/fully 
entered into the namespace and could cause an interpreter fault when 
accessed.

So do you want to re-revert? :) Your changes looks good, just got unlucky (and maybe wait a month or two after a release is out next time).

​https://acpica.org/sites/acpica/files/changes_29.txt