You are not logged in.
If you revert the bad commit
cd linux-drm-tip-git/src/drm-tip
git revert -n d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 #this was the commit that was backported to stable
cd ../..
makepkg -ersi #you could increment the pkgrel if you wanted to keep the built failing one as pkgrel=1 and the probably working as pkgrel=2
see if that also fixes the issue on drm-tip would append dmesg from the good and bad after startx has been run with the boot options drm.debug=0x1e log_buf_len=1M without the boot option nomodeset
https://01.org/linuxgraphics/documentat … eport-bugs
Last edited by loqs (2019-03-07 21:52:50)
Offline
@loqs Indeed, reverting the commit still works with drm-tip. Posted the good and the bad logs upstream, hope it helps. Had some issues compiling the drm-tip kernel with the reverted commit, if failed in depmod, because of nonexistent extramodules: No such file or directory. I guess because of -r? So i did the revert after starting makepkg, it somehow worked it looks. But what would have been the right approach though? Anyway, I hope they figure out what's wrong and fix it.
Last edited by liara (2019-03-09 21:16:21)
Offline
The kernel detected the git repository had uncommitted changes so adds the suffix '-dirty' to the output of `make kernelrelease` which causes the problem with the path for extramodules.
git config --local user.name "John Doe"
git config --local user.email johndoe@example.com
git revert d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 #accept the default commit message
Edit:
Alternatively you can use `scripts/setlocalversion --save-scmversion` before modifying the repository if you want the version to be updated again later remove the file .scmversion
Last edited by loqs (2019-03-09 22:13:04)
Offline
Ah, I see. Indeed it had a dirty suffix. I checked there and there were no extramodules in it. Thank you for the explanation.
Last edited by liara (2019-03-09 22:59:59)
Offline
Not a bug in the kernel, xorg's modesetting driver needs to set all connectors/crtc's directly when using atomic. The legacy path disabled crtc B for you if you stole all its connectors for a different crtc. In the atomic case you need to disable it yourself.
This is a bug in x.org's modesetting driver.
You could try asking for help on IRC or xorg mailing list or submit an issue to https://gitlab.freedesktop.org/xorg/xserver/issues
Offline
It looks like it has been reported there https://gitlab.freedesktop.org/xorg/xserver/issues/542, not much activity though. Will post there later.
Offline
It doesn't look like this bug is getting patched anytime soon. According to this post: https://gitlab.freedesktop.org/xorg/xse … ote_137355 Fedora has patched their own kernel to fix this. The question is, can we do the same in Arch? Who would we need to contact to do that?
Offline
Create a bug report in archlinux bugtracker .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
I also had the "modeset(0): failed to set mode: Invalid argument" error and temporary worked around it by disabling the modesetting driver for Xorg so I didn't have to downgrade.
So I am now using the intel driver again. Hopefully it will be fixed in the next kernel update
@robin67 I made a stab at your approach but seem to have hit a dead end. I added nomodeset and i915.modeset=0 to the kernel command line (in grub) but only succeeded in making screen 0 unrecognized.
Could you explain more fully what you did?
Clever. Too clever.
Offline
The current kernel version (5.0.11-arch1-1-ARCH) fixes the issue for me. Thanks everyone for your help!
Offline