>> Your kernel is panicking on this line: >> >> /* >> * Does the package look coherent? >> */ >> cnt = obj->Package.Elements[0].Integer.Value; >> > ================================= > > This is weird because as I pointed out, the element ptr is just pointing > an offset of the buffer we passed. If the kernel really panic on this line, > It's centernly not a ACPI CA bug. Whatever ACPI CA does can't change > the address. Does this make sense? > > But I doubt the panic place is really here, can the bug reporter send the > panic stack here? > > Thanks, > -Aubrey
%r13 is actually 0 after line 51: cpu_acpi_cache_cst+0x4b: jne +0x209 <cpu_acpi_cache_cst+0x25a> cpu_acpi_cache_cst+0x51: movq -0x38(%rbp),%r13 cpu_acpi_cache_cst+0x55: movl 0x4(%r13),%ecx cpu_acpi_cache_cst+0x59: cmpl $0x2,%ecx cpu_acpi_cache_cst+0x5c: jb +0x1d0 <cpu_acpi_cache_cst+0x232> cpu_acpi_cache_cst+0x62: movq 0x8(%r13),%r8 cpu_acpi_cache_cst+0x66: movq 0x8(%r8),%r14 Why lines 55 and 62 do not SEGV dereferencing offsets from 0 is a mystery to me. By the time we get to line 66 the value in %r8 is invalid due to the earlier bugus NULL dereferences. Bill
