Random freeze on idle/sleep — ThinkPad T14p 2025, Intel Ultra 9 285H, Arc Pro integrated GPU

Hello everyone,

I bought a ThinkPad T14p (2025) with an Intel Ultra 9 285H. It has only integrated Intel Arc Pro graphics. I am experiencing random freezes when the laptop is left idle or goes to sleep. The screen goes black, the power button indicator stays on, but the system stops responding to keyboard and mouse. The only way to recover is a long press on the power button.

System info:

  • Laptop: ThinkPad T14p 2025
  • CPU: Intel Ultra 9 285H (Arrow Lake-P)
  • GPU: Intel Arc Pro 140T (integrated only)
  • OS: Fedora 43 KDE
  • Kernel: 6.19.8

What I have tested:

  • Windows 11 (dual boot): No issues at all
  • Ubuntu LTS: Same freeze, happens frequently
  • Linux Mint: Mostly stable
  • Fedora 43: Same random freeze as Ubuntu

I updated all firmware and BIOS to the latest version, but it still randomly happens.

Is this a known issue with Arrow Lake + Linux power management?
Is it related to Wayland, the xe/i915 driver, or deep C-state transitions?

Thank you for your time.

I suspect it is a kernel issue, or your hardware.
It has to be something that Ubuntu LTS and Fedora 43 have in common.
What Kernel is Ubuntu LTS on?

As far as I remember, on Ubuntu 24.04 LTS, I was running kernel 6.17. The freezing happened in two scenarios: at the login screen (gray screen, cursor turning into a cross), and when the laptop was left idle and went to sleep. It never happened during active use: no lag, no hangs, nothing.

I tried checking the kernel logs after a freeze, but no errors were recorded. The system likely froze before it had a chance to write anything.

Now I have Fedora 43 KDE with kernel 6.19.8 , it never froze when I was login into system. I am not sure if it is an hardware issue, cause it never freeze during loads and normal usage.
About 6 months ago I sent the laptop to customer service to check for a hardware issue. Since the problem only occurred on Linux and Windows had no issues, they concluded it was fine and returned it without fixing anything.

here is my laptop specs:

System:
  Kernel: 6.19.8-200.fc43.x86_64 arch: x86_64 bits: 64
    compiler: gcc v: 15.2.1
  Desktop: KDE Plasma v: 6.6.2 Distro: Fedora Linux
    43 (KDE Plasma Desktop Edition)
Machine:
  Type: Laptop System: LENOVO product: 21RU0000CD
    v: ThinkPad T14p Gen 3 serial: <superuser required>
  Mobo: LENOVO model: 21RU0000CD v: SDK0T76479 WIN
    serial: <superuser required> Firmware: UEFI
    vendor: LENOVO v: R2WET40W (1.22 ) date: 01/08/2026
Battery:
  ID-1: BAT0 charge: 58.4 Wh (79.2%)
    condition: 73.8/75 Wh (98.4%) volts: 12.04 min: 11.61
    model: Sunwoda 5B11M90121 status: not charging
CPU:
  Info: 16-core model: Intel Core Ultra 9 285H bits: 64
    type: MCP arch: Arrow Lake rev: 2 cache: L1: 1.6 MiB
    L2: 28 MiB L3: 24 MiB
  Speed (MHz): avg: 400 min/max: 400/5400:4500:2500
    cores: 1: 400 2: 400 3: 400 4: 400 5: 400 6: 400
    7: 400 8: 400 9: 400 10: 400 11: 400 12: 400
    13: 400 14: 400 15: 400 16: 400 bogomips: 117964
  Flags-basic: avx avx2 ht lm nx pae sse sse2 sse3
    sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: Intel Arrow Lake-P [Arc Pro 130T/140T]
    vendor: Lenovo driver: xe v: kernel arch: Xe2-LPG
    bus-ID: 00:02.0
  Device-2: Bison Integrated RGB Camera
    driver: uvcvideo type: USB bus-ID: 3-4:3
  Display: wayland server: Xwayland v: 24.1.9
    compositor: kwin_wayland driver: gpu: xe resolution:
    1: 2560x1440~75Hz 2: 3072x1920~120Hz
  API: EGL v: 1.5 drivers: iris,swrast platforms:
    active: gbm,wayland,x11,surfaceless,device
    inactive: N/A
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa
    v: 25.3.6 glx-v: 1.4 direct-render: yes renderer: Mesa
    Intel Graphics (ARL)
  API: Vulkan v: 1.4.341 drivers: intel,llvmpipe
    surfaces: N/A devices: 2
  Info: Tools: api: clinfo, eglinfo, glxinfo,
    vulkaninfo de: kscreen-console,kscreen-doctor
    gpu: gputop, intel_gpu_top, lsgpu wl: wayland-info
    x11: xdriinfo, xdpyinfo, xprop, xrandr
Audio:
  Device-1: Intel Arrow Lake cAVS vendor: Lenovo
    driver: sof-audio-pci-intel-mtl bus-ID: 00:1f.3
  API: ALSA v: k6.19.8-200.fc43.x86_64
    status: kernel-api
  Server-1: PipeWire v: 1.4.10 status: active
Network:
  Device-1: Intel Arrow Lake CNVi WiFi driver: iwlwifi
    v: kernel bus-ID: 00:14.3
  IF: wlp0s20f3 state: up mac: <filter>
  Device-2: Intel Ethernet I219-V vendor: Lenovo
    driver: e1000e v: kernel port: N/A bus-ID: 00:1f.6
  IF: enp0s31f6 state: down mac: <filter>
  Device-3: ASIX AX88179 Gigabit Ethernet
    driver: cdc_ncm type: USB bus-ID: 2-1.2:4
  IF: enp0s13f0u1u2c2 state: down mac: <filter>
  IF-ID-1: tailscale0 state: unknown speed: -1
    duplex: full mac: N/A
Bluetooth:
  Device-1: Intel driver: btusb v: 0.8 type: USB
    bus-ID: 3-10:5
  Report: btmgmt ID: hci0 rfk-id: 1 state: up
    address: <filter> bt-v: 5.4 lmp-v: 13
Drives:
  Local Storage: total: 3.66 TiB used: 1.84 TiB (50.3%)
  ID-1: /dev/nvme0n1 vendor: Lenovo
    model: UMIS RPJYJ1T24MML1AWQ size: 953.87 GiB
    temp: 34.9 C
  ID-2: /dev/nvme1n1 vendor: Samsung
    model: SSD 990 PRO 1TB size: 931.51 GiB temp: 35.9 C
  ID-3: /dev/sda vendor: Western Digital
    model: WD BLACK SN770 2TB size: 1.82 TiB type: USB
Partition:
  ID-1: / size: 878.27 GiB used: 53.62 GiB (6.1%)
    fs: ext4 dev: /dev/nvme1n1p4
  ID-2: /boot size: 2.74 GiB used: 655.5 MiB (23.3%)
    fs: ext4 dev: /dev/nvme1n1p1
  ID-3: /boot/efi size: 2.86 GiB
    used: 56.1 MiB (1.9%) fs: vfat dev: /dev/nvme1n1p2
Swap:
  ID-1: swap-1 type: zram size: 8 GiB
    used: 12 KiB (0.0%) dev: /dev/zram0
  ID-2: swap-2 type: partition size: 32.42 GiB
    used: 0 KiB (0.0%) dev: /dev/nvme1n1p3
Sensors:
  System Temperatures: cpu: 57.0 C mobo: 41.2 C
  Fan Speeds (rpm): fan-1: 0 fan-2: 0
Info:
  Memory: total: 32 GiB note: est. available: 30.82 GiB
    used: 9.58 GiB (31.1%)
  Processes: 622 Uptime: 3h 21m Init: systemd

Hello,

I just purchased ASUS NUC 15 Pro+ with Intel Core Ultra 9 285H and Crucial SO-DIMM 96GB KIT DDR5 5600 and I am experiencing the same issues. On stable Fedora 43 at the moment, the default kernel. I have pretty much normal installation but I have 64GB memory reserved for huge pages, just to be clear on my setup. Also, I am on the latest firmware (0029) and I have not enabled any non-standard things in EFI firmware.

A side note: The system was unstable when under load (overheating) and it turns out the OS overrides EFI setting of power management. Although I set the fan to be in Performance mode, it falls back to Standard after Fedora boots and this led to overheating. This helped:

echo performance > /sys/firmware/acpi/platform_profile
echo 95 > /sys/devices/system/cpu/intel_pstate/max_perf_pct

Alternatively, instead throttling down maximum performance to 90%, setting Intel RAPL limits also helped me (80W peak, 45W sustained, 25 seconds of budget):

echo 45000000 > /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw
echo 80000000 > /sys/class/powercap/intel-rapl:0/constraint_1_power_limit_uw
echo 25000000 > /sys/class/powercap/intel-rapl:0/constraint_1_time_window_us

Now, to the actual problem of idle freezing - my PC is a home lab server but I was able to connect it to my TV and make a pic of the kernel message. I did not expect it to be able to do soft power off but I tried it expecting it to require full hold but it worked so it was not all dead (but network was down apparently).

I experienced while I was performing stress tests via stress-ng utility and it tend to happen right after the CPU is put under heavy load. Note the debugfs access is restricted which was a fortunate message that caught my eye in logs followed by rcu_preempt self-detected stall on CPU.

[35144.509252] Lockdown: stress-ng: debugfs access is restricted; see man kernel_lockdown.7
[35144.509269] rcu: rcu_preempt self-detected stall on CPU
[35144.509269] rcu: 	12-....: (t=60001 jiffies g=665365 q=85 ncpus=16)
[35144.509269] rcu: rcu: 12-....: (t=60001 jiffies g=665365 q=85 ncpus=16)
[35144.509286] CPU: 12 UID: 0 PID: 760 Comm: systemd-userdbd Not tainted 6.19.0-200.fc43.x86_64 #1 PREEMPT(lazy)
[35144.509290] Hardware name: ASUSTeK COMPUTER INC. NUC15CSKUU9/NUC15CSKUU9, BIOS CPANL579.0029.2026.0115.1719 01/15/2026
[35144.509290] RIP: 0010:smp_call_function_many_cond+0x112/0x560
[35144.509290] Code: [...] of 95 82 d0 d8 63 e3 eb 49 8b ae 40 e1 0d fd 00 00 e8 0f 03 1a 04 80 88 88 08 8f 03 8c ed e0 88 9c 94 8b 41 80 80 81 81 74 09 <f3> 90 0b 41 80 a0 81 75 f7 83 c3 01 eb b3 48 8b 83 40 ea [...]
[35144.509290] RSP: 0018:ffffd18ac643f890 EFLAGS: 00000202
[35144.509302] RAX: 0000000000000001 RBX: [...] RCX: ffffd18ac643fd40
[35144.509302] RDX: 000000000000000a RSI: [...] RDI: 0000000000000003
[35144.509302] RBP: [...] R08: ffff84db403f2728 R09: ffff84db403f2a78
[35144.509302] R10: ffff84db403f2728 R11: 0000000000000000 R12: 0000000000000001
[35144.509302] R13: 0000000000000000 R14: ffff84dcf6824240 R15: ffff84db403f2728
[35144.509305] FS:  00007f7ccade4c00(0000) GS:ffff84dcf6800000(0000) knlGS:0000000000000000
[35144.509306] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[35144.509306] CR2: 00007f08bf558cf0 CR3: 0000000101254002 CR4: 000000000077efef
[35144.509307] PKRU: 55555554
[35144.509308] Call Trace:
[35144.509308]  <TASK>
[35144.509309]  ? on_each_cpu_cond_mask+0x24/0x40
[35144.509311]  ? native_flush_tlb_func_base+0x20/0x20
[35144.509312]  flush_tlb_mm_range+0x15b/0x360
[35144.509317]  dup_mmap+0x3c9/0x720
[35144.509322]  dup_mm_constrop.8+0x6a/0x160
[35144.509322]  copy_process+0xd1b/0x16e0
[35144.509322]  kernel_clone+0x8c/0x4a0
[35144.509322]  ? _do_sys_clone+0x65/0x90
[35144.509322]  __do_sys_clone+0x65/0x90
[35144.509322]  ? queue_delayed_work_on+0x81/0x90
[35144.509322]  ? _seccomp_filter+0x52/0x300
[35144.509322]  ? audit_reset_context+0x298/0x300
[35144.509322]  ? syscall_exit_work+0x143/0x1b0
[35144.509322]  ? do_syscall_64+0xbb/0x1d0
[35144.509322]  ? audit_reset_context+0x298/0x300
[35144.509322]  ? syscall_exit_work+0x143/0x1b0
[35144.509322]  ? do_syscall_64+0xbb/0x1d0
[35144.509322]  ? syscall_exit_work+0x143/0x1b0
[35144.509322]  ? do_syscall_64+0xbb/0x1d0
[35144.509322]  ? audit_reset_context+0x298/0x300
[35144.509322]  ? switch_fpu_return+0x4c/0xc0
[35144.509322]  ? arch_exit_to_user_mode_prepare.isra.0+0xa1/0xc0
[35144.509322]  ? do_syscall_64+0xcb/0x1d0
[35144.509322]  ? exc_page_fault+0x7e/0x1b0
[35144.509367]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[35144.509369] RIP: 0033:0x7f7ccaecc4bd
[35144.509369] Code: 02 00 e8 ab b3 f3 ff f5 41 cb 31 c0 31 d2 31 f6 64 48 8b 04 25 10 00 00 00 b8 df 11 00 29 df 01 4c c4 d8 b2 00 80 18 30 c0 08 d0 8f c5 cb 3d a0 ff ff 77 c4 05 c4 85 d8 f5 31 c1 d1 d8 8b
[35144.509369] RSP: 002b:00007f7ccade4248 EFLAGS: 00000246 ORIG_RAX: 0000000000000038
[35144.509369] RAX: ffffffffffffffda RBX: [...] RCX: 00007f7ccaecc4bd
[35144.509369] RDX: 0000000000000000 RSI: [...] RDI: 0000000000000003
[35144.509369] RBP: 00007f7f74f4dd10 R08: 0000000000000000 R09: 00007f7f74f4ed40
[35144.509369] R10: 00007f7ccade4e80 R11: 0000000000000246 R12: 0000000000000003
[35144.509369] R13: 00007f7f74f4dcc0 R14: 0000000000000003 R15: 0000000000000000
[35144.509369]  </TASK>
[35324.510458] rcu: INFO: rcu_preempt self-detected stall on CPU
[35324.510458] rcu: 	17-....: (t=240003 jiffies g=665365 q=330 ncpus=16)
[35324.510458] rcu: rcu: INFO: rcu_preempt self-detected stall on CPU
[35324.510458] rcu: rcu: 17-....: (t=240003 jiffies g=665365 q=330 ncpus=16)
[35324.510467] CPU: 17 UID: 0 PID: 760 Comm: systemd-userdbd Not tainted 6.19.0-200.fc43.x86_64 #1 PREEMPT(lazy)
[35324.510468] Hardware name: ASUSTeK COMPUTER INC. NUC15CSKUU9/NUC15CSKUU9, BIOS CPANL579.0029.2026.0115.1719 01/15/2026
[35324.510468] RIP: 0010:smp_call_function_many_cond+0x112/0x560
[35324.510468] Code: cf 95 82 80 89 c3 73 30 48 63 eb 49 8b ae 40 e1 0d fd 00 00 ea 0f 03 1a 04 80 80 80 80 8f 03 8c ed e0 88 9c 94 8b 41 80 80 81 81 74 09 <f3> 90 0b 41 80 a0 81 75 f7 83 c3 01 eb b3 48 8b 83 40 ea [...]
[35324.510468] RSP: 0018:ffffd18ac643f890 EFLAGS: 00000202
[35324.510468] RAX: 0000000000000001 RBX: [...] RCX: ffffd18ac643fd40
[35324.510468] RDX: 000000000000000a RSI: [...] RDI: 0000000000000003
[35324.510468] RBP: [...] R08: ffff84db403f2728 R09: ffff84db403f2a78
[35324.510468] R10: ffff84db403f2728 R11: 0000000000000000 R12: 0000000000000001
[35324.510468] R13: 0000000000000000 R14: ffff84dcf6824240 R15: ffff84db403f2728
[35324.510468] FS:  00007f7ccade4c00(0000) GS:ffff8dcdfc8e0000(0000) knlGS:0000000000000000
[35324.510468] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[35324.510468] CR2: 00007f08bf558cf0 CR3: 0000000101254002 CR4: 000000000077efef
[35324.510468] PKRU: 55555554
[35324.510468] Call Trace:
[35324.510468]  <TASK>
[35324.510468]  ? native_flush_tlb_func_base+0x20/0x20
[35324.510468]  ? on_each_cpu_cond_mask+0x24/0x40
[35324.510468]  flush_tlb_mm_range+0x15b/0x360
[35324.510468]  dup_mmap+0x3c9/0x720
[35324.510468]  dup_mm_constrop.8+0x6a/0x160
[35324.510468]  copy_process+0xd1b/0x16e0
[35324.510468]  kernel_clone+0x8c/0x4a0
[35324.510468]  ? _do_sys_clone+0x65/0x90
[35324.510468]  __do_sys_clone+0x65/0x90
[35324.510468]  ? queue_delayed_work_on+0x81/0x90
[35324.510468]  ? _seccomp_filter+0x52/0x300
[35324.510468]  ? audit_reset_context+0x298/0x300
[35324.510468]  ? syscall_exit_work+0x143/0x1b0
[35324.510468]  ? do_syscall_64+0xbb/0x1d0
[35324.510468]  ? do_syscall_64+0xbb/0x1d0
[35324.510468]  ? syscall_exit_work+0x143/0x1b0
[35324.510468]  ? do_syscall_64+0xbb/0x1d0
[35324.510468]  ? audit_reset_context+0x298/0x300
[35324.510468]  ? switch_fpu_return+0x4c/0xc0
[35324.510468]  ? arch_exit_to_user_mode_prepare.isra.0+0xa1/0xc0
[35324.510468]  ? do_syscall_64+0xcb/0x1d0
[35324.510468]  ? exc_page_fault+0x7e/0x1b0
[35324.510567]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[35324.510569] RIP: 0033:0x7f7ccaecc4bd
[35324.510569] Code: 02 00 e8 b3 f3 ff f5 41 cb 31 c0 31 d2 31 f6 64 48 8b 04 25 10 00 00 00 b8 df 11 00 29 df 01 4c c4 d8 b2 00 80 18 30 c0 08 d0 8f c5 cb 3d a0 ff ff 77 c4 05 c4 85 d8 f5 31 c1 d1 d8 8b
[35324.510569] RSP: 002b:00007f7ccade4248 EFLAGS: 00000246 ORIG_RAX: 0000000000000038
[35324.510569] RAX: ffffffffffffffda RBX: [...] RCX: 00007f7ccaecc4bd
[35324.510569] RDX: 0000000000000000 RSI: [...] RDI: 0000000000000003
[35324.510569] RBP: 00007f7f74f4dd10 R08: 0000000000000000 R09: 00007f7f74f4ed40
[35324.510569] R10: 00007f7ccade4c00 R11: 0000000000000246 R12: 0000000000000003
[35324.510569] R13: 00007f7f74f4dcc0 R14: 0000000000000003 R15: 0000000000000000
[35324.510569]  </TASK>
[43766.355728] EXT4-fs (dm-11): INFO: recovery required on readonly filesystem
[43766.355744] EXT4-fs (dm-11): write access will be enabled during recovery
[43766.372814] EXT4-fs (dm-11): orphan cleanup on readonly fs
[43766.373878] EXT4-fs (dm-11): recovery complete
[43766.375849] EXT4-fs (dm-11): mounted filesystem xxx ro with ordered data mode. Quota mode: none.
[43771.712584] EXT4-fs (dm-11): unmounting filesystem xxx.

I am currently trying to reproduce to confirm this behavior so I can start playing around with different kernels, microcode or kernel command line options. Here is such script:

#!/bin/bash

# Configuration
CPUS=$(nproc)
ON_TIME=5           # Seconds of high load
OFF_TIME=2          # Seconds of complete idle

echo "--------------------------------------------------"
echo " Targets: $CPUS cores | Cycle: ${ON_TIME}s ON / ${OFF_TIME}s OFF"
echo " Press Ctrl+C to stop the madness."
echo "--------------------------------------------------"

trap "echo -e '\nTest stopped by user.'; exit" SIGINT SIGTERM

ITERATION=1
while true; do
    echo -n "[$(date +%H:%M:%S)] Iteration $ITERATION: STRESSING... "
    
    # Fire all cylinders: CPU, Matrix math, and Memory allocation
    # This creates the maximum possible current draw spike
    stress-ng --cpu $CPUS --matrix 1 --malloc 1 --timeout ${ON_TIME}s --quiet
    
    echo -n "IDLE... "
    sleep $OFF_TIME
    
    echo "DONE"
    ITERATION=$((ITERATION + 1))
done

I also looked up the microcode for this CPU and it is the same one as in Fedora 43 stable at the moment (sprint 2026): Intel-Linux-Processor-Microcode-Data-Files/intel-ucode/06-c5-02 at main · intel/Intel-Linux-Processor-Microcode-Data-Files · GitHub so no updates there. Also no BIOS available at this time, I have a one from Jan 2026. My kernel is Linux yuki.internal 6.19.8-200.fc43.x86_64 just for the record.

Edit 1: So far so good, I previously had Huge Pages configured but I removed it and also applied both 95% cap limit and Intel RAPL as above to further stabilize temps since this NUCs lives in my TV cabinet. Temps are below 100C.

Edit 2: Nah, another freeze, this time early morning after all nighter of idling and it happened when I tried to ssh for the first time. So this is definitely an issue with deep sleep states. Adding maximum cstate to 2 or 1 and I keep testing this:

grubby --update-kernel=ALL --args="intel_idle.max_cstate=2"

You can try this too this might help until a new BIOS and a new kernel (or both) are out.

1 Like

Hello,

Thanks for your detailed report.

I have been testing my system for 2 days with no issues, but today I got my first freeze during active use. I was watching YouTube on one monitor while doing light work on the other, and the system suddenly froze with a buzzing sound from the speakers. After rebooting, the kernel left no error messages in the logs, which makes it harder to diagnose.
I have seen several reports on Reddit from users with Intel Ultra series machines experiencing the same behavior.

I will try limiting the maximum C-state as you suggested and report back.

hey, there are several threads on freezes (for ex: Hard Freeze, Usually When Idle. Possibly AMD related - #14 by fdr34j), but it seems that the root cause hasn’t been found yet.

I have Lenovo @ Core 5 255H, with lower TDP than your CPU, but it’s the same generation.

The system is perfectly stable and sustains full day of operation even with many KVM VMs running simultaneously in performance mode (latest Fedora 43 KDE), but frequently hangs (freezes) if i consume local multimedia content in VLC with USB headphones attached, and even more frequently if I watch youtube. A freeze is guaranteed sooner or later, although after latest kernel update yesterday it froze just once.

No multimedia = no freezes.

this is of course very annoying.

Are you on KDE or Gnome?
first of all I’d suggest switching to performance mode, disabling all sleep or power saving for your NVMe drives and see if anything changes.

I am on Fedora 43 KDE, but I had the same freezes on GNOME, and earlier on Ubuntu as well.
I have now disabled all sleep and power saving and will monitor. Will report back.

double check that you have disabled NVMe sleep indeed, as it may require extra efforts in terminal.

I can report that my system has been very stable for last 40 hours with the following kernel command line: intel_idle.max_cstate=4 pcie_aspm=off

I do Fedora/RH development on it over day time and it idles overnight. Package temps are below 100C and package power draw is reported around 2-3 W when idle which is okay. I will continue testing on cstate 4 and if I encounter a freeze, I will have to go higher (and let it draw more power).

What I think may helped is PCIE ASPM because I experienced the freezes when CPU was either busy or idle and I made some network traffic. My network chip is I226-V which is still fairly new (2022).

I will report back soon.

Did not help, removed all kernel command line options and trying kernel from Rawhide, at the moment Linux 7.0.0-0.rc5.43.fc45.x86_64.

I also disabled the following in ASUS BIOS firmware:

  • Power Sense
  • Dynamic PL1
  • Dynamic PL4
  • PCIe ASPM

Has been stable for a week now, not sure if new kernel or BIOS settings helped.

Update: I tried intel_idle.max_cstate=2 and my laptop has been stable for about a week on kernel 6.13.9-200.fc43.x86_64. Will keep testing and report back if any freeze happens.