On 2/20/24 16:41, Erhard Furtner wrote:
On Tue, 20 Feb 2024 07:45:18 -0800
Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
Would it be possible to run the stack trace through scripts/decode/stacktrace.sh ?
I am having trouble associating the backtrace with the actual source.
Also, did you by any chance try the same configuration on the same system with
a pre-6.8 kernel ? The source code locations I did find (unless they are completely
off) point to code that wasn't changed on after v6.7, so it would help to understand
if this is a new problem or one that is exposed by your board.
Hi Günter!
I tried v6.6 just now and got the issue there too.
Thanks for confirming. That makes more sense. Yu should actually see the problem
all the way back to (at least) v5.15.y.
./scripts/decode_stacktrace.sh /boot/vmlinuz-6.8.0-rc5-Zen3 < ~ef/dmesg_68-rc5_zen3_v01
The log is again from 6.8, though.
Anyway,
gives me:
[...]
nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
BTRFS info (device nvme0n1p7: state M): use lzo compression, level 0
loop: module loaded
==================================================================
BUG: KASAN: global-out-of-bounds in nct6775_probe+0x5654/0x6fe9 nct6775_core
This would be the important location. To get that, you would have to provide the
modules directory as second parameter to decode_stacktrace.
After compiling a kernel with your configuration, it does point me to a line
in the source code (drivers/hwmon/nct6775-core.c:4207).
data->reg_temp_config[src - 1] = reg_temp_config[i];
The range of "i" is 0..11, and the size of the reg_temp_config[] array is 2. Oops.
I'll work on a fix.
Thanks,
Guenter
