Talk:Dell XPS 13 2-in-1 (7390)

From ArchWiki
Latest comment: 19 June 2020 by Tamirzb in topic BIOS settings reset

Problems with iwlwifi in Linux 5.4

When running Linux 5.4 the iwlwifi module does not work correctly. (Example dmesg: I stumbled across this: which considers it to be a firmware issue that can be solved with the instructions from here:

In my setting, the module could be loaded and Wifi/Bluetooth are working.

I wasn't sure if that's a proper workaround/fix but it took me quite some time to figure out, so I asked and was directed to put it here :) I like servers (talk) 23:50, 28 November 2019 (UTC)Reply[reply]

Wifi and bluetooth section

I installed Arch with Linux 5.4 and had no problems with LPSS or Wifi. I already removed the section on LPSS. I suggest, the Wifi section can also be removed, unless someone else still has problems. I didn't need to make any modifications for Wifi to work, but I haven't tested Bluetooth yet. Shapeshifter (talk) 11:49, 18 January 2020 (UTC)Reply[reply]

The current installation image should have kernel 5.4.6-arch3 which has the fixes needed for the WiFi. Heftig (talk) 11:54, 18 January 2020 (UTC)Reply[reply]
These appear to be back with 5.5? Sudoes (talk) 18:24, 14 February 2020 (UTC)Reply[reply]
No, they're not. (Also, please sign your discussion posts with ~~~~) Heftig (talk) 18:38, 14 February 2020 (UTC)Reply[reply]
Yes, they are. according to this bugreport: There has been a regression. WiFi is working fine during Arch installation with 5.5.6 arch1-1 kernel but is failing on 5.5.9; issue seems to be back since 5.5.7, yet downgrading the kernel to 5.5.6 from Arch archives did not solve the issue for me. GrandSeB (talk) 11:08, 18 March 2020 (UTC)Reply[reply]

Deep suspend

Out of the box, the system only supports s2idle. This means the laptop will lose significant battery while in this suspend state. You can verify this by checking /sys/power/mem_sleep:

# cat /sys/power/mem_sleep 
[s2idle] deep

However, when you forcibly enable deep (also known as s2ram), the system successfully enters the mode, but resumes with the internal display stuck on the Dell logo (early boot framebuffer contents). I worked around this by disabling the logo under 'Early signs of life' in the UEFI settings.

I then forced deep to be used by appending mem_sleep_default=deep to my kernel command line. Confirmed this worked by checking the kernel logs:

[   44.290126] ACPI: Low-level resume complete

External displays and Thunderbolt dock

Does anyone else have this laptop, the Thunderbolt dock and issues with external screens?

After anywhere between a few minutes and half an hour, both of my external screens suddenly turn off because they get no signal, and I might or might not get CPU FIFO underrun errors in dmesg. Disabling the screens and re-enabling them restores the signal for one minute, then they turn off again. Power cycle and they work again for a time. It seems to be related to certain graphics events, like scrolling in Chromium.

Also, using the latest IntelliJ IDEA makes the entire system unstable. Depending on the kernel and version, the system either freezes completely, kernel panics or XWayland crashes on certain draw events by IDEA (pop ups, scrolling or typing in the editor..)

It seems the entire intel-drm stack with Ice Lake processors is still very much unstable for any use besides using the laptop standalone. DonSig (talk) 07:42, 30 May 2020 (UTC)Reply[reply]

Yes, I'm actually getting very similar issues.
Regarding external monitors, when using a single external monitor I have issues detecting it. Usually turning the external monitor off and on again gets the laptop to detect the monitor. I also had issues coming back from deep sleep while a single external monitor is plugged. When using a docking station with two external monitors I sometimes get weird flashes in one of the screen, and going into deep sleep and back can solve this. Although it can come back any time the monitors turn off due to inactivity.
Regarding software, I am not using IDEA but I am having similar issues with using alacritty on an external screen. The whole X server gets kinda stuck and the only way out of it is to go to a TTY and restart it. When this happens dmesg says intel-drm crashed. Tamirzb (talk) 10:30, 30 May 2020 (UTC)Reply[reply]
Mesa merged a workaround for the IntelliJ issue in 20.1.0. Have you tried upgrading your system to [testing]? Heftig (talk) 15:17, 31 May 2020 (UTC)Reply[reply]
I updated mesa, now the system doesn't freeze or panic, but IntelliJ still crashes (both the 2019 and the 2020 versions). Got tired of it and switched from the JetBrains Java runtime to openjdk, and it seems to be stable for now - so I assume JetBrains messed up somewhere.
As for the external display issues, I made a Hail Mary change in the Dell BIOS and disabled both the virtualization extensions and all Thunderbolt capabilities except for basic functionality. It has been running without hiccups for several hours now, so maybe try that, Tamirzb? Will monitor and report back. DonSig (talk) 11:52, 1 June 2020 (UTC)Reply[reply]
Spoke too soon. Just had another display blackout. This is getting tiresome. DonSig (talk) 15:35, 2 June 2020 (UTC)Reply[reply]
I had these problems. But as described in the linked issue they are gone since Kernel 5.10.16. Anyone still having trouble? Or should we update this section?

BIOS settings reset

I'm not sure how this happened, but after running out of battery my BIOS has been reset to factory settings. As no message was displayed about it, it wasn't that straightforward to troubleshoot. The error I was getting is that the kernel was unable to load the hard drive (since it was set again to "RAID mode" instead of "AHCI mode"), which made me worried that something went wrong with my hard drive. So if you ever get an error about not being able to load the hard drive even you had configured "AHCI mode", make sure the BIOS settings have not been reset. Tamirzb (talk) 23:17, 19 June 2020 (UTC)Reply[reply]