Add Dell XPS 13 9310 #207
Add Dell XPS 13 9310 #207
Conversation
|
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 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. Then when I turned off wi-fi via the GNOME menu it froze for a few seconds and this was emitted. |
|
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 |
|
@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 |
|
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 lsmod | grep -i qca |
dell/xps/13-9310/default.nix
Outdated
| ../../../common/pc/laptop | ||
| ]; | ||
|
|
||
| # TODO: upstream to NixOS/nixpkgs |
There was a problem hiding this comment.
I think we should make this upstream before merging this into nixos hardware.
dell/xps/13-9310/default.nix
Outdated
| # 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 = [ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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. |
|
@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. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
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. |
BluetoothI'm yet to get Bluetooth working. You can find my bluetooth WIP branch here.
I can see these modules are getting built and loaded now, however for some reason the firmware is not getting loaded yet. In w1nk's log, they also observe some Fwiw, I do have bluetooth enabled in my 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 |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
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). |
|
@mitchmindtree I make no promises, but I'm taking a look now. Do we have patches available for a releases version of 5.10? |
|
Thanks!
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. |
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
force-pushed
the
xps-9310
branch
from
eda316b to
42d45c1
Compare
|
Okydoke, I've pushed a commit that switches to CI failure seems unrelated, specific to raspberry pi. Is it safe to point to
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? |
|
I'm not a maintainer of this repository, so take my answers with a grain of salt.
It might be reasonable to adopt a strategy similar to the T495?
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. |
|
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. |
|
One different I saw between Arch and NixOS was the output of |
|
I've installed 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. |
I think buildLinux is safer here for now. Kernel can come and go - especially non-lts versions. We also backport kernel updates.
|
Likewise, I've been running unstable, though do look forward to switching to a stable branch one day, maybe when 21.05 is out.
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 |
|
It doesn't seem to be the QCA6390 chip. According to which uses the |
|
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. |
|
In that case, I consider myself lucky to have working WiFi. :) |
|
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. |
|
Yep I have the same. |
|
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. |
|
Hi folks, anyone tried the latest firmware updates via I'm still on 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 😅 |
|
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. |
|
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. Does anyone here have any ideas how to resolve this? |
|
@nitsky could you share the output of
You might need to add this line to your nix config to enable inclusion of the necessary firmware: hardware.enableRedistributableFirmware = true; |
|
@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? |
|
Glad to hear it!
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? |
I've tried tuning things, but the only thing that seems to work without significant battery drain is |
|
Sorry for bumping this thread again. Has anyone had any luck with kernels newer than 5.10.18? |
I've tried |
|
I also have issues with kernel version newer than 5.11.14, I have created an issue over at NixOS/nixpkgs#123025. |
|
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 :) |
|
Hey guys,
I don't run nix, but I get notified on this thread due to some
involvement with the XPS work. If you check the latest mailing list, you
can see the ath11k driver was having some issues on the newest kernels
they're working on reverting through. That may be the cause of some of the
issues. That said, I'm running 5.12.0 without any issues.
…On Thu, May 20, 2021 at 9:25 PM mitchmindtree ***@***.***> wrote:
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 <https://github.com/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 :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#207 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACLEHN3Z7YMGT2HHUG4S63TOVO4NANCNFSM4TVW4OIA>
.
|
Yep, and I'm hoping at some point I stop having to build the kernel on my laptop, usually at inconvenient times. |
|
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). |
|
I built |
|
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" ];
} |
|
@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. |
|
@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. |
|
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. |
|
Everything is working fine for me on 5.12.19. I've opened #298. |
|
I've upstreamed the kernel config patches in case anyone would like to test: |
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:
jack seem to work fine.
I have only tested this using the channel with
linuxPackages_testingwhich is using5.10.0-rc2as 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?
On the most recent reboot, the wi-fi failed to initialise altogether for the first
time since installing the firmware:
@kvalo mentions how to enable debugging and tracing support for athllk using
make menuconfighere,but I'm unsure how to do this in a declarative manner with
nix? The nixos wikiarticle briefly mentions how to do this
interactively using
nix-shell, but I'm not sure how to translate this into adeclarative config. Any advice on this would be appreciated.