Oops when returning from hibernation with changed thunderbolt status

Oops when returning from hibernation with changed thunderbolt status

[Michael Guntsche]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

Hello,

I started seeing this issue with kernel v6.15, it worked fine up to 6.14.
If my notebook went into hibernation with the docking station plugged
in and I then started it up again with the docking station unplugged
it would panic. Some times but not always it would also panic if the
dock was still connected.
With a lot of support from Mika (thanks again) I tried to debug this
issue for weeks but was not able to get any meaningful debug output.
Now finally with 6.18rc6 and freeze_filesystems set to 1 I managed to
get at least "something" showing up on my screen with a backtrace.

Hibernating and waking up again works fine with no thunderbolt device connected.

The device in question is a
Lenovo ThinkPad X1 Carbon Gen 11 with a 13th Gen Intel® Core™ i7-1355U

Please tell me if you require more information or want me to try
something different.

Kind regards,
Michael Guntsche

[-- Attachment #2: IMG_20251119_180658.jpg --]
[-- Type: image/jpeg, Size: 3367878 bytes --]

Re: Oops when returning from hibernation with changed thunderbolt status

[Mika Westerberg]

Hi,

On Wed, Nov 19, 2025 at 06:43:16PM +0100, Michael Guntsche wrote:
> Hello,
> 
> I started seeing this issue with kernel v6.15, it worked fine up to 6.14.
> If my notebook went into hibernation with the docking station plugged
> in and I then started it up again with the docking station unplugged
> it would panic. Some times but not always it would also panic if the
> dock was still connected.
> With a lot of support from Mika (thanks again) I tried to debug this
> issue for weeks but was not able to get any meaningful debug output.
> Now finally with 6.18rc6 and freeze_filesystems set to 1 I managed to
> get at least "something" showing up on my screen with a backtrace.
> 
> Hibernating and waking up again works fine with no thunderbolt device connected.
> 
> The device in question is a
> Lenovo ThinkPad X1 Carbon Gen 11 with a 13th Gen Intel® Core™ i7-1355U
> 
> Please tell me if you require more information or want me to try
> something different.

Did you try to disable RTC_DRV_EFI? At least from the backtrace that's
where it crashes.

Also I think I asked you to check with the distro kernel because I remember
that you did some changes to get the crashdump working (please correct me
if I'm wrong) so this could be related to that. For instance it is jumping
to the crash kernel (through kexec) and tries to run EFI services related
to RTC but they are not there anymore due to kexec.

Re: Oops when returning from hibernation with changed thunderbolt status

[Michael Guntsche]

On Thu, Nov 20, 2025 at 6:57 AM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
>
> Hi,
>
> On Wed, Nov 19, 2025 at 06:43:16PM +0100, Michael Guntsche wrote:
> > Hello,
> >
> > I started seeing this issue with kernel v6.15, it worked fine up to 6.14.
> > If my notebook went into hibernation with the docking station plugged
> > in and I then started it up again with the docking station unplugged
> > it would panic. Some times but not always it would also panic if the
> > dock was still connected.
> > With a lot of support from Mika (thanks again) I tried to debug this
> > issue for weeks but was not able to get any meaningful debug output.
> > Now finally with 6.18rc6 and freeze_filesystems set to 1 I managed to
> > get at least "something" showing up on my screen with a backtrace.
> >
> > Hibernating and waking up again works fine with no thunderbolt device connected.
> >
> > The device in question is a
> > Lenovo ThinkPad X1 Carbon Gen 11 with a 13th Gen Intel® Core™ i7-1355U
> >
> > Please tell me if you require more information or want me to try
> > something different.
>
> Did you try to disable RTC_DRV_EFI? At least from the backtrace that's
> where it crashes.
>
I tried this with all drivers removed also this one.

> Also I think I asked you to check with the distro kernel because I remember
> that you did some changes to get the crashdump working (please correct me
> if I'm wrong) so this could be related to that. For instance it is jumping
> to the crash kernel (through kexec) and tries to run EFI services related
> to RTC but they are not there anymore due to kexec.
The issue is reproducible with the current ubuntu and debian distro
kernels as well. After I tried it with the vendor version I switched
to the rc version to make sure it was not fixed in the meantime.

Re: Oops when returning from hibernation with changed thunderbolt status

[Lukas Wunner]

[cc += linux-efi]

On Thu, Nov 20, 2025 at 06:57:48AM +0100, Mika Westerberg wrote:
> On Wed, Nov 19, 2025 at 06:43:16PM +0100, Michael Guntsche wrote:
> > I started seeing this issue with kernel v6.15, it worked fine up to 6.14.
> > If my notebook went into hibernation with the docking station plugged
> > in and I then started it up again with the docking station unplugged
> > it would panic. Some times but not always it would also panic if the
> > dock was still connected.
> 
> Did you try to disable RTC_DRV_EFI? At least from the backtrace that's
> where it crashes.

The backtrace in the photo doesn't seem to betray what kind of call
was queued up on efi_rts_wq.  It doesn't have to be a set/get time
request.  efi_queue_work() is also called for set/get variable requests
among other things.  I recommend instrumenting __efi_queue_work()
with a call to dump_stack() to see where this is coming from.
Maybe add an msleep(5000) afterwards to allow time to take a picture.

Also the photo shows a UBSAN splat in drm/display/drm_mst_topology.c
220 msec before the oops, maybe it's related?

Thanks,

Lukas

Re: Oops when returning from hibernation with changed thunderbolt status

[Kenneth Crudup]

On 11/22/25 02:42, Lukas Wunner wrote:

> Also the photo shows a UBSAN splat in drm/display/drm_mst_topology.c
> 220 msec before the oops, maybe it's related?

FWIW, this sounds really familiar (resume crashes if I changed TB docks 
between suspend and resume) and was getting an OOPS there I'd bisected to:

Resume OOPS from f6971d7427 ("drm/i915/mst: adapt 
intel_dp_mtp_tu_compute_config() for 128b/132b SST") if MST displays 
disconnected while suspended

... and this was fixed in 732b87a (Fix determining SST/MST mode during 
MTP TU state computation) back in 6.15 (which IIRC, is when your crashes 
started happening).

I wonder if this is related? Maybe reach out to the i915 guys?

-Kenny

-- 
Kenneth R. Crudup / Sr. SW Engineer, Scott County Consulting, Orange 
County CA

Re: Oops when returning from hibernation with changed thunderbolt status

[Michael Guntsche]

[cc +=maarten.lankhorst@linux.intel.com]

On Mon, Nov 24, 2025 at 7:02 PM Kenneth Crudup <kenny@panix.com> wrote:
>
>
>
> On 11/22/25 02:42, Lukas Wunner wrote:
>
> > Also the photo shows a UBSAN splat in drm/display/drm_mst_topology.c
> > 220 msec before the oops, maybe it's related?
>
> FWIW, this sounds really familiar (resume crashes if I changed TB docks
> between suspend and resume) and was getting an OOPS there I'd bisected to:
>
> Resume OOPS from f6971d7427 ("drm/i915/mst: adapt
> intel_dp_mtp_tu_compute_config() for 128b/132b SST") if MST displays
> disconnected while suspended
>
> ... and this was fixed in 732b87a (Fix determining SST/MST mode during
> MTP TU state computation) back in 6.15 (which IIRC, is when your crashes
> started happening).
>
> I wonder if this is related? Maybe reach out to the i915 guys?

I tried this now with 6.18 and got the same issues, now it even fails
for me  if I unplug the dock while hibernating.
The last entry I see is the UBSAN message and an out of bounds index error.

Re: Oops when returning from hibernation with changed thunderbolt status

[Kenneth Crudup]

On 12/1/25 11:09, Michael Guntsche wrote:

>> FWIW, this sounds really familiar (resume crashes if I changed TB docks
>> between suspend and resume) and was getting an OOPS there I'd bisected to:
>>
>> Resume OOPS from f6971d7427 ("drm/i915/mst: adapt
>> intel_dp_mtp_tu_compute_config() for 128b/132b SST") if MST displays
>> disconnected while suspended
>>
>> ... and this was fixed in 732b87a (Fix determining SST/MST mode during
>> MTP TU state computation) back in 6.15 (which IIRC, is when your crashes
>> started happening).
>>
>> I wonder if this is related? Maybe reach out to the i915 guys?
> 
> I tried this now with 6.18 and got the same issues, now it even fails
> for me  if I unplug the dock while hibernating.
> The last entry I see is the UBSAN message and an out of bounds index error.

I guess what I'm wondering is if the fix for me broke things for you ... 
can you revert that change in 6.15.1 and see if things unbreak for you?

-K

-- 
Kenneth R. Crudup / Sr. SW Engineer, Scott County Consulting, Orange 
County CA