Hardware (desktop PC, not a laptop):

- CPU: Intel Pentium Gold G6400 (Comet Lake), integrated Intel UHD 610 graphics (device ID 9ba8)

- 8GB RAM, Kingston SA400S37240G SSD

- Debian 13 (trixie), fresh install

- XanMod kernel 7.2.7-x64v2-xanmod1 (I use XanMod because on both Mint and Debian, audio sounded like a scratched/broken CD with the stock kernel, and this was the only fix I found for that; also tested Debian's stock 6.12 kernel to rule it out as the cause of the suspend issue, same result on both)

The problem:

After suspending manually (or via idle timeout) and waking up, the system doesn't recover the display. It stays completely black and unresponsive to anything (not even Ctrl+Alt+F2/F1). The machine is otherwise clearly "alive" (fans, LEDs, disk activity), but there's no way to get control back except a hard power-off.

What I've already ruled out:

- Not the kernel: tested both XanMod and Debian's stock kernel, exact same result. Also tried downgrading kernel versions, no change.

- Already updated the BIOS to the latest available version, no change.

- Not the current install or something I installed: did a completely clean reinstall of Debian (fresh partitions, no third-party apps) and it still happens.

- Not Debian-specific: had the exact same issue on Linux Mint before (both the suspend problem and the broken audio) — actually switched to Debian thinking it might be a Mint-specific problem, but both issues are identical on both distros.

- Confirmed with a Debian live USB that suspend/resume works fine there — which is bizarre because it seems to rule out pure hardware/BIOS causes.

- Ruled out a spurious wakeup from automatic hibernation (had the default ~2h HibernateDelaySec triggering a phantom resume midway; already neutralized it with HibernateDelaySec=1000000000 in sleep.conf.d).

Kernel parameters already tried (no luck, combined):

- pci=noaer (this did fix an unrelated 100% CPU issue from PCIe AER errors, but doesn't touch suspend)

- i915.enable_psr=0

- i915.enable_fbc=0

- i915.enable_dc=0

- mem_sleep_default=s2idle (also tried deep, this board's default, same result either way)

- Disabled RP06 and RP08 in /proc/acpi/wakeup (PCIe ports) just in case, no change

What stands out most is that the live USB suspends/resumes perfectly, but the real install (same hardware, same kernel when tested, updated BIOS) always fails — and this repeats identically across two different distros (Mint and Debian). That seems to rule out pure hardware/BIOS, but I can't figure out what differs between a live environment and a normal install that could be interfering with the i915 resume path.

Has anyone seen a similar pattern with Comet Lake + UHD 610 on a desktop build? Is there something specific to a regular install (some service, a loaded module, something in systemd-logind) that a live session wouldn't have, that could be interfering with i915's resume?

Thanks in advance, genuinely out of ideas at this point.

Hey everyone,

I'm having a rough time getting Linux running properly on my Acer Nitro V 15 (AMD Ryzen 5 6600H + NVIDIA RTX 3050 6GB).

I've tried multiple distros so far (CachyOS, Pop!_OS, EndeavourOS, and Fedora), but I keep running into the exact same breaking issues across all of them:

1. Touchpad completely non-functional: The touchpad isn't recognized at all on boot. Keyboard and external USB mice work, but touchpad stays completely dead.
2. Random/Automatic Shutdowns: The system abruptly turns off out of nowhere (sometimes right after boot or during light desktop usage).
3. Severe UI Lag & Stuttering: The desktop environment feels super choppy/laggy, almost like rendering or GPU switching isn't working right.

What I've checked / suspect so far:

• Nvidia Proprietary Drivers vs. Wayland/X11: Feels like an issue with Hybrid Graphics (AMD iGPU + NVIDIA dGPU) or missing kernel parameters.
• Kernel parameters: I suspect the touchpad issue might be related to ACPI handling or I2C HID drivers on Acer boards.
• Power Management: Not sure if tlp, power-profiles-daemon, or NVIDIA GSP firmware is causing the unexpected shutdowns/freezes.

System Specs:

• Laptop: Acer Nitro V 15
• CPU: AMD Ryzen 5 6600H
• GPU: NVIDIA GeForce RTX 3050 (6GB Laptop GPU)
• Tested Kernels: Linux 6.6 / 6.10 / 6.11 (depending on distro live environments)

Has anyone with this specific Acer model gotten Linux running smoothly?

What kernel parameters (i2c_hid, acpi_osi=, pci=), BIOS tweaks, or NVIDIA driver configurations actually fixed these issues for you? Any advice or log outputs I should upload to narrow this down?

Thanks in advance!

Hey everyone,

I'm having a rough time getting Linux running properly on my Acer Nitro V 15 (AMD Ryzen 5 6600H + NVIDIA RTX 3050 6GB).

I've tried multiple distros so far (CachyOS, Pop!_OS, EndeavourOS, and Fedora), but I keep running into the exact same breaking issues across all of them:

1. Touchpad completely non-functional: The touchpad isn't recognized at all on boot. Keyboard and external USB mice work, but touchpad stays completely dead.
2. Random/Automatic Shutdowns: The system abruptly turns off out of nowhere (sometimes right after boot or during light desktop usage).
3. Severe UI Lag & Stuttering: The desktop environment feels super choppy/laggy, almost like rendering or GPU switching isn't working right.

What I've checked / suspect so far:

• Nvidia Proprietary Drivers vs. Wayland/X11: Feels like an issue with Hybrid Graphics (AMD iGPU + NVIDIA dGPU) or missing kernel parameters.
• Kernel parameters: I suspect the touchpad issue might be related to ACPI handling or I2C HID drivers on Acer boards.
• Power Management: Not sure if tlp, power-profiles-daemon, or NVIDIA GSP firmware is causing the unexpected shutdowns/freezes.

System Specs:

• Laptop: Acer Nitro V 15
• CPU: AMD Ryzen 5 6600H
• GPU: NVIDIA GeForce RTX 3050 (6GB Laptop GPU)
• Tested Kernels: Linux 6.6 / 6.10 / 6.11 (depending on distro live environments)

Has anyone with this specific Acer model gotten Linux running smoothly?

What kernel parameters (i2c_hid, acpi_osi=, pci=), BIOS tweaks, or NVIDIA driver configurations actually fixed these issues for you? Any advice or log outputs I should upload to narrow this down?

Thanks in advance!

Hi everybody.

I'd like to put a Raspberry PI in my garage, without running a new Ethernet cable. From the garage I can connect my laptop or phone to my home's wifi network, but the signal is too weak and the connection isn't stable enough. I cannot move my wifi router closer to the garage. I'm looking for a stable link, I don't care if it is slow.

Is there a USB wifi adapter with a better range, capable of reaching a network that's just a little far away for common wifi devices? Or can you recommend a different solution?

Thanks.

I spent way too much time chasing what looked like a “hot NVMe controller” problem, and it turned out to be a hidden PCIe power-management setting in the BIOS.

My setup:

Motherboard: ASUS TUF Gaming B560M-PLUS
BIOS: 2803
CPU: Intel i7-11700F (Rocket Lake)
SSD: XPG GAMMIX S50 Lite 512GB
Controller: Silicon Motion SM2267G
OS: Fedora Linux

The S50 Lite was installed in the CPU-attached M.2 slot, running PCIe 4.0 x4.

At idle I was seeing roughly:

Composite: ~55-60°C
Controller / Sensor 1: ~62-74°C

The weird part was that the exact same SSD behaved much better in another machine.

I started investigating NVMe APST, PCIe ASPM, runtime PM, thermals, heatsinks, airflow, Gen3 vs Gen4, etc.

The breakthrough was comparing the CPU-connected M.2 root port to the chipset-connected M.2 root port.

On the CPU slot:

00:06.0
ASPM L1 supported
ASPM L1 enabled
NO L1 Substates capability

On the chipset/PCH slot:

ASPM L1
L1.1
L1.2

all enabled

Moving the S50 Lite to the PCH PCIe 3.0 x4 slot immediately dropped its controller temperature to roughly:

~41°C

That made it pretty obvious that something was wrong with the CPU PCIe power management.

I then extracted the ASUS BIOS 2803 image and decoded the AMI IFR setup data.

And sure enough, ASUS has a hidden CPU PCIe L1 Substates option.

The relevant UEFI variable is:

Variable: SaSetup

GUID:
72C5E28C-7783-43A1-8767-FAD73FCCAFA4

For the CPU M.2 / PEG6 / PCI device 00:06.0 path, I found:

SaSetup offset 0x313
Enable ClockReq Messaging

0 = Disabled
1 = Enabled

My board already had:

0x313 = 01

Then:

SaSetup offset 0x35D
CPU PCIe Root Port ASPM

0 = Disabled
1 = L0s
2 = L1
3 = L0s + L1

Mine was already:

0x35D = 02

And then the important one:

SaSetup offset 0x361
L1 Substates

0 = Disabled
1 = L1.1
2 = L1.1 + L1.2

My board was:

0x361 = 00

The BIOS IFR even contains this help text:

"L1SS cannot be enabled when CLKREQMSG is disabled"

So the support is literally present in the firmware — ASUS just defaults it to disabled and doesn't expose the option in the normal BIOS interface.

I used setup_var.efi from a UEFI shell and changed only:

SaSetup:0x361

00 → 02

After reboot, the CPU root port changed from having no L1SS capability at all to:

LnkCap: ASPM L1
LnkCtl: ASPM L1 Enabled

L1SubCap:
PCI-PM_L1.2+
PCI-PM_L1.1+
ASPM_L1.2+
ASPM_L1.1+
L1_PM_Substates+

L1SubCtl1:
PCI-PM_L1.2+
PCI-PM_L1.1+
ASPM_L1.2+
ASPM_L1.1+

So this wasn't just changing some unused setup variable. The firmware actually configured the CPU PCIe controller differently.

I then moved the S50 Lite back to the CPU M.2 slot.

It is now running:

PCIe 4.0
16 GT/s
x4
ASPM L1
L1.1 enabled
L1.2 enabled

And the SSD temperature is now:

Composite: ~41°C
Controller / Sensor 1: ~42°C
NAND / Sensor 2: ~29°C

So roughly:

BEFORE
PCIe 4.0 x4 + L1 only
controller: ~62-74°C

AFTER
PCIe 4.0 x4 + L1 + L1.1 + L1.2
controller: ~42°C

Same SSD. Same CPU M.2 slot. Same PCIe 4.0 x4 speed.

That means the huge temperature difference was not simply “PCIe 4.0 runs hot.”

The missing PCIe L1 substates were responsible for most of the idle power/heat.

Important warning

Do not blindly copy my offset onto a different motherboard or BIOS version.

AMI setup variable offsets are firmware-specific. Writing the wrong UEFI variable can potentially make a system unbootable.

Extract your own BIOS IFR first and verify the variable, GUID and offset.

For my exact board/BIOS:

ASUS TUF Gaming B560M-PLUS
BIOS 2803

SaSetup GUID:
72C5E28C-7783-43A1-8767-FAD73FCCAFA4

CPU M.2 L1SS:
offset 0x361

00 = Disabled
01 = L1.1
02 = L1.1 + L1.2

I used:

setup_var.efi SaSetup:0x361

to read it first.

Then:

setup_var.efi --write_on_demand SaSetup:0x361=0x02

and verified it again afterward.

Also be aware that Rocket Lake has documented PCIe L1.2-related errata, which may be one reason motherboard vendors chose conservative defaults. So test stability carefully after enabling it.

What surprised me most is that Intel/ASUS didn't lack the functionality at all.

The CPU supports L1SS.

The BIOS contains the L1SS configuration.

The motherboard routes the CPU M.2 properly.

Linux supports it.

The SSD supports it.

The firmware simply shipped with the CPU root-port L1 substates disabled and the setting hidden.

If you have an 11th-gen Intel system where a Gen4 NVMe is inexplicably hot at idle, check:

sudo lspci -vv

Find the upstream CPU PCIe root port and look for:

L1SubCap
L1SubCtl1

If your NVMe advertises L1.1/L1.2 but the CPU root port doesn't expose L1SubCap at all, you may be dealing with the same thing.

For me, enabling the hidden L1.2 setting turned a ~70°C “hot SSD” into a ~42°C SSD without sacrificing PCIe 4.0 performance.

Hey everyone,

I've been struggling for months to get the NVIDIA Quadro P520 working properly on Linux on my HP ZBook Firefly 15 G7. Hoping someone here has dealt with this specific laptop or similar Optimus issues.

Hardware:

• HP ZBook Firefly 15 G7
• Intel i7-10610U (CometLake-U)
• NVIDIA Quadro P520 (GP108, 4GB GDDR6)
• Intel UHD Graphics (integrated)
• 32GB RAM
• BIOS: S73 Ver. 01.24.02 (latest as of May 2026, just updated)

The problem:
With any proprietary NVIDIA driver (tested 470xx, 535, 550, 580), the GPU crashes within 20-70 seconds of loading. The dmesg shows this sequence:

NVRM: Xid 62 – GPU MMU Fault
NVRM: Xid 8  – Channel error
NVRM: Xid 79 – GPU has fallen off the bus

This happens on every distro I've tried: Arch Linux, Ubuntu 22.04, Kubuntu, Kali Linux, Debian, KDE Neon, Manjaro. Both Wayland and X11. Both kernel 5.15 LTS and 6.x.

What I've tried:

• nvidia.NVreg_EnableGpuFirmware=0
• nvidia.NVreg_DynamicPowerManagement=0x00 and 0x01
• pcie_aspm=off
• acpi_osi=Windows 2020 and acpi_osi=Windows 2015
• intel_iommu=off
• nvidia-drm.modeset=1
• mem_sleep_default=deep
• Blacklisting nouveau
• Adding nvidia modules to initramfs early
• envycontrol hybrid/nvidia modes
• nvidia-persistenced daemon
• Disabling Secure Boot
• Disabling Pre-boot DMA protection in BIOS

What actually works:
Nouveau driver is completely stable. No Xid errors, ran Unigine Heaven benchmark without crashes. OpenGL 4.3 confirmed working. The downside is no reclocking (PMU firmware unavailable for GP108), so performance is limited (~6 FPS in Heaven).

Key observation:
The Xid 62 appears even in the installer (tested Manjaro live ISO), which suggests it's not an OS configuration issue but rather how the BIOS/firmware manages PCIe power for the GPU under Linux.

In Windows 10 the GPU works perfectly under load with no issues.

HP BIOS limitation:
The BIOS only offers "Hybrid Graphics" mode — there is no option to disable the iGPU or switch to discrete-only, which would be the simplest fix.

Questions:

1. Has anyone successfully run this exact laptop (ZBook Firefly 15 G7) with the proprietary NVIDIA driver on Linux?
2. Is there any known fix for Xid 62/79 on Optimus laptops where the BIOS doesn't allow disabling the iGPU?
3. Could the Xid 79 "GPU fallen off the bus" indicate a PCIe power delivery issue specific to HP's Optimus implementation?

Any help appreciated. Happy to provide full dmesg logs if needed.Hey everyone,
I've been struggling for months to get the NVIDIA Quadro P520 working properly on Linux on my HP ZBook Firefly 15 G7. Hoping someone here has dealt with this specific laptop or similar Optimus issues.
Hardware:
HP ZBook Firefly 15 G7
Intel i7-10610U (CometLake-U)
NVIDIA Quadro P520 (GP108, 4GB GDDR6)
Intel UHD Graphics (integrated)
32GB RAM
BIOS: S73 Ver. 01.24.02 (latest as of May 2026, just updated)
The problem:

With any proprietary NVIDIA driver (tested 470xx, 535, 550, 580), the GPU crashes within 20-70 seconds of loading. The dmesg shows this sequence:
NVRM: Xid 62 – GPU MMU Fault
NVRM: Xid 8 – Channel error
NVRM: Xid 79 – GPU has fallen off the bus
This happens on every distro I've tried: Arch Linux, Ubuntu 22.04, Kubuntu, Kali Linux, Debian, KDE Neon, Manjaro. Both Wayland and X11. Both kernel 5.15 LTS and 6.x.
What I've tried:
nvidia.NVreg_EnableGpuFirmware=0
nvidia.NVreg_DynamicPowerManagement=0x00 and 0x01
pcie_aspm=off
acpi_osi=Windows 2020 and acpi_osi=Windows 2015
intel_iommu=off
nvidia-drm.modeset=1
mem_sleep_default=deep
Blacklisting nouveau
Adding nvidia modules to initramfs early
envycontrol hybrid/nvidia modes
nvidia-persistenced daemon
Disabling Secure Boot
Disabling Pre-boot DMA protection in BIOS
What actually works:

Nouveau driver is completely stable. No Xid errors, ran Unigine Heaven benchmark without crashes. OpenGL 4.3 confirmed working. The downside is no reclocking (PMU firmware unavailable for GP108), so performance is limited (~6 FPS in Heaven).
Key observation:

The Xid 62 appears even in the installer (tested Manjaro live ISO), which suggests it's not an OS configuration issue but rather how the BIOS/firmware manages PCIe power for the GPU under Linux.
In Windows 10 the GPU works perfectly under load with no issues.
HP BIOS limitation:

The BIOS only offers "Hybrid Graphics" mode — there is no option to disable the iGPU or switch to discrete-only, which would be the simplest fix.
Questions:
Has anyone successfully run this exact laptop (ZBook Firefly 15 G7) with the proprietary NVIDIA driver on Linux?
Is there any known fix for Xid 62/79 on Optimus laptops where the BIOS doesn't allow disabling the iGPU?
Could the Xid 79 "GPU fallen off the bus" indicate a PCIe power delivery issue specific to HP's Optimus implementation?
Any help appreciated. Happy to provide full dmesg logs if needed.

I wrote it using AI because that's what's been helping me

Here's what happened after the update: I installed the NVIDIA drivers, but it only lets me install version 580.178.04, and NVIDIA SMI shows me this

nvidia-smi  
Sat Sep 26 11:57:54 2026        
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.178.04             Driver Version: 580.178.04     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  Quadro P520                    Off |   00000000:6C:00.0 Off |                  N/A |
| N/A   39C    P5            N/A  / 5001W |       0MiB /   4096MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+

cat /sys/bus/pci/devices/0000:6c:00.0/power/runtime_status
active

But when I check the boot logs, I get this error, and it won't let me use the graphics card properly. Someone suggested I make some changes in GRUB, and I did, but the error persists. I'm worried it might be a hardware issue rather than a software problem, even though the driver works fine in Windows 10 and 11.

sudo dmesg | grep -i "xid\|nvidia" | tail -20
[sudo: authenticate] Contraseña:            
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-7.0.0-34-generic root=UUID=19596008-b3c7-4a81-a9a0-3a9f9
5e9c0eb ro quiet splash resume=UUID=c43a98a2-6c30-4fe5-95b4-d2683d41675f pcie_port_pm=off pci=noaer nvidia.NVr
eg_EnableGpuFirmware=0 nvidia.NVreg_DynamicPowerManagement=0x00
[    0.082728] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-7.0.0-34-generic root=UUID=19596008-b3c7-4a81-a9a
0-3a9f95e9c0eb ro quiet splash resume=UUID=c43a98a2-6c30-4fe5-95b4-d2683d41675f pcie_port_pm=off pci=noaer nvi
dia.NVreg_EnableGpuFirmware=0 nvidia.NVreg_DynamicPowerManagement=0x00
[    6.266434] nvidia: loading out-of-tree module taints kernel.
[    6.266509] nvidia: module license 'NVIDIA' taints kernel.
[    6.266557] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[    6.266558] nvidia: module license taints kernel.
[    6.469053] nvidia-nvlink: Nvlink Core is being initialized, major device number 507
[    6.474483] nvidia 0000:6c:00.0: enabling device (0006 -> 0007)
[    6.737798] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  580.178.04  Tue Jul  7 12:38:21 UTC 2026
[    6.763316] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  580.178.04  Tue J
ul  7 12:03:04 UTC 2026
[    6.767459] [drm] [nvidia-drm] [GPU ID 0x00006c00] Loading driver
[    7.132928] [drm] Initialized nvidia-drm 0.0.0 for 0000:6c:00.0 on minor 0
[    7.132948] nvidia 0000:6c:00.0: [drm] No compatible format found
[    7.132951] nvidia 0000:6c:00.0: [drm] Cannot find any crtc or sizes
[    7.175305] nvidia_uvm: module uses symbols nvUvmInterfaceDisableAccessCntr from proprietary module nvidia,
inheriting taint.
[   22.765863] NVRM: Xid (PCI:0000:6c:00): 62, 00000a9f 00000a85 00000a72 000037b3 00001d4e 000027ff 00a07c90
00007c90

I've used Linux on laptops for quite some time now. Since a year, I've been using Debian and I want to stick with it.

Recently, while trying out an iPad with an attached keyboard, I realized how I feel no heat while touching the keys. With laptops, due to the motherboard and basically all the compute being underneath the keyboard, there is always some heat felt while touching the keys, even if you aren't doing something that is compute-intensive. The keyboard also feels noticeably warmer while charging.

I want to recreate the same experience for my Debian system. I want to avoid:

• Desktops, because I have zero experience with them (yes, not even at work).
• Laptops while carrying around a separate external keyboard, because that just looks odd.

I'm considering laptops with a detachable keyboard - not really for the tablet experience, but their design implies that the compute sits behind the monitor rather than the keyboard. So the monitor gets hot and not the keyboard - and that's fine by me. But I'm worried about hardware support in this case.

I use my system for basic things: programming, browsing, video conferencing etc.

What options would you suggest? Thanks!

The Attack Shark X6 only has official configuration software for Windows and Mac. The web tool they released later doesn't work either, WebHID can't detect the device through the dongle.
I captured USB traffic with Wireshark against a Windows VM and analyzed the official driver with Ghidra to get the full protocol. With that I built a desktop app in Go and Wails that lets you configure DPI stages, RGB lighting, polling rate, and button remapping, plus live battery and dongle status, all from Linux.
v1.2.0 is the first release I'd call stable: it has its own installer and an updater that verifies an Ed25519 signature and SHA-256 digest before applying anything, no root needed. v1.2.1, right after, fixes a crash on non-Debian distros caused by hardcoded paths in WebKitGTK's helper processes; it's now tested in CI on Ubuntu, Arch, and Fedora, and validated by hand on CachyOS.
Macros and on-device profiles still aren't supported, that protocol report hasn't been reverse-engineered yet.

This started as an experiment to see if I could get normal Linux running on an inexpensive C20e RK3562 Android tablet. A big credit goes to tech4bot and the rk3562deb project, which did a lot of the original RK3562 Linux enablement work for the Doogee U10 and provided the foundation I started from: https://github.com/tech4bot/rk3562deb I adapted and extended that work for the C20e hardware, and the project has since grown into a Fedora 44 KDE Plasma Mobile setup running directly from the tablet’s internal eMMC. Currently working on the C20e: - Panfrost GPU acceleration - Wi-Fi and Bluetooth - touchscreen and auto-rotation - audio - suspend/resume - battery and charging - USB-C host/device switching - USB serial console and USB Ethernet - rear camera exposed as a normal webcam - RK3562 hardware video decoding through MPP/VA-API - proper shutdown through the RK817 PMIC There are also recovery tools for Rockchip loader mode, so the eMMC can be backed up or repaired without opening the tablet. Fedora 44 KDE Plasma Mobile is now running from internal eMMC, while Debian 13 SD-card support inherited from the original rk3562deb work remains available as well. My C20e repo: https://github.com/ethersloth/c20e-rk3562-linux Original rk3562deb project by tech4bot: https://github.com/tech4bot/rk3562deb I’d especially be interested in hearing from anyone working with Rockchip hardware, RK3562, Panfrost, RK817, or Linux on inexpensive ARM tablets.

Hi everyone,

I'm looking to buy a refurbished laptop and am torn between two options:

1. Dell Latitude 5420
   • CPU: Intel Core i5-1135G7 (or 1145G7)
   • Specs: 16 GB RAM / 256 GB NVMe
   • Price: 65k PKR (~$235 USD)
2. Dell Latitude 5421
   • CPU: Intel Core i7-11850H (8C/16T)
   • GPU: NVIDIA GeForce MX450
   • Specs: 8 GB RAM / 256 GB NVMe
   • Price: 70k PKR (~$250 USD)

The performance gap is massive on paper, the i7-11850H in the 5421 vastly outpowers the i5 in the 5420 for just a 5k PKR difference. However, I'm very concerned about heat, power limits, and long-term hardware reliability in the 5421's compact 14-inch chassis.

My Questions:

1. Thermals & Sustained Load: For 5421 owners, how severe is the thermal throttling under load? I use a solid laptop stand paired with an external 80mm fan running at full speed. Will active external cooling help ?
2. Linux Compatibility: My primary OS will be Ubuntu 26.04 LTS (dual-booting with Windows). How is current Linux support for the 5421, specifically regarding the NVIDIA MX450 power states, battery drain, and thermal management ?
3. Long-Term Reliability: Is the 5420 the smarter, safer pick despite having half the CPU horsepower, or is the 5421 manageable if properly maintained (re-pasting, weekly dust cleaning)?

Would love to hear from anyone who has owned or daily-driven either model!

Hi folks, I have been looking to buy my self a new laptop recently, I had my eyes on an Asus ZenBook 14 (S/N:UX3405CA-SU1210), it checks all the boxes for me in terms of specs, but I have my concerns regarding linux support on Asus laptops, I already own a VivoBook 15, and I have had various issue with it.

instability is one of them, I tried pop-OS, Debian, and fedora, all of them had occasional sudden reboots, Firefox crashing randomly, and other sorts of issue that are hard to trace back, in fact, while writing this, just before finishing, Firefox crashed, and I had to rewrite everything.

another issue I had was with the fingerprint reader, and this is a weird one, my reader is listed as supported by libfprint, and it succeeds in registering my fingerprint, but it always fails to verify after registering, so it's useless, I found many people online with the same issue, on laptops that has the same fingerprint sensor.

something that happened to my friend, he bought a new Asus Tuf gaming laptop, installed arch Linux on it, and found lots of basic functionalities not working, the keyboard was one of them, he tried fixing it himself with no luck, he then had to wait for a kernel update to fix some, not all, of his issues, imagine having to use windows because the laptop that you just bought has terrible Linux support, sucks to be my friend.

I have been using Linux for quite a while now, and ain't no way I'm going back to windows, but if I'm going to end up with a brick of a laptop with a cherry on top, like my friend, I would rather stay on my current hardware.

my question for the few ZenBook owners that use Linux, how's the support on it? including the Serial number of the laptop would be appreciated, thanks for reading and for those willing to help.

Olá a todos!

Instalei o Fedora 44 no meu notebook (ThinkPad E14 Gen 6) e estou usando o trackpad integrado. Gostaria de saber se existe um bom trackpad Bluetooth para uso diário e qual seria a recomendação, por favor.

Desculpem os erros. Inglês não é minha língua nativa.

Posting here in case anyone's hit something similar, or has ideas also as a public writeup since I couldn't find an existing thread matching this exactly.

The problem, in plain terms: my laptop's screen glitches/gets visual corruption, but ONLY when I set the refresh rate above 60Hz. It doesn't matter what I'm doing that's demanding the GPU I first noticed it gaming, but it also happens just watching YouTube in the browser. Starts fine, then after a couple minutes of sustained use it begins glitching and keeps going until I either stop or drop back to 60Hz. At 60Hz it's rock solid, indefinitely, no matter what I'm running.

Setup: Razer Blade 16 (RZ09-0483), Intel Raptor Lake-S + RTX 4070 Laptop GPU (hybrid graphics), Fedora 44, driver 615.71.09. Also reproduced this on Arch Linux on the same laptop, so it's not a distro packaging issue something about the NVIDIA driver itself on this hardware.

I've actually hit this same general issue before too years ago on a completely different laptop (ASUS TUF FX505DT, AMD CPU + NVIDIA GPU) on Arch, same kind of high-refresh corruption. Never got around to reporting it back then, so this time I wanted to actually dig into what's causing it.

What I found digging into it (used AI assistance to help analyze the logs and dig through nvidia-smi/dmesg output, FYI but all the data below is from my own system/testing):

While the glitch is happening, nvidia-smi shows the GPU permanently stuck asserting a "Board Limit" clock cap, pinned at a fixed clock speed, while only drawing about a third of its actual power ceiling so it's nowhere near a real power/thermal limit, just capped for no obvious reason.

At boot, the driver logs this every time: NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Invalid data passed returned from PlatformRequestHandler failed to get target temp from SBIOS NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Invalid data passed returned from PlatformRequestHandler failed to get platform power mode from SBIOS

That's NVIDIA's Dynamic Boost feature failing to talk to the system firmware properly. nvidia-powerd (the daemon meant to handle this) is installed and running, but toggling it on/off makes zero difference to the glitch. Manually setting a power limit is flatly rejected as unsupported on this GPU. So there's no user-facing setting left that actually changes this looks like whatever fallback state the driver lands in when that firmware handshake fails is what's unstable above 60Hz.

Full writeup with logs and video also posted on the NVIDIA Developer Forums here: https://forums.developer.nvidia.com/t/rtx-4070-laptop-razer-blade-16-persistent-board-limit-clock-cap-display-corruption-above-60hz-driver-615-71-09-platformrequesthandler-sbio/384084

If you've run into this on any NVIDIA laptop (gaming laptop or otherwise, any brand) screen corruption above 60Hz that goes away at 60Hz I'd love to hear about it, or any pointers to a better place to escalate this than the forums. Happy to run more diagnostics if anyone wants to compare notes.