search

damentz / liquorix-package

Liquorix Debian Package
https://liquorix.net
GNU General Public License v2.0
288 stars 23 forks source link

OpenRGB Broken As Of 5.14 #70

Closed ChaosBlades closed 2 years ago

ChaosBlades commented 3 years ago

Noticed on Liquorix OpenRGB stops seeing my RGB RAM. It works without issue on generic and xanmod kernels.

Seeing as you really need to go out of your way to buy RAM that does not look like a chrismas tree this module should be included.

I think this is what you need? https://gitlab.com/CalcProgrammer1/OpenRGB/-/wikis/OpenRGB-Kernel-Patch

ChaosBlades commented 3 years ago

Just found this...

https://github.com/zen-kernel/zen-kernel/issues/174

So is this broken at the moment then?

damentz commented 3 years ago

Yep, seems to be broken. I just verified, the patch hasn't been updated since I merged it, so if it's not working then it's either a new incompatibility with 5.14 or maybe something local to your system is misconfigured.

I'll update the subject to indicate that and leave open for now.

ChaosBlades commented 3 years ago

Fresh install of Pop!_OS 21.04 with Kernel 5.13.0-7614-generic my RGB RAM is detected. I don't need to load any kernel modules or anything. Just a base install with OpenRGB.

Installing 5.14.13-xanmod1 it is also detected.

Installing 5.14.0-13.1-liquorix-amd64 my RGB RAM is immediately no longer detected with OpenRGB upon reboot into new kernel.

I don't believe this is is an issue with my configuration or Kernel 5.14 since xanmod still works. Looks to be an issue specific to liquorix.

damentz commented 3 years ago

Looking at the OpenRGB documentation, they mention setting acpi_enforce_resources=lax on some motherboards. Liquorix already overrides this setting and configures it to use lax. With that in mind, maybe it's actually breaking OpenRGB rather than making it work better.

Can you try booting with acpi_enforce_resources=strict?

ChaosBlades commented 3 years ago

Assuming I did this correctly by adding that to my /boot/efi/loader/entries/Pop_OS-current.conf file like so...

title Pop!_OS
linux /EFI/Pop_OS-be2bf9ec-6219-4be3-905b-472d36a211c4/vmlinuz.efi
initrd /EFI/Pop_OS-be2bf9ec-6219-4be3-905b-472d36a211c4/initrd.img
options root=UUID=be2bf9ec-6219-4be3-905b-472d36a211c4 ro quiet loglevel=0 systemd.show_status=false splash acpi_enforce_resources=strict

... that did not resolve the issue.

damentz commented 2 years ago

The first 5.15 kernel should be out soon, can you try it when you get the chance?

ChaosBlades commented 2 years ago

Looks like it has not quite hit the ubuntu repo just yet. Should it work out of the box or should I test with acpi_enforce_resources=strict?

ChaosBlades commented 2 years ago

No change with 5.15. Same thing as before.

damentz commented 2 years ago

Ok, well at this point, I think it's just best to say OpenRGB doesn't work with Liquorix and leave it as that. I don't have any hardware that's compatible to test with (I personally don't care for RGB anyways, so I avoid hardware that probably would work with OpenRGB).

Also, the patch from the OpenRGB project has two problems (https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/OpenRGB.patch):

  1. It's only a patch file, not a mailbox compatible patch with the original upstream commit it's based on.
  2. It hasn't been rebased in over a year. Currently in Zen Kernel, we have to made modifications so it merges correctly at all. I'm not surprised there's issues with it.

And last, I don't even advertise OpenRGB support on the main website despite the patch being applied. The patch seems to do something, when I load the corresponding module, I get a message in the kernel log: Found NCT6796D or compatible chip at 0x2e:0x200. I'd say at this point it's probably a bug in the code that Liquorix is exposing, so maybe you should submit an issue here: https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues

Who knows if you'll get a response (Open: 768, Closed: 1,178, All: 1,946 - yikes!!), but this is the responsibility of the author of the patch.

If a new patch comes out, please let me know so it can be merged into Zen Kernel upstream (which then Liquorix gets), but otherwise I'll mark this issue as closed since there isn't really anything I can think of that I can do to help at this point.

CalcProgrammer1 commented 2 years ago

The patch is only needed for a handful of ASUS Intel motherboards and only for the on-board RGB. I haven't updated the patch because of how few devices really need it, none of my main test builds use it. I can look at cleaning it up after the 0.7 release. RGB RAM is always driven by the chipset SMBus (i801 on Intel, piix4 on AMD). The change I made to expose the second AMD piix4 SMBus has already made it upstream, and besides, it too is unnecessary as the RGB RAM is on the first bus.

I have been using Liquorix on my primary system for a while, though uninstalled recently while waiting for a 5.15 version. I'll reinstall and try again. I never had any issues detecting all four of my G.Skill Trident Z RGB sticks on 5.14 Liquorix, though the piix4 SMBus driver had trouble with my motherboard RGB on the second bus. Switching to Debian's stock 5.15 or 5.14 kernels I don't have this issue. The issue is that after a bunch of continuous writes (maybe 30 seconds to 1 minute of PC-driven effects) the motherboard SMBus would just start throwing errors in dmesg and the RGB would stop responding.

ChaosBlades commented 2 years ago

I also have G.Skill Trident Z RGB sticks. Maybe it is something specific with my ASUS x570 Dark Hero on BIOS 3801 (latest) or it is specific with Pop OS on Liquorix.

0lvin commented 2 years ago

Could you please also check patch from https://bugzilla.kernel.org/show_bug.cgi?id=204807#c173 ?

It contains workaround for acpi conflicts and rebased i2c patch from OpenRGB repository as part of nct6775.

It requires name of ACPI mutex for access to i2c if conflict exists.

I2C part is untested, i will be appreciate if someone can check it with real board.

damentz commented 2 years ago

It appears from what @0lvin posted, the fact that many of these modules still require acpi_enforce_resources=lax underlines a bigger issue. Because Liquorix has hard kernel preemption and a different scheduler, interactions with these drivers without proper protections will eventually leave the hardware in a broken state, as we're seeing from some anecdotes here.

I'll re-open since it looks like there's traction to resolve this upstream.

damentz commented 2 years ago

In package version 5.14-3, acpi_enforce_resources=lax was prepended to the boot time kernel parameters. Packages based on 5.15-6 coming out soon will have that removed.

This may fix the issue some of you are having, but is no guarantee considering OpenRGB recommends this option be turned on in order for the software to work properly.

CalcProgrammer1 commented 2 years ago

This parameter is only "recommended" for certain motherboards for OpenRGB, particularly those from Gigabyte. This option is necessary as Gigabyte boards seem to prevent the loading of i2c_piix4 otherwise. On boards where i2c_piix4 loads fine, the lax option isn't necessary (and including it doesn't improve anything). I'm guessing Gigabyte's ACPI/WMI has something that uses the associated addresses so the piix4 driver refuses to load.

damentz commented 2 years ago

@CalcProgrammer1 thanks for the clarification, reading the README.md on your GitLab, it does say:

Some Gigabyte/Aorus motherboards have an ACPI conflict with the SMBus controller.

And proceeds to recommend it for that situation.

With acpi_enforce_resources=strict or the latest Liquorix kernel, do the issues reported here go away?

ChaosBlades commented 2 years ago

Going from the generic kernel to 5.15.0-5.4-liquorix-amd64 is still breaking detection even with acpi set to strict. Before and after OpenRGB logs show it is no longer registering any I2C interfaces.

damentz commented 2 years ago

Hmm, then I think this definitely is an upstream defect (as per the label). The issue is that things get initialized in a different order because PDS schedules things differently. The best example came from @CalcProgrammer1 where he described how things worked for a while and then didn't at all. There's some bugs in these drivers, some that make them useless immediately, and some others where it takes them a while to break.

I think the work @0lvin is doing is important and will probably resolve the issues here eventually and permanently. But until then, I don't think there's really much left we can do aside from turning on a module that may have been disabled by accident.