I am experiencing severe system instability and total hard-locks after upgrading to the 7.0.10-1-MANJARO kernel. The system becomes sluggish, eventually freezing completely. During these hangs, I cannot even drop to a TTY, forcing a hard reset. Also, hibernation was also not working.
Rolling back to the 6.18 LTS kernel completely resolves all issues, and the system is rock-solid.
journalctl -b -1 -p 3 -x shows:
Jun 12 01:42:39 shaurya-manjaro kernel: amdgpu 0000:11:00.0: Unable to locate a BIOS ROM
Jun 12 01:42:39 shaurya-manjaro kernel: amdgpu 0000:11:00.0: Fatal error during GPU init
Jun 12 01:42:39 shaurya-manjaro kernel: amdgpu 0000:11:00.0: GPU mode2 reset failed
Jun 12 01:42:39 shaurya-manjaro kernel: amdgpu 0000:11:00.0: asic reset on amdgpu_device_ip_fini_early failed
Jun 12 01:42:39 shaurya-manjaro kernel: amdgpu 0000:11:00.0: probe with driver amdgpu failed with error -22
Further down the line there is also:
Jun 12 01:56:38 shaurya-manjaro kernel: kernel BUG at fs/iomap/buffered-io.c:1061!
On a bit of searching, the amdgpu bug seems to resolve by adding amdgpu.sg_display=0 to GRUB configuration, as I have not seen the same error in journalctl since.
However, for the kernel bug, I found similar complaints in arch forum and kernel bugtracker. Reading the bug report in kernel bug tracker, it seems nothing is being done for it. I also found a commit for the same in cachy os repo for the ntfs3 driver. So is there plan to patch the manjaro kernel too?
I would keep 6.18 as the working boot entry for now and treat 7.0.10 as unsafe on that machine until the ntfs3/iomap fix lands. If the NTFS volume is not essential at boot, one practical test is to leave it unmounted for a session on 7.0.10 and see if the panic disappears; if it does, mount it via ntfs-3g or stay on LTS for that workload.
Also keep a separate backup before testing hibernation again. A hard lock while ntfs3 is writing is exactly the kind of failure where I would rather be boring and use the stable kernel than chase a newer one.
Manjaro kernel maintainer maintains a set of patches targeting specific hardware.
You can find these at core packages repo see the specific kernel repositories e.g. linux618, linux70 and linux71 - please consult the PKGBUILD to see which patches are actually applied (unused patches are kept for reference).
If this question relates to fix ntfs, I think kernel maintainer will say no.
ntfs is a proprietary alien file system and the kernel driver is reverse engineered and it is far from perfect.
Any reliance on ntfs is - forgive me for being blunt - not a Manjaro issue.
if you must have ntfs
Blacklist the kernel driver to prioritise the user-space ntfs-3g driver.
If your issue is related to boot because you mount the device in your fstab I advise to change your approach to use a set of systemd units (mount/automount) to mount the device when path is accessed.
More information on the use of systemd mount/automount units can be found in Contributions > Tutorials
@linux-aarhus
I am an individual and don’t distribute manjaro or any other distro in any official or non-official capacity, so i don’t see any issue. Their usage policy may apply to you though, if you included their compiled kernel in manjaro or some official distribution channel. It still does not bar the manjaro team from using their patches though
@giulia_privacy408
Accidentally deleted the previous comment while editing, so posting again.
Yeah, I am back to 6.18 kernel. Besides the ntfs issue, which i solved with first compiling my own kernel with the patch (and later just using the cachy-os kernel), and the amd bug mentioned above, there is another amdgpu bug where a null pointer deference freezes the system, and which I can not solve. Posted it in amdgpu gitlab , but i have seen little activity to show it will addressed in near future.
@linux-aarhus
Btw, manjaro team should really look into this ntfs bug as it is not hardware specific and will likely affect any user using the said driver in kernel 7.0.x. So either they should blacklist the newer ntfs driver and make ntfs-3g the default, or include the patch in the recent kernels. It can cause data corruption if triggered at wrong time.
Mod edit:Consecutive posts merged, @mentions added.
Nonetheless - the policy seems very clear on the subject - that is the reason I mentioned the policy
4. Supported Users
The CachyOS repository (and its mirrors) provides support exclusively for the following users:
CachyOS Users
ArchLinux Users
5. Unsupported Users
Users from other distributions are NOT SUPPORTED and HIGHLY DISCOURAGED to use the CachyOS repository (and its mirrors). This includes, but is not limited to:
Manjaro
EndeavourOS
ArcoLinux
Parabola
Users of any other Linux distribution not explicitly mentioned in the “Supported Users” section.
While you could read it as you do - but the words - appears to be valid for any individual that might get the idea of mixing in cachyos packages
Users from other distributions are NOT SUPPORTED and HIGHLY DISCOURAGED to use the CachyOS repository (and its mirrors).
But it is your system - you can do whatever you like.
As for ntfs if it really is as serious as you say - it is upstream at kernel.org that needs to fix it - not individual distributions.
However, as much as CachyOS do have their policy, so does Manjaro – technically you would be in an unsupported state – no Support should be offered.