Incompatible Dell 5490 - How to find a good laptop?

I own a Latitude e6540 for years that works flawlessly with Linux. I was confident that a brand-new Latitude 5490 (i7 8650u) would work too. That simply wasn't the case. Unfortunately, Linux can't stand-by. This has the effect of reducing the portability of the system, because I can't ever leave it unplugged unless it is completely shut down, because otherwise it continues to draw power from the battery until it becomes dead, and then I lose whatever I had been working on. It effectively makes the laptop unusable for me. Unfortunately this problem persists across every Linux distro that I've tried (Manjaro, Ubuntu).

How can I buy a comparable laptop that does not have this type of issue?

How so? Why isn't it compatible? What hardware component can't be made to work?


you may start with a look here:


Is compatible with Linux Ubuntu 12.04 (source)

the Latitude e6540 IS compatible with everything. I think it's this lousy UEFI that's mucking everything up in the Latitude 5490. That's why I'm selling it. Arch Linux could at least reboot the machine. Ubuntu couldn't even manage that!
What concerns me is that I actually DID look at both of those links before buying, and Latitude 5490 is on the wiki.archlinux list, even though it very clearly doesn't meet my expectation of compatible (mine or anyone's). The seems to only sell computers that are more expensive than what I'm able to afford. I was hoping I could get a recommendation from someone with a good-working modern UEFI laptop that works well with linux. I heard that maybe Dell's XPS models are better supported. Anyone have a good experience?

you can have a look here too:

I'm using a XPS 9560 almost three years now, only manjaro installed on it, bios legacy, battery, 97 W, it's a optimus lap but I use only with intel graphics, disabled nvidia via acpi_call, quite satisfied but is not cheap...

if I will change I will go for the basic without nvidia


I have had an Inspiron 5770 for a year now.

We only update to SSD devices.

1 Like

I'm experiencing the same issue:

That's an old (1 year, 4 months) Intel driver-related bug, patched quite some time ago. Manjaro is Arch-based. and Arch is usually preeminent with Intel patches.


have you considered that maybe it can work? some laptops, default to a certain sleep method that doesnt behave well for power savings but there is usually a way of making this work even if it's hibernate rather than suspend. maybe try posting some system info.

inxi -Fxxxza --no-host
grep -v /sys/power/*
1 Like
System:    Kernel: 5.4.6-2-MANJARO x86_64 bits: 64 compiler: gcc v: 9.2.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-5.4-x86_64 root=UUID=85d80ee1-1aff-401f-b83e-470923b37e6b rw quiet apparmor=1 
           security=apparmor udev.log_priority=3 
           Desktop: Xfce 4.14.2 tk: Gtk 3.24.13 info: xfce4-panel wm: xfwm4 dm: LightDM 1.30.0 Distro: Manjaro Linux 
Machine:   Type: Laptop System: Dell product: Latitude 5490 v: N/A serial: <filter> Chassis: type: 10 serial: <filter> 
           Mobo: Dell model: 0FDHF4 v: A00 serial: <filter> UEFI: Dell v: 1.11.1 date: 09/19/2019 
Battery:   ID-1: BAT0 charge: 47.7 Wh condition: 68.0/68.0 Wh (100%) volts: 7.8/7.6 model: Samsung SDI DELL MT31P87 
           type: Li-ion serial: <filter> status: Discharging 
CPU:       Topology: Quad Core model: Intel Core i7-8650U bits: 64 type: MT MCP arch: Kaby Lake family: 6 model-id: 8E (142) 
           stepping: A (10) microcode: CA L2 cache: 8192 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 33615 
           Speed: 800 MHz min/max: 400/4200 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 802 8: 800 
           Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages 
           Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable 
           Type: mds mitigation: Clear CPU buffers; SMT vulnerable 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling 
           Type: tsx_async_abort mitigation: Clear CPU buffers; SMT vulnerable 
Graphics:  Device-1: Intel UHD Graphics 620 vendor: Dell driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:5917 
           Display: x11 server: X.Org 1.20.6 driver: intel unloaded: modesetting alternate: fbdev,vesa 
           resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel UHD Graphics 620 (Kabylake GT2) v: 4.6 Mesa 19.3.2 compat-v: 3.0 
           direct render: Yes 
Audio:     Device-1: Intel Sunrise Point-LP HD Audio vendor: Dell driver: snd_hda_intel v: kernel bus ID: 00:1f.3 
           chip ID: 8086:9d71 
           Sound Server: ALSA v: k5.4.6-2-MANJARO 
Network:   Device-1: Intel Ethernet I219-LM vendor: Dell driver: e1000e v: 3.2.6-k port: f040 bus ID: 00:1f.6 
           chip ID: 8086:15d7 
           IF: enp0s31f6 state: down mac: <filter> 
           Device-2: Intel Wireless 8265 / 8275 driver: iwlwifi v: kernel port: f040 bus ID: 02:00.0 chip ID: 8086:24fd 
           IF: wlp2s0 state: up mac: <filter> 
Drives:    Local Storage: total: 111.79 GiB used: 33.04 GiB (29.6%) 
           ID-1: /dev/sda vendor: OCZ model: VERTEX3 size: 111.79 GiB block size: physical: 512 B logical: 512 B 
           speed: 6.0 Gb/s serial: <filter> rev: 2.25 scheme: GPT 
RAID:      Hardware-1: Intel 82801 Mobile SATA Controller [RAID mode] driver: ahci v: 3.0 port: f060 bus ID: 00:17.0 
           chip ID: 8086.282a rev: 21 
Partition: ID-1: / raw size: 111.29 GiB size: 109.04 GiB (97.98%) used: 33.04 GiB (30.3%) fs: ext4 dev: /dev/sda2 
Sensors:   System Temperatures: cpu: 44.5 C mobo: N/A 
           Fan Speeds (RPM): cpu: 0 
Info:      Processes: 215 Uptime: 1h 44m Memory: 15.50 GiB used: 3.71 GiB (24.0%) Init: systemd v: 242 Compilers: gcc: 9.2.0 
           clang: 9.0.1 Shell: bash v: 5.0.11 running in: xfce4-terminal inxi: 3.0.37 

/sys/power/disk:[platform] shutdown reboot suspend test_resume 
/sys/power/mem_sleep:s2idle [deep]
/sys/power/pm_test:[none] core processors platform devices freezer
grep: /sys/power/pm_wakeup_irq: No data available
/sys/power/state:freeze mem disk
grep: /sys/power/suspend_stats: Is a directory
1 Like

Please, use the </> button above the post entry box when pasting terminal output so it's formatted properly.
You can edit your post (pencil button)

1 Like

have you tried with RAID disabled in bios?

im trying to find documentation supporting the theory, i know i've read of certain raid controllers not working well with suspend but i'm not finding it now that im looking...:thinking:

refers to s3, not sure if it effect s2idle/deep. still looking

have you tried using hibernate (s4) instead of suspend? did you create a swap partition/file during install?

1 Like

Those are great thoughts. I had played with the AHCI/RAID (intel rapid restore) toggle. I didn't create swap partition (just let Manjaro use all defaults format whole disk to eliminate screw-ups, and it didn't create swap).
For some reason it seems to be working fine now. TBH, questioning my own sanity. I had updated to the latest firmware 2 weeks ago. Nothing ever worked right. After reverting to Default Settings in BIOS/UEFI setup, it now seems to work fine. Wish I had thought of that first! btw.. AHCI and RAID both seem to work.. It's hard to say what actually "fixed" this, but it's fair to say that Intel had at least one awkward workaround hardwired into the firmware (a "block sleep" option in Setup). Thanks for your suggestions!


Actually - It still seems to fail about 40% of the time. I'm haven't been able to discern any specific triggers for this, but about 40% of the time isn't able to be brought back from standby (power light, screen blank, unresponsive), and requires a 4-second ATX hard power-off in order to reboot (which causes any active work to be lost, obviously).

Have you tested using the hibernate feature instead. I know that's not the solution you're looking for, but it beats data loss until you get suspend working properly.


Although hibernate does seem to work (sometimes), it apparently doesn't fix the problem. Whether sleep or hibernate, the system still regularly becomes unresponsive when transitioning into low-power states and needs to be powered down hard. It often (but not always) results in an LED Flash Sequence that codes to CPU Failure (Amber, Amber, White).

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by