i'm not developer or maintainer and i don't have expert opinion, but i think the problem with NVMe the problem is with linux firmware and linux current kernel. Once again i'm not an expert, just thoughts on the go

Hey everyone,

Just an update. Today I spent some time trimming down our config to the bare essentials for my machine specifically, to minimize build times as I looked into this issue. With the latest release of 5.10.0-rc1, I opted to test against this, not bothering to immediately rebase our patches in the event it didn't resolve my NVMe namespaces to begin with.

Fortunately, I have some good news. I can confirm that this build of the kernel resolved our NVMe namespaces. After this, I passed it off to @DataDrake and @Girtablulu, which both have similar or identical (depending on the person) Samsung controllers for their NVMe drives as I do, and they both validated that their namespaces were also being resolved and they were able to boot into the desktop! @DataDrake 's logging documentation was also invaluable to validating that it was actually fixed and my initial issues were elsewhere (failing to reach the login screen made me suspicious initially), so massive thanks to him. I would've wasted countless hours otherwise ❤️

From this point, I went and rebased our kernel patches (such as for apparmor confinement, ELANtech touchpad support, etc.) then copied and updated our 5.6 kernel config for 5.10. I've listed some of the features / flags I've enabled below:

  • ZSTD Compression. Changed from lz4 to zstd for default.
  • Enabled
    • ACPI_DPTF: Intel DPTF (Dynamic Platform and Thermal Framework) Support
    • APPLE_MFI_FASTCHARGE: Fast charge control for iOS devices
    • BRIDGE_MRP: Enables ethernet bridges to run MRP protocol to detect loops
    • DM_MULTIPATH_HST: I/O Path Selector based on historical service time
    • DPTF_PCH_FIVR: Dynamic Platform and Thermal Framework (DPTF) PCH FIVR Participant device support
    • DRM_AMD_DC_DCN3_0: AMD sienna_cichlid DCN 3.0 family support
    • INTEL_SOC_PMIC_BXTWC: Support for Intel Broxton Whiskey Cove PMIC
    • MFD_INTEL_PMC_BXT: Intel PMC Driver for Broxton and Apollo Lake
    • MMC_HSQ: Selects the MMC Host Software Queue support. This may increase performance, if the host controller and its driver supports it.
    • MT7663U: MediaTek MT7663U (USB) support
    • NVME_TARGET_PASSTHRU: NVMe Target Passthrough support
    • PINCTRL_EMMITSBURG: Intel Emmitsburg pinctrl and GPIO driver
    • PINCTRL_JASPERLAKE: Intel Jasper Lake PCH pinctrl and GPIO driver
    • RMI4_F3A: RMI4 Function 3A (GPIO)
    • RTW88_8723DE: Realtek 8723DE PCI wireless network adapter
    • RTW88_8821CE: Realtek 8821CE PCI wireless network adapter
    • SENSORS_AMD_ENERGY: AMD RAPL MSR based Energy driver
    • SND_HDA_INTEL_HDMI_SILENT_STREAM: Intel hardware has a feature called 'silent stream', that keeps external HDMI receiver's analog circuitry powered on avoiding 2-3 sec silence during playback start. This mechanism relies on setting channel_id as 0xf, sending info packet and preventing codec D3 entry (increasing platform static power consumption when HDMI receiver is plugged-in). 2-3 sec silence at the playback start is expected whenever there is format change.
    • SND_SOC_AMD_RENOIR: AMD Audio Coprocessor - Renoir support
    • SND_SOC_AMD_RV_RT5682_MACH: AMD RV support for RT5682
    • SND_SOC_INTEL_CATPT: Intel Haswell and Broadcom support with I2S codec present.
    • SND_SOC_INTEL_SOF_PCM512x_MACH: Adds support for ASoC machine driver for SOF platforms with TI PCM512x I2S audio codec.
    • SPI_AMD: Enables SPI controller driver for AMD SoC.
    • SPI_MUX: Adds support for SPI multiplexers. Each SPI mux will be accessible as a SPI controller, the devices behind the mux will appear to be chip selects on this controller. It is still necessary to select one or more specific mux-controller drivers.
    • SURFACE_3_POWER_OPREGION: Support for ACPI operation region of the Surface 3 battery platform driver
    • USB_LGM_PHY: Support Intel DWC3 PHY USB phy

Alongside all of this, I grabbed a patch that enables the building of nvidia-glx-driver against 5.10. In all likelihood this can be applied to the other drivers (390, beta, and developer). I've validated that graphics work, as you can see from the screenshot below, and that snaps work as well (in other words, I didn't break the AppArmor confinement, which is always a plus).

Given all of this, it does indeed appear that 5.10 will be the kernel that current will see an update to. That being said, 5.10 isn't scheduled for release until late December, so @DataDrake and I need to determine whether or not we're going to defer Solus 4.2 until then or ship with an RC, given it doesn't appear 5.9 has gotten all the NVMe changes. Obviously we recognize that Solus 4.2 is much needed (we want to release it too!), especially given I'll be starting the GNOME 3.38 upgrade locally next week and Budgie 10.5.2 will be officially released when GNOME 3.38 lands in our stable repo. At that point there won't be any blockers besides the kernel for tagging.

big updates hype !

6 days later

ghostv33 What fix? LTS is quite a bit older than latest at this point. If someone knows an actual patch that fixes it, we can add it, but "it works on LTS" is literally saying "it used to work, years ago". We have a hard enough time fixing regressions between releases in the same kernel series, weeks apart, let alone the thousands of commits between LTS and now.

      ghostv33

      DataDrake sry but i don't know what's the actual problem
      But on mate
      Desktop gets borked after installation
      For some reason only moving to lts fixes it
      Though other flavors don't have this strange problem

            ghostv33 I know, I read the other thread. My point is asking us to include the "fix" is like asking us to sort through a haystack for a single needle without lighting the haystack on fire. And since we can't reproduce it ourselves easily, searching that haystack also means not using magnets. It's probably something odd with the display driver in the linux-current kernel for your machine. That likely will only get fixed by moving us to a newer kernel which is waiting on a stable release of 5.10 at the moment.

                DataDrake yes but the kernel on other flavors don't have this problem
                From what i understand it seems to happen with amd old apus of E series

                    ghostv33 I know. I figured you could connect the dots that it's specifically something in the driver that is causing problems with MATE's compositor (marco) and not the compositors/WM on the other editions. Apparently, I should have been more clear. These kinds of bugs happen all the time. They are almost always fixed by a later kernel update. Please be patient.

                        DataDrake oww ok
                        Sry for not understanding earlier 🙁
                        Thanks for the clarification 😄

                          5 days later

                          JoshStrobl Will your RC builds of the LTS kernel be available in Unstable to test?

                          I'm hopeful that maybe I can use my 2740p on that without the stability issues I have under Current.

                              Saijin_Naib 5.10 would be our current, not LTS. Our linux-lts is designed for what we consider older, "legacy" hardware that has notable regressions in newer kernels. The RCs aren't available since they're just on an experimental source repo that we have, not something we're going to be supporting more broadly since it'd require additional driver support, build time, etc. Mostly used as a rare playground to test changes or in this case, just get a head start on 5.10 so we can push it to unstable as soon it's released as a proper stable release.

                              @DataDrake has a fairly clear idea on how he wants to address LTS going forward. My work / testing is limited to future current.

                                  JoshStrobl Thank you for the clarification.

                                  I will see if/how I may help test the future LTS then.

                                    Saijin_Naib In further testing against current (5.6) on my HP EliteBook 2740p, I find that the issue with suspend/resume remains, and in addition, I am subject to random hard-freezes during usage/idling. Performance seems better than LTS, and accessory/peripheral functionality is solid.

                                    The freeze seems to occur typically within 30min of boot and leads to the system being entirely unresponsive, requiring a hard reset via the power switch.

                                    Given what I have access to, I'd say that maybe the 4.19 branch might be safer for this vintage hardware, given my issues with 5.6 currently.

                                        a month later

                                        i clicked others ( I want latest kernel supporting latest hardware). I wish Solus team uploads 5.9 kernel soon

                                          And, it’s probably no secret in this forum, 5.10 is expected to be released this upcoming weekend.