On Mon, 30 Nov 2020 08:01:41 +0100, Martin Husemann <mar...@duskware.de> wrote:
> Just netbsd.gdb would be enough to map the address from your backtrace, > the address did not match my local build, could have been either hid > or uid. Finally got a chance to test this again. Still panics with a very up-to-date -current (9.99.77) as follows: [...] [ 1.0000030] acpi0 at mainbus0: Intel ACPICA 20201113 [ 1.0000030] panic: kmem_free(0xffff933ad14b6780, 32) != allocated size 0; overwrote? [ 1.0000030] cpu0: Begin traceback... [ 1.0000030] vpanic() at netbsd:vpanic+0x156 [ 1.0000030] snprintf() at netbsd:snprintf [ 1.0000030] kmem_alloc() at netbsd:kmem_alloc [ 1.0000030] AcpiGetObjectInfo() at netbsd:AcpiGetObjectInfo+0x385 [ 1.0000030] acpi_make_devnode() at netbsd:acpi_make_devnode+0x23 [ 1.0000030] AcpiNsWalkNamespace() at netbsd:AcpiNsWalkNamespace+0xf4 [ 1.0000030] AcpiWalkNamespace() at netbsd:AcpiWalkNamespace+0xc2 [ 1.0000030] acpi_attach() at netbsd:acpi_attach+0x26c [ 1.0000030] config_attach_loc() at netbsd:config_attach_loc+0x17e [ 1.0000030] amd64_mainbus_attach() at netbsd:amd64_mainbus_attach+0x1b0 [ 1.0000030] mainbus_attach() at netbsd:mainbus_attach+0x84 [ 1.0000030] config_attach_loc() at netbsd:config_attach_loc+0x17e [ 1.0000030] cpu_configure() at netbsd:cpu_configure+0x38 [ 1.0000030] main() at netbsd:main+0x32c [ 1.0000030] cpu0: End traceback... [ 1.0000030] fatal breakpoint trap in supervisor mode [ 1.0000030] trap type 1 code 0 rip 0xffffffff80221a35 cs 0x8 rflags 0x202 cr2 0 ilevel 0x8 rsp 0xffffffff81d8da80 [ 1.0000030] curlwp 0xffffffff81886d80 pid 0.0 lowest kstack 0xffffffff81d882c0 Stopped in pid 0.0 (system) at netbsd:breakpoint+0x5: leave breakpoint() at netbsd:breakpoint+0x5 vpanic() at netbsd:vpanic+0x156 snprintf() at netbsd:snprintf kmem_alloc() at netbsd:kmem_alloc AcpiGetObjectInfo() at netbsd:AcpiGetObjectInfo+0x385 acpi_make_devnode() at netbsd:acpi_make_devnode+0x23 AcpiNsWalkNamespace() at netbsd:AcpiNsWalkNamespace+0xf4 AcpiWalkNamespace() at netbsd:AcpiWalkNamespace+0xc2 acpi_attach() at netbsd:acpi_attach+0x26c config_attach_loc() at netbsd:config_attach_loc+0x17e amd64_mainbus_attach() at netbsd:amd64_mainbus_attach+0x1b0 mainbus_attach() at netbsd:mainbus_attach+0x84 config_attach_loc() at netbsd:config_attach_loc+0x17e cpu_configure() at netbsd:cpu_configure+0x38 main() at netbsd:main+0x32c ds da90 es da40 fs da80 gs 10 rdi 8 rsi 2f8 rbp ffffffff81d8da80 rbx ffffffff81d8dbc8 rdx 1 rcx 8 rax 1 r8 ffffffff81d8dbc8 r9 1e r10 1 r11 fffffffe r12 104 r13 ffffffff8144d240 r14 ffffffff81d8dac8 r15 ffff93389c823a85 rip ffffffff80221a35 breakpoint+0x5 cs 8 rflags 202 rsp ffffffff81d8da80 ss 10 netbsd:breakpoint+0x5: leave It's too early for dumpdev to be configured, so 'sync' from ddb just prompts to reboot. Looking at AcpiGetObjectInfo+0x385 in "netbsd.gdb" shows: (gdb) list *AcpiGetObjectInfo+0x385 0xffffffff809681a6 is in AcpiGetObjectInfo (/x/current/src/sys/external/bsd/acpica/dist/namespace/nsxfname.c:528). 523 Cleanup: 524 if (Hid) 525 { 526 ACPI_FREE (Hid); 527 } 528 if (Uid) 529 { 530 ACPI_FREE (Uid); 531 } 532 if (CidList) so something's up with "Uid" on this host? At least three other amd64 systems (intel boards DG41TY, D945GCL, D946GZIS) have no problems with the new ACPI. So far, only this Dell Optiplex 760. In case it matters, the Optiplex760 has 12GB ram whereas the others have 8GB, 4GB, and 4GB, respectively. There are a couple of other machines I can check without much trouble. So far, the i386 systems I've booted (IBM 817234U (ThinkCentre S51), and Dell Optiplex GX110) also have no problem with the new ACPI. These systems have 2GB and 512MB RAM, respectively. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSD FreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645