Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Dell XPS 13 9310 #207

Merged
merged 16 commits into from Feb 27, 2021
Merged

Add Dell XPS 13 9310 #207

merged 16 commits into from Feb 27, 2021

Conversation

mitchmindtree
Copy link
Member

@mitchmindtree mitchmindtree commented Nov 14, 2020

After quite a few days of re-compiling the kernel with different patches and
rebooting my 9310 over and over, I'm finally opening this PR over wi-fi via
the on-board AX500 2x2!

I've had quite frequent spontaneous crashes since installing the QCA6390 firmware where
the whole system appears to freeze (twice while attempting to submit this PR).
Planning to look into this next.

Otherwise, everything appears to be working now other than:

  • Built-in microphone input. Earphones with a mic plugged in via the 3.5mm
    jack seem to work fine.
  • Bluetooth.
  • Fingerprint reader.

I have only tested this using the channel with
linuxPackages_testing which is using 5.10.0-rc2 as of writing this.

A big thanks to @kvalo for their work on the QCA6390 firmware and for helping me
to get this working.

W.r.t. the spontaneous crashes, I'm wondering if this section from the dmesg logs has
anything to do with it?

[    4.738943] ath11k_pci 0000:56:00.0: Respond mem req failed, result: 1, err: 0                                                                              
[    4.738945] ath11k_pci 0000:56:00.0: qmi failed to respond fw mem req:-22                                                                                   
[    4.739070] ath11k_pci 0000:56:00.0: req mem_seg[0] 0x5a100000 524288 1                                                                                     
[    4.739071] ath11k_pci 0000:56:00.0: req mem_seg[1] 0x5a180000 524288 1                                                                                     
[    4.739072] ath11k_pci 0000:56:00.0: req mem_seg[2] 0x5a200000 524288 1                                                                                     
[    4.739072] ath11k_pci 0000:56:00.0: req mem_seg[3] 0x5a280000 294912 1                                                                                     [    4.739073] ath11k_pci 0000:56:00.0: req mem_seg[4] 0x5a300000 524288 1                                                                                     
[    4.739073] ath11k_pci 0000:56:00.0: req mem_seg[5] 0x5a380000 524288 1                                                                                     
[    4.739074] ath11k_pci 0000:56:00.0: req mem_seg[6] 0x59c00000 458752 1                                                                                     
[    4.739074] ath11k_pci 0000:56:00.0: req mem_seg[7] 0x5a5c0000 131072 1                                                                                     [    4.739075] ath11k_pci 0000:56:00.0: req mem_seg[8] 0x59c80000 524288 4                                                                                     
[    4.739075] ath11k_pci 0000:56:00.0: req mem_seg[9] 0x59d00000 360448 4                                                                                     [    4.739076] ath11k_pci 0000:56:00.0: req mem_seg[10] 0x5a5a4000 16384 1                                                                                     
[    4.749134] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family 0xb board_id 0xff soc_id 0xffffffff                                                            
[    4.749136] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc fw_build_timestamp 2020-06-24 19:50 fw_build_id                                                  

On the most recent reboot, the wi-fi failed to initialise altogether for the first
time since installing the firmware:

[   34.312700] ath11k_pci 0000:56:00.0: failed to receive scan abort comple: timed out
[   34.312706] ath11k_pci 0000:56:00.0: failed to abort scan: -110
[   37.384665] ath11k_pci 0000:56:00.0: wmi command 12289 timeout
[   37.384667] ath11k_pci 0000:56:00.0: failed to send WMI_START_SCAN_CMDID
[   37.384670] ath11k_pci 0000:56:00.0: failed to start hw scan: -11
[   40.392710] ath11k_pci 0000:56:00.0: wmi command 20482 timeout
[   40.392713] ath11k_pci 0000:56:00.0: failed to submit WMI_VDEV_DELETE_CMDID
[   40.392718] ath11k_pci 0000:56:00.0: failed to delete WMI vdev 0: -11
[   43.400725] ath11k_pci 0000:56:00.0: wmi command 16387 timeout
[   43.400729] ath11k_pci 0000:56:00.0: failed to send WMI_PDEV_SET_PARAM cmd
[   43.400734] ath11k_pci 0000:56:00.0: failed to enable PMF QOS: (-11
[   46.408713] ath11k_pci 0000:56:00.0: wmi command 16387 timeout
[   46.408717] ath11k_pci 0000:56:00.0: failed to send WMI_PDEV_SET_PARAM cmd
[   46.408721] ath11k_pci 0000:56:00.0: failed to enable PMF QOS: (-11

@kvalo mentions how to enable debugging and tracing support for athllk using
make menuconfig here,
but I'm unsure how to do this in a declarative manner with nix? The nixos wiki
article
briefly mentions how to do this
interactively using nix-shell, but I'm not sure how to translate this into a
declarative config. Any advice on this would be appreciated.

@mitchmindtree
Copy link
Member Author

I should note that the XPS 13 9310 can come with one of two connectivity chips. One is the AX500 (what I have), and I think the other is AX1650. The AX1650 appears to be better supported, and is the one Dell ships with their Ubuntu certified laptops. It seems that the AX500 tends to ship with XPS 13 9310 devices that have 32GB RAM for some reason.

I'm still quite new to nix - can anyone recommend what the best approach would be to allow for specifying either of these chips with a configuration option?

Or perhaps the simplest approach is to leave out the QCA6390 firmware (necessary for the AX500) altogether, and instead require that users manually add hardware.firmware = [ qca6390-firmware ]; in the case they have a device with the AX500? I imagine this could be noted in a /dell/xps/13-9310/README.wiki.

Also, I believe both the AX500 and AX1650 provide both wi-fi and bluetooth, though since installing the QCA6390 driver my bluetooth hasn't yet shown any signs of life.


In other news, I've encountered a new error - my system didn't crash this time, but the internet dropped out and this repeated endlessly.

Nov 14 21:29:29 mindtree kernel: ath11k_pci 0000:56:00.0: failed to receive scan abort comple: timed out
Nov 14 21:29:29 mindtree kernel: ath11k_pci 0000:56:00.0: failed to abort scan: -110
Nov 14 21:30:02 mindtree wpa_supplicant[1242]: wlp86s0: CTRL-EVENT-SCAN-FAILED ret=-11 retry=1
Nov 14 21:30:02 mindtree kernel: ath11k_pci 0000:56:00.0: wmi command 12289 timeout
Nov 14 21:30:02 mindtree kernel: ath11k_pci 0000:56:00.0: failed to send WMI_START_SCAN_CMDID
Nov 14 21:30:02 mindtree kernel: ath11k_pci 0000:56:00.0: failed to start hw scan: -11
Nov 14 21:30:06 mindtree wpa_supplicant[1242]: wlp86s0: CTRL-EVENT-SCAN-FAILED ret=-11 retry=1
Nov 14 21:30:06 mindtree kernel: ath11k_pci 0000:56:00.0: wmi command 12289 timeout
Nov 14 21:30:06 mindtree kernel: ath11k_pci 0000:56:00.0: failed to send WMI_START_SCAN_CMDID
Nov 14 21:30:06 mindtree kernel: ath11k_pci 0000:56:00.0: failed to start hw scan: -11
Nov 14 21:30:10 mindtree wpa_supplicant[1242]: wlp86s0: CTRL-EVENT-SCAN-FAILED ret=-11 retry=1
Nov 14 21:30:10 mindtree kernel: ath11k_pci 0000:56:00.0: wmi command 12289 timeout
Nov 14 21:30:10 mindtree kernel: ath11k_pci 0000:56:00.0: failed to send WMI_START_SCAN_CMDID
Nov 14 21:30:10 mindtree kernel: ath11k_pci 0000:56:00.0: failed to start hw scan: -11
Nov 14 21:30:14 mindtree wpa_supplicant[1242]: wlp86s0: CTRL-EVENT-SCAN-FAILED ret=-11 retry=1
Nov 14 21:30:14 mindtree kernel: ath11k_pci 0000:56:00.0: wmi command 12289 timeout
Nov 14 21:30:14 mindtree kernel: ath11k_pci 0000:56:00.0: failed to send WMI_START_SCAN_CMDID
Nov 14 21:30:14 mindtree kernel: ath11k_pci 0000:56:00.0: failed to start hw scan: -11
Nov 14 21:30:18 mindtree wpa_supplicant[1242]: wlp86s0: CTRL-EVENT-SCAN-FAILED ret=-11 retry=1
Nov 14 21:30:18 mindtree kernel: ath11k_pci 0000:56:00.0: wmi command 12289 timeout
Nov 14 21:30:18 mindtree kernel: ath11k_pci 0000:56:00.0: failed to send WMI_START_SCAN_CMDID
Nov 14 21:30:18 mindtree kernel: ath11k_pci 0000:56:00.0: failed to start hw scan: -11

Then when I turned off wi-fi via the GNOME menu it froze for a few seconds and this was emitted.

Nov 14 21:45:38 mindtree kernel: wlp86s0: deauthenticating from 1c:b0:44:ec:96:c0 by local choice (Reason: 3=DEAUTH_LEAVING)
Nov 14 21:45:41 mindtree kernel: ath11k_pci 0000:56:00.0: wmi command 28680 timeout
Nov 14 21:45:41 mindtree kernel: ath11k_pci 0000:56:00.0: failed to submit WMI_MGMT_TX_SEND_CMDID cmd
Nov 14 21:45:41 mindtree kernel: ath11k_pci 0000:56:00.0: failed to send mgmt frame: -11
Nov 14 21:45:41 mindtree kernel: ath11k_pci 0000:56:00.0: failed to tx mgmt frame, vdev_id 0 :-11
Nov 14 21:45:43 mindtree kernel: ath11k_pci 0000:56:00.0: failed to flush transmit queue 0
Nov 14 21:45:46 mindtree kernel: ath11k_pci 0000:56:00.0: wmi command 24595 timeout
Nov 14 21:45:46 mindtree kernel: ath11k_pci 0000:56:00.0: failed to send WMI_PEER_REORDER_QUEUE_SETUP
Nov 14 21:45:46 mindtree kernel: ath11k_pci 0000:56:00.0: failed to send wmi to delete rx tid -11
Nov 14 21:45:46 mindtree kernel: wlp86s0: HW problem - can not stop rx aggregation for 1c:b0:44:ec:96:c0 tid 0

@w1nk
Copy link

w1nk commented Nov 16, 2020

hi @mitchmindtree ! I'm part of the ath11k mailing list thread as well. I didn't have a good platform to respond there, but my bluetooth works without any additional configuration on an install of ubuntu 20.10. I'm not sure it's the same chip controlling it fwiw.

edit to add - my understanding of the 9310 is the same as yours...we got the ax500 because it has 32gb of ram

@mitchmindtree
Copy link
Member Author

@w1nk ah interesting, thanks for the tip! I wonder if perhaps Ubuntu ships an extra driver or firmware to get bluetooth working...

It would be great if we could see what chip is being used for bluetooth in your working setup! Does anything interesting show up if you run dmesg | grep -i blue or lsusb -v | grep -i blue?

@w1nk
Copy link

w1nk commented Nov 16, 2020

I checked dmesg, and it looks like you're correct re: the QCA controlling bluetooth, but I see a different set of firmware being loaded for it:

[ 2.349008] Bluetooth: Core ver 2.22
[ 2.349019] Bluetooth: HCI device and connection manager initialized
[ 2.349023] Bluetooth: HCI socket layer initialized
[ 2.349024] Bluetooth: L2CAP socket layer initialized
[ 2.349028] Bluetooth: SCO socket layer initialized
[ 2.394642] Bluetooth: HCI UART driver ver 2.3
[ 2.394644] Bluetooth: HCI UART protocol H4 registered
[ 2.394645] Bluetooth: HCI UART protocol BCSP registered
[ 2.394654] Bluetooth: HCI UART protocol LL registered
[ 2.394655] Bluetooth: HCI UART protocol ATH3K registered
[ 2.394660] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 2.394702] Bluetooth: HCI UART protocol Intel registered
[ 2.394734] Bluetooth: HCI UART protocol Broadcom registered
[ 2.394742] Bluetooth: HCI UART protocol QCA registered
[ 2.394743] Bluetooth: HCI UART protocol AG6XX registered
[ 2.394748] Bluetooth: HCI UART protocol Marvell registered
[ 2.416321] Bluetooth: hci0: setting up ROME/QCA6390
[ 2.420348] Bluetooth: hci0: Frame reassembly failed (-84)
[ 2.444937] Modules linked in: snd_pcm qrtr ns snd_seq_midi snd_seq_midi_event ath11k_pci(+) mhi snd_rawmidi ath11k hci_uart qmi_helpers btqca i915(+) snd_seq btrtl uvcvideo mac80211 snd_seq_device btbcm btintel snd_timer videobuf2_vmalloc dell_wmi drm_kms_helper input_leds videobuf2_memops dell_smbios videobuf2_v4l2 cec dcdbas snd efi_pstore serio_raw rc_core videobuf2_common hid_sensor_als i2c_algo_bit hid_sensor_trigger ucsi_acpi(+) cfg80211 fb_sys_fops industrialio_triggered_buffer processor_thermal_device typec_ucsi dell_wmi_descriptor kfifo_buf hid_sensor_iio_common intel_rapl_common soundcore industrialio wmi_bmof videodev mei_me libarc4 syscopyarea cros_ec_ishtp 8250_dw mc hid_multitouch sysfillrect mei cros_ec sysimgblt intel_soc_dts_iosf typec mac_hid bluetooth ecdh_generic ecc int3403_thermal int340x_thermal_zone acpi_pad intel_hid acpi_tad int3400_thermal acpi_thermal_rel sparse_keymap sch_fq_codel parport_pc ppdev drm lp parport ip_tables x_tables autofs4 hid_sensor_hub
[ 2.756645] Bluetooth: hci0: QCA Product ID :0x00000010
[ 2.756647] Bluetooth: hci0: QCA SOC Version :0x400a0200
[ 2.756647] Bluetooth: hci0: QCA ROM Version :0x00000200
[ 2.756648] Bluetooth: hci0: QCA Patch Version:0x00000d2b
[ 2.756650] Bluetooth: hci0: QCA controller version 0x02000200
[ 2.756651] Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv
[ 3.584055] Bluetooth: hci0: QCA Downloading qca/htnv20.bin
[ 3.777754] Bluetooth: hci0: QCA setup on UART is completed
[ 3.998318] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 3.998319] Bluetooth: BNEP filters: protocol multicast
[ 3.998321] Bluetooth: BNEP socket layer initialized
[ 14.108234] Bluetooth: RFCOMM TTY layer initialized
[ 14.108238] Bluetooth: RFCOMM socket layer initialized
[ 14.108242] Bluetooth: RFCOMM ver 1.11

lsmod | grep -i qca
reports these modules:
btqca
bluetooth

dell/xps/13-9310/default.nix Outdated Show resolved Hide resolved
../../../common/pc/laptop
];

# TODO: upstream to NixOS/nixpkgs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should make this upstream before merging this into nixos hardware.

# TODO: Remove this once landed in kernel.
# Apply kernel patch for xps 9310 wifi bug.
# https://patchwork.kernel.org/project/linux-wireless/patch/1605121102-14352-1-git-send-email-kvalo@codeaurora.org/
boot.kernelPatches = [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With all these kernel patches in place we should probably set a specific kernel as they likely are no longer apply to a later one.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review!

Currently kvalo's patches are based on 5.10-rc4, but I can't see an "official" linuxPackages_5_10_rc4 or anything like this in nixpkgs. I'm thinking that instead I'll point boot.kernelPackages directly to kvalo's branch until all of these patches land in mainline. This would mean the nix expr will clone the whole kernel and building it locally though, but it's probably worth the improved reliability. I'll push an update for this soon, but let me know if there's a nicer way of achieving this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can probably set boot.kernelPackages to the output of buildLinux with the version set back to rc4.

That said, they applied to rc5. knocks wood

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can probably set boot.kernelPackages to the output of buildLinux with the version set back to rc4.

Good idea! Do you know of an easier way to point to this version of linuxPackages while also applying kvalo's patches that doesn't involve linking a unique patch for each commit like I'm currently doing? E.g. perhaps there is some nicer way of specifying a single patch that links to the diff between kvalo's branch and rc4? I figure I could manually create and upload this diff somewhere, but thought that surely git.kernel.org must already provide some link for this that I'm missing?

Otherwise, I might just point to kvalo's branch to make maintaining this a bit easier, as they seem to be pushing new commits quite regularly.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK, you're doing it the correct way. My understanding is kvalo's branch is tracking just ath-next, which may be out of sync with improvements to other parts of the kernel.

@terinjokes
Copy link
Contributor

I've had quite frequent spontaneous crashes

What are the symptoms of these crashes? I've had issues where the display has brief corruption or goes completely black until I close the lid or power cycle. But I also had these in Dell's Windows install.

@w1nk
Copy link

w1nk commented Dec 2, 2020

@terinjokes I also see occasional random screen glitches, which are always matched with some dmesg chatter from the i915 driver, usually about some kind of DRM buffer underruns. If you check your dmesg, I'd guess you'll see similar.

I believe the crashes he's referring to are coming from the ATH11K PCI wifi driver. We've been chasing them on that mailing list for a few weeks. When the adapter is coming online, there is a potential race that occurs and if so, the driver will spin lock everything. However if it wins the race, it seems the machine will stay stable.

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/trouble-enabling-the-btqca-driver-module-in-the-linux-kernel-using-kernelpatches/10316/1

@mitchmindtree
Copy link
Member Author

It looks like the Arch wiki just got an XPS 9310 entry:

https://wiki.archlinux.org/index.php/Dell_XPS_13_(9310)

While it's still pretty bare, it does have some info on getting the fingerprint reader working using a "proprietary Ubuntu driver released by Dell and Goodix". I probably won't look into this myself, but this might be useful for anyone interested in getting this working.

@mitchmindtree
Copy link
Member Author

mitchmindtree commented Dec 7, 2020

Bluetooth

I'm yet to get Bluetooth working. You can find my bluetooth WIP branch here.

  • I've added a kernel patch that enables some extra bluetooth modules here.
  • I've tried to include the bt firmware showing up in @w1nk's log. I'm not sure if it's necessary to fetch it from the kernel's linux-firmware repo like I'm doing, or if there's a more ergonomic way to use firmware from the linux-firmware in NixOS? The install directory inside the buildCommand stage is a wild guess, largely based on how kvalo's wifi driver is installed (see qca6390-firmware.nix).

I can see these modules are getting built and loaded now, however for some reason the firmware is not getting loaded yet.

[mindtree@mindtree:~]$ dmesg | grep -i bluetooth
[    3.599287] Bluetooth: Core ver 2.22
[    3.599301] Bluetooth: HCI device and connection manager initialized
[    3.599304] Bluetooth: HCI socket layer initialized
[    3.599306] Bluetooth: L2CAP socket layer initialized
[    3.599309] Bluetooth: SCO socket layer initialized
[    3.619715] Bluetooth: HCI UART driver ver 2.3
[    3.619717] Bluetooth: HCI UART protocol H4 registered
[    3.619717] Bluetooth: HCI UART protocol BCSP registered
[    3.619725] Bluetooth: HCI UART protocol LL registered
[    3.619729] Bluetooth: HCI UART protocol QCA registered
[   48.990643] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   48.990649] Bluetooth: BNEP socket layer initialized

In w1nk's log, they also observe some hci0 bluetooth messages in their dmesg output following this that I am not seeing:

[ 2.416321] Bluetooth: hci0: setting up ROME/QCA6390
[ 2.420348] Bluetooth: hci0: Frame reassembly failed (-84)
...
[ 2.756645] Bluetooth: hci0: QCA Product ID :0x00000010
[ 2.756647] Bluetooth: hci0: QCA SOC Version :0x400a0200
[ 2.756647] Bluetooth: hci0: QCA ROM Version :0x00000200
[ 2.756648] Bluetooth: hci0: QCA Patch Version:0x00000d2b
[ 2.756650] Bluetooth: hci0: QCA controller version 0x02000200
[ 2.756651] Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv
[ 3.584055] Bluetooth: hci0: QCA Downloading qca/htnv20.bin
[ 3.777754] Bluetooth: hci0: QCA setup on UART is completed

Fwiw, I do have bluetooth enabled in my configuration.nix too:

  hardware.bluetooth.enable = true;

Any ideas on what I might be missing here would be appreciated.


I just stumbled across the nixos common configuration, leaving it here as a reminder for myself to check against the debian and arch configurations, as users on those distros appear to have bluetooth working:

https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/common-config.nix

Edit: And here's the Arch kernel config with which BT is apparently working out of the box:

https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux

@mitchmindtree
Copy link
Member Author

I've just added a couple of patches by @w1nk that appear to completely stabilize wifi! Feel free to read the commit and linked discussion in the archive for more details. d615901

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-to-include-and-use-external-firmware-in-nixos-config-bluetooth-for-qca6390/10471/1

@mitchmindtree
Copy link
Member Author

I'm at a bit of a loss on how to progress on the Bluetooth front, likely due to a lack of my experience in configuring the kernel. I've asked for help on the linux stack exchange here and in the NixOS forums (linked above by the nixos-discourse bot).

@terinjokes
Copy link
Contributor

terinjokes commented Dec 29, 2020

@mitchmindtree I make no promises, but I'm taking a look now. Do we have patches available for a releases version of 5.10?

@mitchmindtree
Copy link
Member Author

mitchmindtree commented Dec 29, 2020

Thanks!

Do we have patches available for a releases version of 5.10?

Yes, you can find my bluetooth WIP branch here which also includes the update to use 5.10 (currently 5.10.2 on my machine). A couple of the patches were changed slightly during the rebase, but everything seems stable in terms of wifi - Edit: in terms of behaviour at least, the ath11k mailing list still seems unsure about why disabling this MHI state works so well.

@terinjokes
Copy link
Contributor

Yes, you can find my bluetooth WIP branch here which also includes the update to use 5.10 (currently 5.10.2 on my machine).

It would be awesome to get this branch updated, as getting this merged if, even sans Bluetooth, would still be super useful.

I'm currently rebuilding the kernel with a few config options enabled.

@mitchmindtree
Copy link
Member Author

Okydoke, I've pushed a commit that switches to linuxPackages_5_10 along with the rebased patches. I'll rebase my xps-9310-bt-wip branch onto this.

CI failure seems unrelated, specific to raspberry pi.

Is it safe to point to linuxPackages_5_10 like this? Or should I switch back to using buildLinux and fix this to a particular commit? I'm not sure how these linuxPackages with appended versions are updated.

getting this merged if, even sans Bluetooth, would still be super useful.

I'm not sure what the maintainers' thoughts are on including modules with so many kernel patches and relying on a specific version of the kernel, but I'm happy for this to get merged whenever, as we can always open issues & follow-up PRs for the rest of the work?

@mitchmindtree mitchmindtree marked this pull request as ready for review December 29, 2020 01:55
@terinjokes
Copy link
Contributor

terinjokes commented Dec 29, 2020

I'm not a maintainer of this repository, so take my answers with a grain of salt.

Is it safe to point to linuxPackages_5_10 like this?

It might be reasonable to adopt a strategy similar to the T495?

I'm not sure what the maintainers' thoughts are on including modules with so many kernel patches

It might be best to have to it be an optional nix file users have to include, similar to the usbarmory. It's the only other example with extra patches.

@terinjokes
Copy link
Contributor

I don't think there's anything wrong with any firmware packaging in Nix. In my investigations so far, the kernel code to load the QCA6390 firmware is never reached.

None of my breakpoints in the hci_qca driver are hit, so it's as if Linux doesn't see any hardware to initialize.

I'll keep debugging.

@terinjokes
Copy link
Contributor

One different I saw between Arch and NixOS was the output of lspci -k on NixOS denoting that the card was handled by the ath11k_pci driver. I reverted back to 5.9, which made the output of lspci -k the same, but still no luck in getting the card initialized.

@terinjokes
Copy link
Contributor

I've installed testing/linux-5.10.3 (along with linux-firmware) on Arch Linux, and I see the same behavior as Arch on 5.9.

I've removed the firmware to try to confirm my theory it's not even being loaded. The error behavior is entirely different to what we see in NixOS.

[ 107.416321] Bluetooth: hci0: setting up ROME/QCA6390
[ 107.756645] Bluetooth: hci0: QCA Product ID :0x00000010
[ 107.756647] Bluetooth: hci0: QCA SOC Version :0x400a0200
[ 107.756647] Bluetooth: hci0: QCA ROM Version :0x00000200
[ 107.756648] Bluetooth: hci0: QCA Patch Version:0x00000d2b
[ 107.756650] Bluetooth: hci0: QCA controller version 0x02000200
[ 107.756651] Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv
[ 108.584055] Bluetooth: hci0: QCA Downloading qca/htnv20.bin
[ 108.704956] Bluetooth hci0: Direct firmware load for qca/htnv20.bin failed with error -2
[ 108.704959] Bluetooth: hci0: QCA Failed to request file: qca/htnv20.bin (-2)
[ 108.705086] Bluetooth: hci0: QCA Failed to download NVM (-2)

@Mic92
Copy link
Member

Mic92 commented Dec 30, 2020

Okydoke, I've pushed a commit that switches to linuxPackages_5_10 along with the rebased patches. I'll rebase my xps-9310-bt-wip branch onto this.

CI failure seems unrelated, specific to raspberry pi.

Is it safe to point to linuxPackages_5_10 like this? Or should I switch back to using buildLinux and fix this to a particular commit? I'm not sure how these linuxPackages with appended versions are updated.

I think buildLinux is safer here for now. Kernel can come and go - especially non-lts versions. We also backport kernel updates.

getting this merged if, even sans Bluetooth, would still be super useful.

I'm not sure what the maintainers' thoughts are on including modules with so many kernel patches and relying on a specific version of the kernel, but I'm happy for this to get merged whenever, as we can always open issues & follow-up PRs for the rest of the work?

@mitchmindtree
Copy link
Member Author

I expect most people testing this are/were running unstable.

Likewise, I've been running unstable, though do look forward to switching to a stable branch one day, maybe when 21.05 is out.

WiFi works out-of-the-box with the latest kernel, btw.

Wow that's great news! Could you confirm that you have the xps 9310 with the QCA6390 chip? Could you possibly post the output of both dmesg | grep -i qca6390 and nix-shell -p nix-info --run "nix-info -m"?

@hmenke
Copy link
Member

hmenke commented Mar 24, 2021

It doesn't seem to be the QCA6390 chip. According to lspci it is

0000:00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201 (rev 20)

which uses the iwlwifi driver. On the Arch Wiki is says that the XPS 13 9310 is available with either AX201 or AX500, but I don't see how to tell which one you are going to get when buying the laptop.

@terinjokes
Copy link
Contributor

If you buy from dell.com, it should appear on the customization page, albeit it's not selectable. (AFAIK, the ArchWiki page is technically wrong: you have a Killer WiFi AX1650, not an Intel AX201, they're close but not exactly the same)

If you (or your corporate IT) buy through a Dell reseller or systems integrator, good luck in getting this information. It seems everything but the 32GB model is getting the AX1650 currently, but Dell may change at any moment.

@hmenke
Copy link
Member

hmenke commented Mar 24, 2021

In that case, I consider myself lucky to have working WiFi. :)

@hmenke
Copy link
Member

hmenke commented Mar 25, 2021

Is S3 sleep working on unstable? On NixOS 20.09 I only have

$ cat /sys/power/mem_sleep 
[s2idle]

which is pretty bad. I've made sure that "Block sleep" option is set to OFF in the BIOS. "Sign of Life" is also disabled.

@rowanG077
Copy link
Member

Yep I have the same.

@terinjokes
Copy link
Contributor

Dell no longer includes S3 support in firmware of new laptops. This is to support the Windows "Modern Standby" feature. The running system is expected to properly power toggle hardware components as needed.

@mitchmindtree
Copy link
Member Author

Hi folks, anyone tried the latest firmware updates via fwupdmgr yet?

I'm still on 00.1.1.4, but looks like there's already been a few updates since:

https://fwupd.org/lvfs/devices/com.dell.ueficfb08d7c.firmware

There's a couple mentions of idle-state fixes. Thinking I might try updating later today.

I wish we could update firmware as fearlessly as we can update NixOS 😅

@hmenke
Copy link
Member

hmenke commented Apr 9, 2021

I successfully performed a firmware update from (don't remember) -> 2.0.0 when I first got the machine and another one from 2.0.0 -> 2.1.1 just now. BTW, fwupd maintains rollback information in case the update fails. So unless it bricks the entire EFI boot, it should be pretty safe.

@nitsky
Copy link

nitsky commented Apr 12, 2021

Hi, I have an XPS 9310 with the AX201 chip, but I am unable to get wifi working. I expected it to work without the patches in this PR because it is not the AX500.

I have tried kernel versions 5.10.27 and 5.11.11. dmesg | grep iwlwifi shows "direct firmware load for iwlwifi-***.ucode failed with error -2" and "no suitable firmware found".

Does anyone here have any ideas how to resolve this?

@mitchmindtree
Copy link
Member Author

@nitsky could you share the output of nix-shell -p nix-info --run "nix-info -m"?

dmesg | grep iwlwifi shows "direct firmware load for iwlwifi-***.ucode failed with error -2" and "no suitable firmware found".

You might need to add this line to your nix config to enable inclusion of the necessary firmware:

hardware.enableRedistributableFirmware = true;

@nitsky
Copy link

nitsky commented Apr 12, 2021

@mitchmindtree enabling redistributable firmware did it, thank you so much!! :)

May I ask if you have a suggested workaround for the lack of S3 deep sleep?

@mitchmindtree
Copy link
Member Author

mitchmindtree commented Apr 12, 2021

Glad to hear it!

May I ask if you have a suggested workaround for the lack of S3 deep sleep?

Embarrassingly, I'm afraid I don't properly understand what the issue is here and I'm yet to look into and understand how the levels of "sleep" in Linux work. Maybe someone else will chime in with an idea or PR?

@terinjokes
Copy link
Contributor

Maybe someone else will chime in with an idea or PR?

I've tried tuning things, but the only thing that seems to work without significant battery drain is systemctl poweroff. In theory the kernel should shutdown peripherals and put them in low power states, I've just never gotten that working (and judging from forum posts and a recent HN thread, others haven't either).

@terinjokes
Copy link
Contributor

Sorry for bumping this thread again. Has anyone had any luck with kernels newer than 5.10.18?

@luka5
Copy link

luka5 commented May 18, 2021

Sorry for bumping this thread again. Has anyone had any luck with kernels newer than 5.10.18?

I've tried 5.12 from nixos-unstable on the weekend and my wifi was not working. Maybe I did something wrong.

@rien
Copy link

rien commented May 18, 2021

I also have issues with kernel version newer than 5.11.14, I have created an issue over at NixOS/nixpkgs#123025.

@terinjokes
Copy link
Contributor

@luka5 @rien FWIW, in the Arch partition I have for testing, the wireless device stopped appearing once I upgraded to 5.12 from 5.10, so that might not be a NixOS issue.

@Mic92
Copy link
Member

Mic92 commented May 18, 2021

Until this issue is resolved the xps config could pin an older kernel?
If someone is keen enough to do git bisect on the linux kernel, I could also provide some guidance.

@mitchmindtree
Copy link
Member Author

Until this issue is resolved the xps config could pin an older kernel?

Yeah I believe the XPS 9310 config is still pinned to 5.10.18 - I think that's why @terinjokes initially asked if it's working on anything newer yet.

That said if anyone has got their xps 9310 (in particular, with the QCA6390) working on a newer version, a PR here updating the pinned version to the latest known working version would be appreciated :)

@w1nk
Copy link

w1nk commented May 20, 2021 via email

@terinjokes
Copy link
Contributor

Yeah I believe the XPS 9310 config is still pinned to 5.10.18 - I think that's why @terinjokes initially asked if it's working on anything newer yet.

Yep, and I'm hoping at some point I stop having to build the kernel on my laptop, usually at inconvenient times.

@terinjokes
Copy link
Contributor

I've found that the system seems reasonably stable on 5.12.11.

{ config, pkgs, lib, ...}:
{
  imports = [
    <nixos-hardware/dell/xps/13-9310>
    ./hardware-configuration.nix
  ];
  
  # mkForce to override the non-optional boot.kernelPackages set by the overlay.
  boot.kernelPackages = lib.mkForce pkgs.linuxPackages_latest;
  # we still need to upstream this change
  boot.kernelPatches = [{
    name = "enable-qca6390-bluetooth";
    patch = null;
    extraConfig = ''
      BT_QCA m
      BT_HCIUART m
      BT_HCIUART_QCA y
      BT_HCIUART_SERDEV y
      SERIAL_DEV_BUS y
      SERIAL_DEV_CTRL_TTYPORT y
    '';
  }];
  
  // ...
}

If this works for someone else, I can put together a PR to update this repository (and probably another one upstream for Bluetooth).

@luka5
Copy link

luka5 commented Jun 22, 2021

I built nixos-21.05 with the latest kernel 5.12.11 and the bluetooth patch right now. I can confirm: wifi and bluetooth work for me. Also built-in microphone and speaker works. A PR to update would be great @terinjokes

@hmenke
Copy link
Member

hmenke commented Jul 22, 2021

Further abusing this PR as a support thread: If anyone has issues with the display flickering, that is because recent kernels broke the Panel Self Refresh in the Intel driver. A workaround is

{
  boot.kernelParams = [ "i915.enable_psr=0" ];
}

@terinjokes
Copy link
Contributor

@hmenke Is your audio working on a kernel newer than 5.12.11? Trying to figure out what stopped working is what's blocking me from opening a new PR.

@hmenke
Copy link
Member

hmenke commented Jul 22, 2021

@terinjokes I'm still on kernel 5.10.50 because 5.12 was causing all kinds of other issues for me. Most annoyingly the boot process suddenly took twice as long.

@terinjokes
Copy link
Contributor

Hmm, interesting. So far the only issue I've noticed past 5.12.11 is the onboard audio not coming up correctly. It boots just as quickly as it did on previous versions.

@terinjokes
Copy link
Contributor

Everything is working fine for me on 5.12.19. I've opened #298.

@mitchmindtree
Copy link
Member Author

mitchmindtree commented Nov 25, 2021

I've upstreamed the kernel config patches in case anyone would like to test:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants