[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <35086bb6-ee11-4ac6-b8ba-5fab20065b54@intel.com>
Date: Fri, 17 May 2024 10:22:32 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Kalle Valo <kvalo@...nel.org>, Borislav Petkov <bp@...en8.de>
Cc: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"Rafael J. Wysocki" <rafael@...nel.org>, x86@...nel.org,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
regressions@...ts.linux.dev, Jeff Johnson <quic_jjohnson@...cinc.com>
Subject: Re: [regression] suspend stress test stalls within 30 minutes
On 5/17/24 10:15, Kalle Valo wrote:
> Borislav Petkov <bp@...en8.de> writes:
>> There might be some #GP or so in the logs in case we've managed to f*ck
>> up microcode application which emulates that IBRS MSR bit and the
>> actual toggling or so when suspending...
> So the weird part is that when the bug happens (ie. suspend stalls) I
> can access the box normally using ssh and I don't see anything special
> in dmesg. Below is a full copy of dmesg output after the suspend
> stalled. Do note that I copied this dmesg before I updated microcode so
> it will still show the old microcode version.
>
> Let me know if you need more info.
Kalle, could you remind us what we're seeing here? Does this show 30
working rtcwake tests followed by a failure at "rtcwake test 31" where
the system failed to suspend?
Powered by blists - more mailing lists