Talk:Dell XPS 13 (9360)
This is just the data output by iw (or the ath10k driver being wrong). I have no problems downloading or uploading files over WLAN with a sustained speeds of several MByte/s (Ubuntu and Arch) while iw dev wlp58s0 link reports 1 or 6 Mbits/s
Lachi (talk) 18:39, 29 October 2016 (UTC)
- Thanks for the information. I directly switched the wlan card my XPS13 had to an Intel 8265 chip, which runs very nice with Linux. This was planed from the beginning, so i didn't check the 1 MByte/s iw gave me further. Feel free to add that.
ColdBug (talk) 18:42, 29 October 2016 (UTC)
- This is strange, my wireless connection isn't stable, and there seems to be a firmware file missing for ath10k. Are you sure it's properly included in the kernel?
~ ➤ dmesg | grep ath10k [ 1.617988] ath10k_pci 0000:3a:00.0: enabling device (0000 -> 0002) [ 1.620576] ath10k_pci 0000:3a:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 [ 1.634702] Modules linked in: vfat fat snd_hda_intel(+) evdev snd_hda_codec input_leds led_class pcspkr mac_hid snd_hda_core snd_hwdep snd_pcm snd_timer snd ath10k_pci(+) soundcore i2c_i801(+) i2c_smbus ath10k_core ath mac80211 i915(+) cfg80211 rtsx_pci_ms memstick mei_me mei shpchp idma64 drm_kms_helper intel_lpss_pci drm intel_gtt intel_pch_thermal syscopyarea sysfillrect sysimgblt fb_sys_fops i2c_algo_bit processor_thermal_device intel_soc_dts_iosf thermal i2c_hid wmi hid battery hci_uart intel_vbtn btbcm soc_button_array btqca btintel int3400_thermal bluetooth acpi_thermal_rel rfkill video intel_lpss_acpi intel_lpss int3403_thermal int340x_thermal_zone intel_hid sparse_keymap fjes acpi_pad ac button acpi_als kfifo_buf industrialio tpm_tis(+) tpm_tis_core tpm sch_fq_codel ip_tables x_tables ext4 [ 1.889432] ath10k_pci 0000:3a:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:3a:00.0.bin failed with error -2 [ 1.889456] ath10k_pci 0000:3a:00.0: Direct firmware load for ath10k/cal-pci-0000:3a:00.0.bin failed with error -2 [ 1.889665] ath10k_pci 0000:3a:00.0: Direct firmware load for ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2 [ 1.889670] ath10k_pci 0000:3a:00.0: could not fetch firmware file 'ath10k/QCA6174/hw3.0/firmware-5.bin': -2 [ 1.890787] ath10k_pci 0000:3a:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:1535 [ 1.890790] ath10k_pci 0000:3a:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 0 testmode 0 [ 1.892271] ath10k_pci 0000:3a:00.0: firmware ver WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features wowlan,ignore-otp,no-4addr-pad crc32 75dee6c5 [ 1.955414] ath10k_pci 0000:3a:00.0: board_file api 2 bmi_id N/A crc32 6fc88fe7 [ 4.078443] ath10k_pci 0000:3a:00.0: htt-ver 3.26 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1 ~ ➤
--Fandekasp (talk) 01:59, 17 November 2016 (UTC)
- I hadn't had any problems, but was trying to get monitor mode working (failed). Found the same message, stuck https://github.com/sumdog/ath10k-firmware/blob/master/ath10k/QCA6174/hw3.0/firmware-5.bin in, saw no changes. Currently troubleshooting wifi breakage after suspend failing "Freezing of tasks failed" ("device poll D ...") which may or may not be related. Also "rtkit-daemon: The canary thread is apparently starving [...] "demoted /usr/bin/pulseaudio" but that's even less likely related.
--Mal (talk) 03:15, 24 March 2017 (UTC)
I haven't had a problem with my ath10k in quite some time, even though linux-firmware pacman upgrades have clobbered my firmware-6.bin file, downgrading it to WLAN.RM.4.4.1-00140-QCARMSWPZ-1 at the time of writing. If it is the case that linux-firmware contains sufficiently up-to-date firmware now, what do people think of removing these instructions?
CraigFurman (talk) 08:44, 17 November 2019 (UTC)
- I haven't had any issues recently either, but let's leave it for now, just in case. If you're not experiencing issues, you wouldn't search for troubleshooting steps in the first place, no? :) DragoonAethis (talk) 12:15, 17 November 2019 (UTC)
> If you're not experiencing issues, you wouldn't search for troubleshooting steps in the first place, no?
That's reasonable. I have not edited the Arch Wiki before and was unsure how to balance the conflicting priorities of de-cluttering and exhaustive troubleshooting resources. In that case, the problem is that the advice doesn't work! The linux-firmware package owns /usr/lib/firmware/ath10k/QCA6174/hw3.0/firmware-6.bin. I have not tried this, but TIL you can prevent individual files from being upgraded by pacman as documented in https://wiki.archlinux.org/index.php/Pacman#Skip_file_from_being_upgraded. Adding that to the wiki might be prudent if we're going to keep the advice.
I did not try the original wiki advice (patching firmware-4.bin) as it was superseded by patching firmware-6.bin. I'm not clear on how the firmware loading process works, but I'd guess that the firmware-6.bin laid down by linux-firmware would take precedence? If so then I reckon we should remove the firmware-4.bin directions as part of this cleanup. What do you think?
CraigFurman (talk) 12:44, 17 November 2019 (UTC)
- This is a page for a specific laptop model with specific hardware issues - generally you want to keep as much reliable info as possible on these, even if it's outdated or low quality, since you never know what issues people are going to have with their hardware revision. Consider this: Whatever caused the wireless problems in your Killer 1535 hardware revision might've been fixed in blobs available in current linux-firmware. But let's say that Qualcomm gets a new hw revision a few months later, same specs, same model number, just that they've introduced a few hardware fixes. And those hardware fixes, oops, introduce a minor bug elsewhere, so we need a firmware fix. But linux-firmware is slightly behind the latest firmware blobs from Qualcomm, so what do these users have to do in the meantime? Replace their adapter, use wired networking? Nah, they're going to google those issues, find a note that Dell and some random wikis recommended upgrading the firmware, so they'll do the same and now it kind of works. (Of course, if the only needed fix for a given issue is to upgrade the software to a decently recent version, that can be removed after a while since we're on Arch and the only supported system is a fully updated one. The same advice does not apply to software/guide/explanation pages, please purge or mark anything outdated on these :)
- The advice mentions replacing the entire QCA6174 folder with the downloaded one - that is, to remove all the files provided by linux-firmware (pacman will still be able to upgrade the package just fine by overwriting your files). This works just fine, or at least it did on my laptop back when I needed those fixes.
- DragoonAethis (talk) 12:59, 17 November 2019 (UTC)
Initially works out of the box but sometimes dies after resume from suspend. Anyone else getting this?
Zorael (talk) 02:12, 31 October 2016 (UTC)
Hey there, it's the same for me! I don't use it anyway so I just made a fast check and could not find a solution. Can't see something irregual in dmesg or journactl, so it could be a prolem with libinput...
Update: When starting Arch I can see the ELAN Touchscreen in "libinput-list-devices" and also in xinput list as a virtual device. After suspend its gone from both...
ColdBug (talk) 08:15, 31 October 2016 (UTC)
Found a answer to that problem on kernel.org and added it to the wiki. kernel.org
ColdBug (talk) 09:23, 31 October 2016 (UTC)
Having trouble with an external monitor using a DisplayPort <-> USB-C cable. Anyone else seeing this? Monitor is detected fine by XPS, but no signal being sent by the XPS to the monitor.
I think you will need an active adapter to use that. I tried it with an combi adapter i bought from cable matters and could connect it via vga or hdmi withou any problem. Because i wanted to have a 4k display and 60 Hz i now bought an plugable thunderbolt to 2 times Display Port Adapter and will tell you how it works once i got it.
ColdBug (talk) 18:10, 1 November 2016 (UTC)
I have a similar problem using the official Dell adapter when going from USB-C to HDMI. Interestingly it works if I use 1280x800 or anything lower as the resolution but for anything above that I don’t get any output. The supported resolutions seem to be recognized correctly by xrandr.
cocreature (talk) 18:45, 1 November 2016 (UTC)
There is an open bug report for this issue. Unfortunatly it's unfixed for quite some time.
Kaueraal (talk) 14:13, 20 December 2016 (UTC)
So I am running the Anker Aluminium USB C to HDMI Adapter. I just plugged it in and it worked. I also got the HDMI to VGA Adapter from Ugreen (the active one) in case there is no HDMI available. It also worked right of the box. No need to change anything. I can link the products here if necessary.
uname -r 4.10.6-1-ARCH
janphilippi (talk) 16:05, 07 April 2017 (UTC)
Checkout bug report here [bugs.freedesktop.org/show_bug.cgi?id=93578] for details on fix for official Dell adapter. The patch should be pushed out on 4.11 or 4.12.
SnowLimit (talk) 17:52, 07 April 2017 (UTC)
Getting a lot of dmesg errors regarding some failure on pipe A
[ 1832.400184] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=109958 end=109959) time 277 us, min 1788, max 1799, scanline start 1772, end 1803 [ 1892.651578] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=113567 end=113568) time 379 us, min 1788, max 1799, scanline start 1773, end 1816 [ 1907.727072] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=114470 end=114471) time 373 us, min 1788, max 1799, scanline start 1786, end 1828
Following this link, I've verified that I was correctly running the microcodes (although no microcode is added)
$ sudo bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS - iucode_tool: system has processor(s) with signature 0x000806e9 microcode bundle 1: (stdin) selected microcodes: $
I tried to add i915.enable_psr=0 to my boot entry without success
title Arch Linux linux /vmlinuz-linux initrd /intel-ucode.img initrd /initramfs-linux.img options root=/dev/disk/by-label/ARCH_ROOT rw i915.enable_psr=0 timeout 4 editor 0
And I could confirm that while running `sudo intel_gpu_top` in a shell, no new error was thrown in dmesg.
Hasn't this happened to you guys?
--Fandekasp (talk) 02:29, 17 November 2016 (UTC)
I had the same with intel-ucode, enable_psr=1 disable_power_well=0. Now testing enable_psr=2
--Mal (talk) 03:21, 24 March 2017 (UTC)
Also seeing FIFO underruns but much more rarely.
[ 3556.126478] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
--Zorael (talk) 14:09, 27 March 2017 (UTC)
GPU hang kernel error
There seems a problem in the driver (4.8.7-nvme):
Nov 27 16:01:51 horizon kernel: [drm] GPU HANG: ecode 9:0:0x87d6fffe, in Xorg , reason: Hang on render ring, action: reset Nov 27 16:01:51 horizon kernel: [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. Nov 27 16:01:51 horizon kernel: [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel Nov 27 16:01:51 horizon kernel: [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. Nov 27 16:01:51 horizon kernel: [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. Nov 27 16:01:51 horizon kernel: [drm] GPU crash dump saved to /sys/class/drm/card0/error Nov 27 16:01:51 horizon kernel: drm/i915: Resetting chip after gpu hang Nov 27 16:01:51 horizon kernel: [drm] GuC firmware load skipped Nov 27 16:01:53 horizon kernel: [drm] RC6 on
This problem leads to a computer freeze (mouse, everything) for a few seconds and then things move on normally again.
... to be investigated. I'll post updates and put the bug link here, once I get around to it. 14:59, 1 December 2016 Tormen
Here's a bug I reported, which looks very similar:  , so this may have been fixed upstream (mesa). And this is not a kernel bug. Vladimir Pinchuk (talk) 11:02, 17 January 2019 (UTC)
Anyone else seeing an apparent race with bluetooth on resume (4.9.10)? Sometimes it works and sometimes it doesn't, leaving it in a state where it seems to be enabled but is useless, and giving errors when trying to power it back on. Sometimes merely suspending and resuming again fixes it, but not always. rfkill checks out. dmesg excerpt;
[359743.125259] Bluetooth: hci0 command 0x2011 tx timeout [359745.205270] Bluetooth: hci0 command 0x200b tx timeout [359747.285300] Bluetooth: hci0 command 0x200c tx timeout [359749.365579] Bluetooth: hci0 command 0x2011 tx timeout [359751.445385] Bluetooth: hci0 command 0x200b tx timeout [359753.525484] Bluetooth: hci0 command 0x200c tx timeout
The bluetoothd service also outputs errors like
Failed to set mode: Failed (0x03) to the systemd journal when calling
power on in
--Zorael (talk) 23:39, 5 March 2017 (UTC)
Add one observation. The Bluetooth device cannot be detected when I restarted the laptop as I did many times yesterday. Interestingly, it can be found properly if I start the laptop completely today.
$ lsusb Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 003: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc. Hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 006: ID 0bda:568b Realtek Semiconductor Corp. ******************** *Bus 001 Device 005: ID 0cf3:e300 Qualcomm Atheros Communications* ******************** Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 004: ID 413c:2113 Dell Computer Corp. Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I remembered that the bluetooth device didn't show up yesterday when my Bluetooth wasn't working in the "restart" mode.
--Tikilou (Tikilou) 00:36, 17 Sept 2018 (UTC)
I've founded something interesting about bluetooth, all of this (can't work after suspend...) is because this is an old firmware wich are integrated inside the linux-firmware package. If we download latest firmware, rename and replaces files in the right directory, everything work perfectly, without any problem. issue is here Maybe someone should contact the maintener of linux-firmware package about this update
Freeze on resume from suspend
Anyone else? It's happened about once a week - Open it and try to wake, it seems to resume but freezes. No C+A+F*, haven't had a keyboard with SysRQ handy to try that.
Haven't experienced this but AltGr + PrintScreen is SysRq (if you have AltGr).
--Zorael (talk) 13:38, 24 March 2017 (UTC)
USB-C Compatibility Chart
|Anker USB-C to HDMI Adapter||4K@60Hz HDMI||Working|
|Apple 29W USB-C Power Adapter||USB-C Power||Not Working|
|Apple 61W USB-C Power Adapter||USB-C Power||Working|
|Apple 87W USB-C Power Adapter||USB-C Power||Working|
|Apple Thunderbolt 3 (USB-C) to Thunderbolt 2 Adapter||Thunderbolt 2, Thunderbolt||Not Working|
|Apple USB-C Digital AV Multiport Adapter||USB-C, USB-A, HDMI||Mostly Working||Charging does not work (tested w/ Apple 87W Power Adapter)|
|ARP USB 3.1 C - DVI||DVI||Working|
|Aukey USB-C Hub HDMI 4 Port||USB-C, 4xUSB-A, HDMI||Working|
|Aukey Multiport USB-C Hub||USB-C, 2x USB, HDMI, VGA, SD card, micro SD card, Ethernet||Working|
|Belkin USB-C to VGA Adapter||VGA||Working|
|Cable Matters USB-C Multiport Adapter||4K HDMI or VGA, USB 3.0, Gigabit Ethernet||Working|
|Cable Matters USB-C to HDMI Adapter with Power Delivery||USB-C Power (60W PD), 4K@60Hz HDMI||Working|
|Caldigit TS3 Plus||USB-C Power, Gbit Ethernet, SPDIF, 5x USB-A (3.0), 2x USB-C (1x 3.1, 1x 3.0), DP (4K), audio 3.5mm in/out, TB3 daisy-chain (or monitor), SD 4.0 UHS-II||Working|
|Dell DA200||USB-A, Ethernet, HDMI (max. 1920x1080), VGA||Working|
|Dell TB16||USB-C Power, VGA, mDP, HDMI, DP, Thunderbolt, Ethernet (only 100Mbit Mode), 2x USB 2.0, 3x USB 3.0 (Disable Thunderbolt Security in BIOS)||Working|
|Dell WD15 130W||3xUSB-A 3.0, 2xUSB-A 2.0, Ethernet, HDMI, Mini DisplayPort, VGA, Line Out, Line In||Working|
|dodocool DC58 45W USB Type-C Wall Charger Power Adapter||USB-C Power||Working|
|Hama 135729 Multiport 4 in 1||2 X USB A, USB c, HDMI||Working|
|i-Tec USB 3.0 / USB-C 5K Universal Dual Display Docking Station||2x 4K 60Hz Video, 2x HDMI, 2x Display Port, 1x GLAN Ethernet, 6x USB-A 3.0, 1x Audio Input / Output||Working|
|i-Tec USB-C Dual Display MST Dock||HDMI, DP (4K@30Hz Single Monitor, 1920x1200@60Hz Dual Monitor), Gbit Ethernet, 3xUSB-A, USB-C, Sound, Charging @ 60W||Working|
|i-Tec USB-C Low Profile Docking Station||HDMI 4K@30Hz, SD Card Reader, Gigabit Ethernet, 3x USB-A, USB-C, USB-PD@60W||Working|
|i-Tec USB-C 4K Travel Docking Station Multi Adapter||4K HDMI, Gigabit Ethernet (RTL8153), 2x USB 3.0, 1x USB-C Power, 1x USB-C||Working|
|Innergie PowerGear USB-C 45||USB-C Power||Working|
|Juiced Systems BizHUB USB-C Multiport Gigabit HDMI Hub||4K@30Hz HDMI, 3x USB 3.0, Gigabit Ethernet, USB-C Power, SD, Micro-SD||Working|
|Kanex USB-C to HDMI 4K Adapter||HDMI||Working|
|LMP USB-C mini Dock||USB-C Power, Gigabit Ethernet, HDMI 4K, 3x USB 3.0, SD, microSD||Working||Retail price: 75€|
|Omars Type C Hub OMADTTCSL4PAL-UK||Gigabit Ethernet, HDMI (4K@30 Hz), VGA, 2x USB 3.0||Working|
|PCT UHC304||HDMI (4K@30Hz, 2K@60Hz), Gigabit Ethernet, USB-A, USB-C||Working|
|QacQoc GN30H USB-C HUB Aluminum Multi-Port TYPE C HUB Adapter with 4K HDMI||4K@30Hz HDMI, 3x USB 3.0, Gigabit Ethernet, USB-C Power, SD, Micro-SD||Working|
|RAVPower Type C USB Power Delivery Charger 36W||USB-C Power||Working|
|StarTech CDP2HD - USB-C to HDMI Adapter||HDMI||Working|
|StarTech TB32DP2 - Thunderbolt 3 Adapter||2 x DP (4 K, 60 Hz)||Working|
|StarTech TBT3TBTADAP - Thunderbolt 3 to Thunderbolt Adapter||Thunderbolt 2, Thunderbolt||Working|
|StarTech USB-C DP MST Hub||2x DP||Buggy||Takes a few tries, sometimes freezes GPU|
|Tripp Lite USB-C to DVI External Video Adapter||DVI, Gbit Ethernet, USB-A, USB-C PD Charging Port||Working|
|UCOUSO USB-C Aluminium HDMI Adapter mit HDMI (4K@30HZ) und 3 USB 3.0 Ports||HDMI, 3x USB 3.0||Working|
|UGREEN USB Type-C 30W Wall Charger With Power Delivery||USB-C Power||Not Working|
|Uni USB C to Ethernet Adapter||USB 3.0, Gigabit Ethernet||Working||Not actually thunderbolt, just usb 3.0|
|Xiaomi USB Type-C to HDMI Multifunction Adapter||4K HDMI, 1x USB 3.0, USB-C Power||Working|
|Xiaomi USB Type-C Clip On Car Charger Expansion||USB-C Power||Working|
Destroyed Display Panel
I destroyed my display panel by not being super-careful when doing Step 6. There was no clear indication from the tool that disables ABC whether it's working or had finished. I thought it had completed, so I prematurely powered down the computer.
I'm happy now after purchasing and installing the new display panel and finally succeding at disabling ABC by following these instructions. Strangely, however, the tool that disables ABC gave dozens of red "fail" messages while it was working on disabling ABC - seemingly properly judging from the good result. Also, flashing took quite a bit longer than I am used to - around 10-20 minutes.