On 2022-07-08 12:13 p.m., Vince Weaver wrote:
On Wed, 6 Jul 2022, Vince Weaver wrote:
Let the fuzzer running a long time on 5.19-rc1 and after a few weeks it
triggered this weird trace. It is repeatable (although I haven't
narrowed down exactly what's causing it).
It's odd in that it just dumps a <TASK>, it doesn't provide any info on
what the actual trigger is.
This is on a Haswell machine.
I bumped up to current git and managed to trigger this again, this time
it actually managed to print the error message.
[ 7763.384369] unchecked MSR access error: WRMSR to 0x689 (tried to write 0x1fffffff8101349e) at rIP: 0xffffffff810704a4 (native_write_msr+0x4/0x20)
The 0x689 is a valid LBR register, which is MSR_LASTBRANCH_9_FROM_IP.
The issue should be caused by the known TSX bug, which is mentioned in
the commit 9fc9ddd61e0 ("perf/x86/intel: Fix MSR_LAST_BRANCH_FROM_x bug
when no TSX"). It looks like the TSX support has been deactivated,
however the quirk in the commit isn't applied for some reason.
To apply the quirk, perf relies on the boot CPU's flag and LBR format.
static inline bool lbr_from_signext_quirk_needed(void)
bool tsx_support = boot_cpu_has(X86_FEATURE_HLE) ||
return !tsx_support && x86_pmu.lbr_has_tsx;
Could you please share the value of the PERF_CAPABILITIES MSR 0x00000345
of the machine?
I'd like to double check whether the LBR fromat is correct. 0x5 is expected.
If the LBR format is correct, maybe the boot CPU's flag is not cleared
when the TSX support is deactivated.
I noticed that Pawan recently had several TSX patches merged which may
impact the flags.
400331f8ffa3 ("x86/tsx: Disable TSX development mode at boot")
258f3b8c3210 ("x86/tsx: Use MSR_TSX_CTRL to clear CPUID bits")
If you only observe the issue with the latest kernel, you may want to
revert the above two patches and see if it helps.