Nvidia driver on Ubuntu 24.04.04 LTS with AMD threadripper 3995WX + Nvidia RTX 3080 Ti fails and gdm-x-session deletes GPU-0

Graphics / Linux Linux
1

nvidia driver on Ubuntu 24.04.04 LTS with AMD threadripper 3995WX + Nvidia RTX 3080 Ti appears to fail in such a way that gdm-x-session deletes the GPU-0

The screen goes blank but the machine is still reachable via ssh. Running nvidia-bug-report.sh and the log is attached.

The faster way to replicate is to run OpenAI whisper with cuda --device.
conda activate whisper
whisper movie.mp4 --device cuda --language English --model turbo --task transcribe -f srt | tee -a subtitles.txt & disown

any movie will do, it won’ t take long for the error to manifest itself.

However it happens as well randomly after hours of usage even if I am NOT running any cuda AI acceleration / training nor 3D App like Blender or FreeCAD.
Currently it happens with nvidia-driver-580-open but it also happens all the same with nvidia-driver-570 -580 -590 variants.

$ tail subtitles.txt
[11:58.340 → 11:59.340] Some other time, then?
[11:59.420 → 12:00.340] Sure. Maybe.
[12:01.340 → 12:02.260] Bye, Janice.
[12:02.340 → 12:03.340] See ya.
Skipping “movie”.mp4 due to AcceleratorError: CUDA error: unspecified launch failure
Search for cudaErrorLaunchFailure' in https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__TYPES.html for more information. CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect. For debugging consider passing CUDA_LAUNCH_BLOCKING=1 Compile with TORCH_USE_CUDA_DSA` to enable device-side assertions.

$ nvidia-smi
Unable to determine the device handle for GPU0: 0000:81:00.0: Unknown Error
No devices were found

$ tail -1400 /var/log/syslog | grep -i nvidia
2026-03-11T17:44:27.817991+00:00 WRX80-3995WX gnome-shell[4449]: Added device ‘/dev/dri/card2’ (nvidia-drm) using atomic mode setting.
2026-03-11T17:44:28.765205+00:00 WRX80-3995WX systemd[4181]: Started app-gnome-nvidia\x2dsettings\x2dautostart-4785.scope - Application launched by gnome-session-binary.
2026-03-11T17:44:30.757488+00:00 WRX80-3995WX /usr/libexec/gdm-x-session[3436]: (II) NVIDIA(GPU-0): Deleting GPU-0
2026-03-11T17:48:54.408077+00:00 WRX80-3995WX kernel: NVRM: nvidia-bug-report.sh as root to collect this data before
2026-03-11T17:48:54.408078+00:00 WRX80-3995WX kernel: NVRM: the NVIDIA kernel module is unloaded.
2026-03-11T17:48:56.527650+00:00 WRX80-3995WX kernel: WARNING: CPU: 21 PID: 7962 at nvidia/nv.c:5291 nvidia_dev_put_uuid+0x55/0x60 [nvidia]

$ cat /etc/os-release
PRETTY_NAME=“Ubuntu 24.04.4 LTS”
NAME=“Ubuntu”
VERSION_ID=“24.04”
VERSION=“24.04.4 LTS (Noble Numbat)”
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL=“https://www.ubuntu.com/”
SUPPORT_URL=“https://help.ubuntu.com/”
BUG_REPORT_URL=“https://bugs.launchpad.net/ubuntu/”
PRIVACY_POLICY_URL=“https://www.ubuntu.com/legal/terms-and-policies/privacy-policy”
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

$ uname -a
Linux WRX80-3995WX 6.17.0-14-generic #14~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Jan 15 15:52:10 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

uploading nvidia-bug-report.

Note: I have another machine. Intel CPU and nvidia rtx 3060 ti , also ubuntu 24.04 but in there the kernel is 6.8

$ uname -a
Linux O11Vision 6.8.0-101-generic #101-Ubuntu SMP PREEMPT_DYNAMIC Mon Feb 9 10:15:05 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

and in that machine no issues whatsoever, all fine and good. I still need to find out why the Threadripper machine ubuntu installs 6.17 kernel while in the intel machine only 6.8 if both are ubuntu 24.04 LTS

nvidia-bug-report.log.gz (256.5 KB)

2

From the bug report the GPU is no longer responding on the PCIe bus.

The lspci dump for 0000:81:00.0 shows Unknown header type 7f and the entire configuration space reads 0xFF. When configuration space reads all 0xFF, the device is electrically unreachable on the PCIe bus. This is exactly what happens after Xid 79 (“GPU fallen off the bus”).

NVIDIA documentation describes Xid 79 as the GPU becoming unreachable over PCIe:

So the bug report was captured after the PCIe link had already failed, not before.

There are a couple of things in the report worth investigating.

PCIe link width

The root port (0000:80:01.1) shows:

LnkCap: Width x4
LnkSta: Speed 8GT/s, Width x4

A RTX 3080 Ti normally runs on a x16 PCIe link. If the GPU is installed in a slot electrically limited to x4 lanes, the link has significantly less bandwidth and signal margin.

On WRX80 boards, not every mechanical x16 slot is wired x16. Some slots share lanes with NVMe controllers or chipset paths. It would be worth checking the motherboard manual to confirm which slot provides a full x16 connection directly to the CPU.

ASPM L1 enabled

The root port shows ASPM L1 enabled, and there is no pcie_aspm=off override in the kernel command line.

On some AMD platforms ASPM power states have caused GPU link resume failures. A reasonable diagnostic step is disabling ASPM to see whether the behavior changes.

Example kernel parameters:

pcie_aspm=off pcie_port_pm=off

Linux PCI power-management documentation:

https://www.kernel.org/doc/html/latest/power/pci.html

BIOS check for ASPM

If kernel parameters do not change the behavior, it is also worth verifying that ASPM is disabled at the firmware level.

On many WRX80 and workstation boards this setting is located under:

BIOS
 → Advanced
   → PCIe / PCI Subsystem Settings
     → ASPM Support

or sometimes:

Advanced
 → AMD CBS
   → PCIe Configuration
     → ASPM

Set ASPM Support = Disabled for testing.

Firmware-level ASPM can override or interact with OS power management, so disabling it in BIOS helps ensure the link is not entering low-power states unexpectedly.

Kernel version difference

You mentioned another machine is stable on kernel 6.8, while this system pulled the 6.17 HWE kernel. Testing the older kernel can help determine whether the issue is related to a regression in PCIe or AMD-IOMMU handling.

sudo apt install linux-generic

Then select the 6.8 kernel from the GRUB boot menu.

Optional PCIe link verification

After making changes it can be useful to verify that the PCIe link is negotiating correctly and sustaining normal DMA throughput.

Example diagnostic tool:

https://github.com/parallelArchitect/gpu-pcie-path-validator

It checks negotiated PCIe link state together with host↔device transfer throughput, which can help confirm whether the GPU transport path is stable under load.

Summary

At the time the bug report was captured the GPU’s PCIe configuration space was already inaccessible, meaning the PCIe link had already dropped.

The most useful things to investigate next would be:

  • whether the GPU is installed in a slot electrically limited to x4

  • whether ASPM power management is affecting link stability

  • whether the behavior changes under kernel 6.8

Those checks should help determine whether the issue is related to PCIe topology, firmware power management, or kernel behavior.

3

Well, first of all, thank you very much for such a detailed and comprehensive answer.

I had tried installing kernel 6.8 even before reading these instructions. It happened the same.

@WRX80-3995WX:~/Apps/gpu-pcie-path-validator [base] main
± uname -a
Linux WRX80-3995WX 6.8.0-106-generic #106-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 6 07:58:08 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

I couldn’ t find any reference on the motherboard User Manual not in the BIOS about ASPM.

But nevertheless I apply the suggested parameters into /etc/default/grup and sudo update-grub. And reboot

@WRX80-3995WX:~/Apps/gpu-pcie-path-validator [base] main
± ./gpu_pcie_validator --list-devices

Detected GPUs

Idx BDF NUMA PCIe Link Name

0 0000:81:00.0 0 Gen1 x16 NVIDIA GeForce RTX 3080 Ti

I can see in the dmesg the notification that ASPM is now disabled

@WRX80-3995WX:~/Apps/gpu-pcie-path-validator [base] main
± sudo dmesg | grep -i ASPM
[sudo] …
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.8.0-106-generic root=/dev/mapper/ubuntu–vg-ubuntu–lv ro splash pcie_aspm=off pcie_port_pm=off vt.handoff=7
[ 0.289298] Kernel command line: BOOT_IMAGE=/vmlinuz-6.8.0-106-generic root=/dev/mapper/ubuntu–vg-ubuntu–lv ro splash pcie_aspm=off pcie_port_pm=off vt.handoff=7
[ 0.289355] PCIe ASPM is disabled
[ 2.708566] acpi PNP0A08:00: _OSC: not requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI]
[ 2.731995] acpi PNP0A08:01: _OSC: not requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI]
[ 2.737701] acpi PNP0A08:02: _OSC: not requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI]
[ 2.745791] acpi PNP0A08:03: _OSC: not requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI]
@WRX80-3995WX:~/Apps/gpu-pcie-path-validator [base] main

And the gpu_pcie_validator app says “state healthy”

@WRX80-3995WX:~/Apps/gpu-pcie-path-validator [base] main
± ./gpu_pcie_validator --device 0

GPU PCIe Validator v4.1

GPU Identity

Model : NVIDIA GeForce RTX 3080 Ti
Compute Capability : 8.6
Driver Version : 580.126.20
NVML Version : 13.580.126.20
CUDA Runtime : 12.8
PCI Bus ID (BDF) : 00000000:81:00.0
GPU UUID : GPU-4964b1bb-04db-1ede-5a16-92735d267b8e
NUMA Node : 0

System Environment

Operating System : Ubuntu 24.04.4 LTS
Kernel Version : 6.8.0-106-generic
CPU Architecture : x86_64
CPU Cores (online) : 128
Scheduler Policy : SCHED_OTHER (priority 0)
NUMA Nodes : 1

Run Parameters

Device Index : 0
Memory Mode : pinned
Window Duration : 2000 ms
Sample Interval : 100 ms
Transfer Size : 1024 MiB

PCIe Topology

GPU Device (endpoint) : 0000:81:00.0
Upstream Port : 0000:80:01.1
Root Port : 0000:80:01.1
PCIe Chain (root->endpoint) : 0000:80:01.1 → 0000:81:00.0
Chain Depth : 1

PCIe Link Capability

Maximum Supported : PCIe Gen4 x16
Negotiated (pre-load) : PCIe Gen4 x16
Negotiated (post-load) : PCIe Gen4 x16
Theoretical Max Payload : 31.50 GB/s per direction

Link Changes During Test

Speed Change : None
Width Change : None
Retrain Events : N/A (not exposed by NVML)

GPU Clocks

SM Clock (pre-load) : 210 MHz
SM Clock (post-load) : 2040 MHz
Mem Clock (pre-load) : 405 MHz
Mem Clock (post-load) : 9251 MHz
GR Clock (pre-load) : 210 MHz
GR Clock (post-load) : 2040 MHz
P-State (pre-load) : P8
P-State (post-load) : P2

PCIe Bandwidth Validation (CUDA memcpy)

Host → Device Throughput : 23.94 GB/s
Device → Host Throughput : 22.81 GB/s
Average Throughput : 23.38 GB/s
Utilization Efficiency : 74.2 %

Memcpy Transfer Timing

Host->Device memcpy time (1024 MiB) : 41.8 ms
Device->Host memcpy time (1024 MiB) : 43.8 ms
Average memcpy time (1024 MiB) : 42.8 ms

Host->Device memcpy time (64 KiB) : 3.8 us
Device->Host memcpy time (64 KiB) : 3.2 us
Average memcpy time (64 KiB) : 3.5 us

NVML PCIe Throughput (bus-level)

Host→Device (RX) : 9.12 GB/s
Device→Host (TX) : 10.18 GB/s
Combined (duplex) : 19.30 GB/s
Per-direction average : 9.65 GB/s

Note: Memcpy throughput measures payload transfer rate per direction.
NVML combined traffic measures total bus utilization (duplex).

PCIe Replay Counter

Counter Start : 0
Counter End : 0
Counter Delta : 0

AER Error Counters (PCIe Advanced Error Reporting)

Correctable Errors (total delta) : 0
Non-Fatal Errors (total delta) : 0
Fatal Errors (total delta) : 0

Power Telemetry

Pre-Test Power : 20.7 W
Average Load Power : 125.3 W
Peak Power : 130.0 W
End Power : 130.5 W
Power Delta (pre->end) : 109.8 W

Thermal Telemetry

Temperature (baseline) : 24.0 °C
Temperature (end) : 28.0 °C
Thermal Delta : 4.0 °C

Sampling Integrity

Target Interval : 100 ms
Achieved Interval : 97.2 ms
Target Samples : 20
Achieved Samples : 21
Window Duration : 2041.0 ms

System Signals

Persistence Mode : Enabled
ASPM Policy : auto (runtime PM enabled)
IOMMU : enabled (72 groups)
Max Payload Size : 256 bytes
Max Read Request : 512 bytes
NUMA CPU Affinity : 0-127
NUMA Affinity OK : yes

Final PCIe Assessment

State : HEALTHY

Evidence
Link consistency : TRUE
Replay counter increase : NONE
AER correctable errors : 0
AER fatal errors : 0
Efficiency ratio : 0.742

[log] ./logs/runs/20260319_124858_GPU0/report.txt
[log] ./logs/runs/20260319_124858_GPU0/report.json

@WRX80-3995WX:~/Apps/gpu-pcie-path-validator [base] main
± nvidia-smi
Thu Mar 19 12:50:40 2026
±----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.126.20 Driver Version: 580.126.20 CUDA Version: 13.0 |
±----------------------------------------±-----------------------±---------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce RTX 3080 Ti On | 00000000:81:00.0 On | N/A |
| 0% 24C P8 20W / 370W | 163MiB / 12288MiB | 0% Default |
| | | N/A |
±----------------------------------------±-----------------------±---------------------+

±----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 4703 G /usr/bin/gnome-shell 129MiB |
| 0 N/A N/A 4912 G /usr/bin/Xwayland 4MiB |
±----------------------------------------------------------------------------------------+

So, I am going to give a spin and I will get back to you if the job finishes or if the GPU keeps disconnecting and the job aborting. Please bear with me.

4

I am sorry to report that the same phenomena happens.

I have launched a whisper transcribe job with CUDA device and model “turbo” (quick one) and at ~35 seconds into the job the screen on my TV monitor has disconnected “No signal”.

I can still ssh into my threadripper machine. If I do so

@WRX80-3995WX:~ [base]
$ nvidia-smi
Unable to determine the device handle for GPU0: 0000:81:00.0: Unknown Error
No devices were found

The same thing. The GPU disconnects while on the job

$ tail subtitles.txt
[10:04.880 → 10:05.960] Run, you big doofus!
[10:06.460 → 10:06.960] Run.
[10:07.960 → 10:10.620] Yeah, I told you the Steelers were on fire!
[10:10.960 → 10:11.760] I’m going for a run.
Skipping “movie”.mp4 due to AcceleratorError: CUDA error: unspecified launch failure
Search for `cudaErrorLaunchFailure’ in CUDA Runtime API :: CUDA Toolkit Documentation for more information.
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1
Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

@WRX80-3995WX:~ [base]
$ sudo dmesg | grep -i error
[sudo] password for admanero:
[ 2.951845] ERST: Error Record Serialization Table (ERST) support is initialized.
[ 3.596016] i8042: probe of i8042 failed with error -5
[ 4.144817] RAS: Correctable Errors collector initialized.
[ 3315.188984] NVRM: kgspRcAndNotifyAllChannels_IMPL: RC all channels for critical error 79.
[ 3315.216540] [drm:nv_drm_gem_alloc_nvkms_memory_ioctl [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00008100] Failed to allocate NVKMS memory for GEM object
[ 3315.217092] [drm:nv_drm_gem_alloc_nvkms_memory_ioctl [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00008100] Failed to allocate NVKMS memory for GEM object
[ 3315.217153] [drm:nv_drm_gem_alloc_nvkms_memory_ioctl [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00008100] Failed to allocate NVKMS memory for GEM object
[ 3316.686719] NVRM: nvGpuOpsReportFatalError: uvm encountered global fatal error 0x60, requiring os reboot to recover.
[ 3316.856237] NVRM: nvGpuOpsReportFatalError: uvm encountered global fatal error 0x60, requiring os reboot to recover.
[ 3316.859598] NVRM: nvGpuOpsReportFatalError: uvm encountered global fatal error 0x60, requiring os reboot to recover.

The GPU is placed at the top the closest to the CPU socket. As it happens this is PCI socket 7 not 1. But this is the mighty ThreadRipper PRO 3995WX and according the motherboard User Manual all PCIE slots are connected directly to the CPU. It has 128 pcie gen4 lanes after all.

I am thinking I might have to change PCIE slot. But I have a custom water cooling loop, so … That is going to take a while. But I would like to know why the GPU works fine after rebooting but I am getting this nasty issue when running CUDA acceleration jobs.

$ ~/Apps/gpu-pcie-path-validator/gpu_pcie_validator --list-devices

Detected GPUs

Idx BDF NUMA PCIe Link Name

5

Thanks for running the validator and posting the full output — that gives us a clear baseline.

PCIe path is clean at idle: Gen4 x16, zero replay counters, zero AER errors, ~74% efficiency. ASPM disabled, kernel 6.8 same result as 6.17. That rules out static link degradation, ASPM power management, and kernel-specific regressions.

The crash signature tells us what’s happening:

NVRM: kgspRcAndNotifyAllChannels_IMPL: RC all channels for critical error 79.
NVRM: nvGpuOpsReportFatalError: uvm encountered global fatal error 0x60, requiring os reboot to recover.

Xid 79 indicates the GPU is no longer accessible on the PCIe bus. UVM fatal 0x60 is the driver confirming the device is gone — unrecoverable without reboot. The Deleting GPU-0 from gdm-x-session is the display server reacting to the GPU disappearing, not the cause.

The pattern — stable at idle, crashes ~35 seconds into sustained CUDA load, works again after reboot — points to a load-triggered hardware instability. The baseline validation runs a short-duration controlled transfer; Whisper turbo sustains inference that ramps power, clocks, memory traffic, and thermals well beyond that window. The consistent ~35 second timing suggests something is ramping to a failure threshold.

Here’s a diagnostic sequence ordered by speed and signal value:

1. Power limit cap (no reboot, fastest test)

sudo nvidia-smi -pl 200

This reduces the GPU’s power envelope and, more importantly, its transient current spikes. Even within the allowed power range, momentary current spikes can stress the PSU, PCIe slot, or GPU VRMs under sustained load.

Then rerun the workload. If the crash disappears, that strongly points to a power delivery or electrical margin issue. If it still crashes, move on.

Note: the valid range depends on the card’s VBIOS — check with nvidia-smi -q | grep -i "Power Limit" first to confirm what your card accepts.

2. Better telemetry during the crash

Start this in a separate terminal before running the workload:

nvidia-smi dmon -s pucvmet -d 1

This logs power, temperature, utilization, clocks, memory, and PCIe throughput every second. When the crash happens, the last few lines before the drop will show whether power spiked, temperature ramped, or PCIe throughput surged. Save that output — it’s high-value signal.

3. Sustained load stress test with the validator

Since you already ran the validator, the next useful step is to extend it into a sustained load window. The baseline run is short-duration; your failure appears around ~35 seconds, so we want to push well past that:

./gpu_pcie_validator --device 0 --size-mib 4096 --window-ms 60000 --interval-ms 50

The full set of run modes is documented here: gpu-pcie-path-validator/docs/Usage.md at main · parallelArchitect/gpu-pcie-path-validator · GitHub

This drives continuous large DMA transfers for 60 seconds at high sampling resolution. If this triggers the same Xid 79, that points to a transport-level instability under sustained DMA load. If it completes clean while Whisper still crashes, the failure is likely tied to the combined compute + memory access pattern rather than raw PCIe throughput — in that case, the PCIe path is stable under pure transfer pressure, and the issue shifts toward power, thermals, or workload-specific behavior.

4. Force PCIe Gen3 (requires reboot)

Update your kernel command line in /etc/default/grub:

pcie_aspm=off pcie_port_pm=off pci=pcie_bus_safe,force_gen3

Then sudo update-grub and reboot. Gen4 has tighter signal margins than Gen3. If the crash disappears at Gen3, that points to signal integrity issues at Gen4 speeds under sustained load — slot, board traces, or physical seating. If it still crashes at Gen3, signal integrity is less likely.

5. Power cabling check

Make sure the GPU uses two separate PCIe power cables from the PSU, not one daisy-chained cable. Under sustained combined CPU + GPU load (Threadripper + 3080 Ti), transient demand on the 12V rail can expose marginal cabling or PSU response.

6. Thermal / VRM

Core temperature can look fine in nvidia-smi while VRMs overheat — VRM temps aren’t exposed. Quick test: open the case, point a fan directly at the GPU, rerun the workload. If the crash disappears, it points to VRM thermal instability.

If none of the above changes the behavior, the next step is a slot swap. Even on WRX80 where slots are CPU-wired, trace routing and power delivery differences can show up under sustained high-power load.

Start with the power cap test — it takes 10 seconds and no reboot. Then extend into the sustained transfer test to separate transport stability from workload-induced behavior. Let us know what happens.

6

I think we got it now. It was the PCIE cable connections.

When I did the last changes to my custom cooling waterloop (introducing a flow and temperature sensors and tap fitting to drain it easily) also I moved the GPU to the top slot. When reconnecting the PCIE, because the zip ties made it hard I ended up connecting both from a single cable, thus, a single PSU connection.

Before running any of the suggestions, I cut the zip ties and connected each PCIE to one separate cable so it goes to 2 PSU PCIE slots. And now …

:~ [base]
$ sudo nvidia-smi -pl 200
[sudo] password for admanero:
Power limit for GPU 00000000:81:00.0 was set to 200.00 W from 370.00 W.
All done.

:~ [base]
$ nvidia-smi -q | grep -i “Power Limit”
Current Power Limit : 200.00 W
Requested Power Limit : 200.00 W
Default Power Limit : 370.00 W
Min Power Limit : 100.00 W
Max Power Limit : 370.00 W
Current Power Limit : N/A
Requested Power Limit : N/A
Default Power Limit : N/A
Min Power Limit : N/A
Max Power Limit : N/A
:~ [base]

Now the whisper job runs to completion. The temperature most often being 37C with 1 instance of 38C

:~ [base]
$ nvidia-smi dmon -s pucvmet -d 1
…

gpu pwr gtemp mtemp sm mem enc dec jpg ofa mclk pclk pviol tviol fb bar1 ccpm sbecc dbecc pci rxpci txpci

Idx W C C % % % % % % MHz MHz % bool MB MB MB errs errs errs MB/s MB/s

0    198     37      -     77     53      0      0      0      0   9251   1785     48      0   6148     14      0      -      -      0    729     88 
 
0    197     38      -     81     43      0      0      0      0   9251   1770     31      0   6148     14      0      -      -      0    723    111

So, I set the power back to 370W and now run again but the large model instead of turbo. And again, the job completes, this time reaching a maximum of 52C.

So, the issue is sorted. I feel a bit silly , but when you buy 2nd hand hardware and the User Guide is not readily present, these little details … I should had noticed though.
Thank you very much for your assistance. The issue can be closed and marked as “solved”.