On Mon, 30 Nov 2020 08:01:41 +0100, Martin Husemann
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.030] acpi0 at mainbus0: Intel ACPICA 20201113
[ 1.030] panic: kmem_free(0x933ad14b6780, 32) != allocated size 0;
overwrote?
[ 1.030] cpu0: Begin traceback...
[ 1.030] vpanic() at netbsd:vpanic+0x156
[ 1.030] snprintf() at netbsd:snprintf
[ 1.030] kmem_alloc() at netbsd:kmem_alloc
[ 1.030] AcpiGetObjectInfo() at netbsd:AcpiGetObjectInfo+0x385
[ 1.030] acpi_make_devnode() at netbsd:acpi_make_devnode+0x23
[ 1.030] AcpiNsWalkNamespace() at netbsd:AcpiNsWalkNamespace+0xf4
[ 1.030] AcpiWalkNamespace() at netbsd:AcpiWalkNamespace+0xc2
[ 1.030] acpi_attach() at netbsd:acpi_attach+0x26c
[ 1.030] config_attach_loc() at netbsd:config_attach_loc+0x17e
[ 1.030] amd64_mainbus_attach() at netbsd:amd64_mainbus_attach+0x1b0
[ 1.030] mainbus_attach() at netbsd:mainbus_attach+0x84
[ 1.030] config_attach_loc() at netbsd:config_attach_loc+0x17e
[ 1.030] cpu_configure() at netbsd:cpu_configure+0x38
[ 1.030] main() at netbsd:main+0x32c
[ 1.030] cpu0: End traceback...
[ 1.030] fatal breakpoint trap in supervisor mode
[ 1.030] trap type 1 code 0 rip 0x80221a35 cs 0x8 rflags 0x202
cr2 0 ilevel 0x8 rsp 0x81d8da80
[ 1.030] curlwp 0x81886d80 pid 0.0 lowest kstack
0x81d882c0
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 81d8da80
rbx 81d8dbc8
rdx 1
rcx 8
rax 1
r8 81d8dbc8
r9 1e
r10 1
r11 fffe
r12 104
r13 8144d240
r14 81d8dac8
r15 93389c823a85
rip 80221a35breakpoint+0x5
cs 8
rflags 202
rsp 81d8da80
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
0x809681a6 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 OpenBSDFreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
