Big upgrade of xorg, kernel, and graphics drivers that include important changes, is now available in [testing]


(Luca Giambonini) #15

what you mean with reconfiguration? could you please explain what you have done?

(tom) #16

i started the touchpad configuration and set “mouse click emulation” on
(so far i can remember)

(Sławomir Szewczyk) #17

Hello, when is the update planned for a stable release?

(Rémy Epke) #18

Wrong topic. However, this and this will answer your question.

(Neofytos Kolokotronis) #19

Hello @shevchenko1987 and welcome to the Chakra forums!

If the question is when is this planned to move to the stable repositories, then the answer is early next week, if nothing comes up, as no showstoppers have been reported so far.

If you are asking for a new ISO release, perhaps to test how Chakra runs on your system with these updates included, the plan was to start working on it after these groups have been done. But we can’t really give an ETA until we are closer to a release, and this will take time (as in at least 1-2 months).

As @ReemZ pointed above, you can simply install Chakra now using the current ISO and you will receive these updates with a standard upgrade after everything hits the stable repos.

(dinolib) #22

Hi! just back home from holidays, and updated my first testing machine (intel+nvidia bumblebee).
Update was fine, without errors.

Reboot seemed to be a little slow, but at first I find that nvidia is working and bumblebee can’t stop it.

Later I’ll try to check it deeply. In the meanwhile any suggestion is welcome!

Some problem with bumblebee. It confirms that nvidia is already used…
sudo systemctl status bumblebeed
● bumblebeed.service - Bumblebee C Daemon
Loaded: loaded (/usr/lib/systemd/system/bumblebeed.service; enabled; vendor preset: disabled)
Active: active (running) since sab 2017-08-26 07:51:54 CEST; 7h ago
Main PID: 545 (bumblebeed)
Tasks: 3 (limit: 4915)
Memory: 42.0M
CPU: 17min 41.615s
CGroup: /system.slice/bumblebeed.service
├─ 545 /usr/bin/bumblebeed
└─10512 /usr/lib/xorg-server/Xorg :8 -config /etc/bumblebee/xorg.conf.nvidia -configdir /etc/bumblebee/xorg.conf.d -sharevts -nolisten tcp -noreset -verbose 3

ago 26 13:39:59 chakra-pc bumblebeed[545]: [20899.735777] [WARN][XORG] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
ago 26 13:39:59 chakra-pc bumblebeed[545]: [20899.735794] [WARN][XORG] (WW) NVIDIA(0): Unable to get display device for DPI computation.
ago 26 13:39:59 chakra-pc bumblebeed[545]: [20899.735800] [WARN][XORG] (WW) NVIDIA(0): Option “NoLogo” is not used
ago 26 13:39:59 chakra-pc bumblebeed[545]: [20899.735810] [ERROR][XORG] (EE) kbd: : failed to set us as foreground pgrp (Inappropriate ioctl for device)
ago 26 13:39:59 chakra-pc bumblebeed[545]: modprobe: FATAL: Module nvidia is in use.
ago 26 13:40:02 chakra-pc bumblebeed[545]: [20902.857990] [ERROR]Unloading nvidia driver timed out.
ago 26 13:40:03 chakra-pc bumblebeed[545]: [20903.576536] [WARN][XORG] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
ago 26 13:40:03 chakra-pc bumblebeed[545]: [20903.576559] [WARN][XORG] (WW) NVIDIA(0): Unable to get display device for DPI computation.
ago 26 13:40:03 chakra-pc bumblebeed[545]: [20903.576566] [WARN][XORG] (WW) NVIDIA(0): Option “NoLogo” is not used
ago 26 13:40:03 chakra-pc bumblebeed[545]: [20903.576579] [ERROR][XORG] (EE) kbd: : failed to set us as foreground pgrp (Inappropriate ioctl for device)

Looking at this README I’m not able to shut down the card.

Actualizaciones para xorg, kernel y controladores gráficos incluyen cambios importantes y pueden requerir intervención manual
Upgrades for xorg, kernel and graphics drivers include important changes and might require manual intervention
Plasma not loading after last update
包含了重要且可能需要手動調整變更的 xorg、核心與顯示卡驅動程式的更新
(Neofytos Kolokotronis) #23

Ah, so am not alone! Check out my report on our bugtracker and better add any additional info there, or at least mention that you are also experiencing the same issue. I wasn’t sure back then if it was this upgrade that caused it or I just happened to notice it at this time, but now it looks related.

Fwiw, I’ve switched to PRIME in the meantime with nouveau and that works. I have a 2nd Chakra installation with bumblebee+nvidia though, so I can help to further troubleshoot this.

(dinolib) #24

Hi tetris,

for me this is not exactly the same. I cannot unload the module nvidia, because in use.
I still can’t understand what is using it. Maybe X?

I tried to blacklist it in /etc/modprobe.d/nvidia.conf but with no luck.

At the moment I don’t like to move to nouveau…

(Neofytos Kolokotronis) #25

Yes it was exactly the same for me, that is why I had to force it with the -f switch.

sudo modprobe -rf nvidia

And then turn the card off:

sudo tee <<<OFF /proc/acpi/bbswitch

(dinolib) #26

sudo modprobe -rf nvidia
modprobe: FATAL: Module nvidia is in use.

I’m not able to unload the module…

(tom) #27

also in a TTY?
my second idea is reboot in to the
add to the kcmd:

(dinolib) #28

Tty? Do you mean alt+f1? Let me try when at home.

Unfortunately I can’t understand your suggestion about kcmd

(tom) #29

i mean ctrl + alt + F2 because the session run on TTY1

(dinolib) #30

I tried it, but when come back to KDE it is freezed. Hard reset needed from power button…
X should run under intel drivers, because running openGL info it is using intel drivers.

(Neofytos Kolokotronis) #31

I don’t know why, but I couldn’t replicate this on my test system (used the latest ISO to install).

Can you check if you have a bumblebee.conf.pacnew file under /etc/bumblebee/? If yes, then replace your bumblebee.conf file with this one.

Also, I found this post on the Arch’s libglvnd related thread, it suggests you need to manually copy the configuration files. I am not sure this is needed for bumblebee though.

cp /usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf /etc/X11/xorg.conf.d

It is probably worth it to try and remove all nvidia,bbswitch and bumblebee packages > reboot > reinstall them > reboot.

(dinolib) #34

Thank you. I’ll ASAP. In the past (early libglvnd compiles) I made some test with these files, may be I broke something.

intel note: on my pure Intel machine, after the update I had some stability issues. I cannot recover from video stand by.

Reading arch wiki it seems that it is preferable to use modeset driver for recent video cards.
So I removed the package xf86-video-intel and now it works perfectly.

NOTE: remember to remove any intel.conf file in the xorg.conf.d directory, otherwise your system could hang at boot (this is what happened to me)

Thank you tetris4, I confirm exactly the same behaviour as indicated in the Arch forum:

cp /usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf /etc/X11/xorg.conf.d
env PRIMUS_libGLa="/usr/lib/" primusrun

I’ll try to investigate why this happens

(Alexander Waldemar Ahjolinna) #35

I get this on my ultrabook (intel gpu):

(271/271) checking for file conflicts                                                                                                             [##########################################################################################] 100%
error: failed to commit transaction (conflicting files)
/usr/lib/xorg/modules/extensions/ exists in both 'mesa-libgl' and 'xorg-server'
ca-certificates-utils: /etc/ssl/certs/ca-certificates.crt exists in filesystem
Errors occurred, no packages were upgraded.

(Neofytos Kolokotronis) #36

Yup, both are known issues and require manual intervention.

For mesa check this:

For the ca-certificates check here:

Also, remember to join the testers group so you will get notified of all related announcements.

(Neofytos Kolokotronis) #37

This is very strange. The nvidia module should not be needed if intel is in use and it makes no sense to freeze KDE if unused…

Update: I have in the meantime talked about this the developers in #bumblebee on IRC, ‎Lekensteyn‎ suggested building bumblebee+bbswitch from the develpment branch as it includes some related fixes. I hope we can provide that asap.

Here’s the full discussion:

[00:31] ‎<‎tetris4‎>‎ Hi everyone. We are preparing a kernel/xorg/graphics drivers update over at Chakra and this issue came up with bumblebee not being able to properly blacklist the nvidia module
‎[00:31] ‎<‎tetris4‎>‎ Here is the relevant report:
‎[00:31] ‎<‎tetris4‎>‎ Any insight on how to fix or workaround this for our users would be greatly appreciated!
‎[00:32] ‎<‎tetris4‎>‎ here is our package details, mostly imported from ArchLinux:
‎[00:36] ‎[Notice]‎ -ChanServ- [#chakra] Welcome to the Chakra discussion and support channel!
‎[00:53] ‎<‎Lekensteyn‎>‎ hi tetris4
‎[00:56] ‎<‎Lekensteyn‎>‎ tetris4: could you give the develop branch a go? that branch has some fixes related to modules
‎[00:56] ‎<‎Lekensteyn‎>‎ the Debian folks helped a lot there
‎[00:57] ‎<‎tetris4‎>‎ hi Lekensteyn, long time no speak, I hope you are doing well. =)
‎[00:57] ‎<‎tetris4‎>‎ glad to see the project is still active. So just pull from the latest git commit?
‎[00:58] ‎<‎Lekensteyn‎>‎ develop branch (master tracks the latest release)
‎[00:58] ‎<‎Lekensteyn‎>‎ project is active by virtue of gsgatlin and bluca
‎[00:59] ‎<‎tetris4‎>‎ ok, should I got for the develop branch of bumblebee, bbswitch or both?
‎[00:59] ‎<‎tetris4‎>‎ kudos to them then!
‎[00:59] ‎<‎tetris4‎>‎ *got=go
‎[01:00] ‎<‎Lekensteyn‎>‎ just develop of bumblebee
‎[01:00] ‎<‎Lekensteyn‎>‎ you can also pull develop for bbswitch to fix building against 4.12 (really a small patch)
‎[01:01] ‎<‎Lekensteyn‎>‎ and if people are running into issues related to a hanging machine, see
‎[01:01] ‎<‎tetris4‎>‎ we do use kernel 4.12.4 so that makes sense
‎[01:01] ‎<‎Lekensteyn‎>‎ I tried to debug that issue, but no luck :( sticking with a workaround for now
‎[01:02] ‎<‎Lekensteyn‎>‎ if possible, I would personally recommend people to try nouveau if they just have the need for external monitor and power saving in othercases
‎[01:02] ‎<‎Lekensteyn‎>‎ have not tried the blob for a long time, so am not fully up to date with its issues
‎[01:03] ‎<‎Lekensteyn‎>‎ (and features of course ;))
‎[01:03] ‎<‎tetris4‎>‎ well personally I used this as an opportunity to switch to PRIME+nouveau, seems to be fine for now, don't really use the nvidia card nowadays
‎[01:04] ‎<‎tetris4‎>‎ I understand people want to use nvidia for gaming mostly
‎[01:04] ‎<‎Lekensteyn‎>‎ I used bbswitch with my old laptop (since it had its outputs wired to intel)
‎[01:05] ‎<‎Lekensteyn‎>‎ my new laptop resulted in moving to nouveau instead due to the external monitor
‎[01:05] ‎<‎Lekensteyn‎>‎ so that's also one of the reasons why I am less active in bb nowadays
‎[01:06] ‎<‎Lekensteyn‎>‎ a pity for the users, I try to reply when I have the time, but it is not a sustaining approach
‎[01:06] ‎<‎tetris4‎>‎ true...
‎[01:06] ‎<‎Lekensteyn‎>‎ thanks for maintaining chakra packages btw :)
‎[01:07] ‎<‎tetris4‎>‎ am still on the Dell XPS L502X, which was doing great with bb until this issue came up 
‎[01:08] ‎<‎tetris4‎>‎ nah, thanks for providing us with this project, don't know what I would have done over the years without it.
‎[01:09] ‎<‎Lekensteyn‎>‎ as for debugging this, any hints in journal or /var/log/Xorg.*.log? anything in release notes of nvidia?
‎[01:10] ‎<‎tetris4‎>‎ unfortunately I can't replicate the issue on my 2nd installation on the same system, which is weird
‎[01:10] ‎<‎tetris4‎>‎ I will ask the user, if they can't find anything I might try to revert this installation back to bb and check
‎[01:11] ‎<‎tetris4‎>‎ hmm, release notes of nvidia? what should I look for there?
‎[01:11] ‎<‎Lekensteyn‎>‎ perhaps they have changed the way modules get loaded
‎[01:11] ‎<‎Lekensteyn‎>‎ or introduced new modules
‎[01:12] ‎<‎tetris4‎>‎ what's strange is that I would expect to find some reports on Arch about this, but didn't see anything
‎[01:13] ‎<‎tetris4‎>‎ so I wonder how it can be Chakra specific
‎[01:13] ‎<‎tetris4‎>‎ also any idea why that user could not force the unloading of the module on his system, whereas I could?
‎[01:15] ‎<‎Lekensteyn‎>‎ is it possible that the user's primary X server suddenly took ownership of the device via hotplugging?
‎[01:15] ‎<‎Lekensteyn‎>‎ if something like that happened, it should be visible in the xorg log
‎[01:16] ‎<‎Lekensteyn‎>‎ another possibility is that nvidia was already loaded (at least once) during startup of the primary X server
‎[01:17] ‎<‎Lekensteyn‎>‎ then since the primary X server owns this device (as exposed by the nvidia driver), it will not be possible to unload nvidia
‎[01:17] ‎<‎Lekensteyn‎>‎ that's often the result. Now what causes this, I would probably be looking into the modprobe blacklist, whether they function or not
‎[01:18] ‎<‎tetris4‎>‎ dunno if you read it already, but here is his initial report:
‎[01:18] ‎<‎Lekensteyn‎>‎ is the nvidia module in /etc/modules-load.d/? (should not)
‎[01:19] ‎<‎tetris4‎>‎ oki, I'll ask that also in my response
‎[01:20] ‎<‎Lekensteyn‎>‎ `modprobe -f nvidia` is also not recommended. If it is in use, it is important to figure out what exactly uses it (primary X server, Bumblebee's secondary X server, maybe some CUDA application? etc)
‎[01:20] ‎<‎tetris4‎>‎ how does one check for that though?
‎[01:21] ‎<‎Lekensteyn‎>‎ it can help to check the process list (ps uww -C X or ps uww -C Xorg)
‎[01:21] ‎<‎tetris4‎>‎ ehehe, one more thing to ask him =P
‎[01:21] ‎<‎Lekensteyn‎>‎ and assuming that /dev/dri/card1 is nvidia, you can also try sudo lsof -n /dev/dri/card1
‎[01:22] ‎<‎Lekensteyn‎>‎ to discover whether it is actually nvidia, have a look in the Xorg log
‎[01:23] ‎<‎tetris4‎>‎ I'll just copy paste what you are writing here, hopefully the user can follow.
‎[01:24] ‎<‎Lekensteyn‎>‎ actually, skip that xorg step. To see whether card1 corresponds to nvidia, check sysfs with: ls -l /sys/class/drm/card1
‎[01:24] ‎<‎Lekensteyn‎>‎ for me it gives: lrwxrwxrwx 1 root root 0 Aug 26 14:04 /sys/class/drm/card1 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1
‎[01:25] ‎<‎Lekensteyn‎>‎ intel (card0) would give: ../../devices/pci0000:00/0000:00:02.0/drm/card0
‎[01:26] ‎<‎tetris4‎>‎ hmm, here on prime+nouveau, running that command gives card1, but the card seems to be off
‎[01:26] ‎<‎Lekensteyn‎>‎ that's correct
‎[01:26] ‎<‎Lekensteyn‎>‎ card1 is only created when a DRM driver (like nouveau, and presumably nvidia-drm) is loaded
‎[01:27] ‎<‎Lekensteyn‎>‎ in the case of nouveau, runtime PM ensures that the device suspends when no user is accessing it (e.g. Xorg/DRI_PRIME applications via /dev/dri/cardX, lspci accessing config space, etc.)
‎[01:28] ‎<‎Lekensteyn‎>‎ and even if Xorg has claimed it, if no outputs are active, it will also suspend
‎[01:30] ‎<‎tetris4‎>‎ how can one check if card1 is nvidia and 0 is intel?
‎[01:30] ‎<‎Lekensteyn‎>‎ examine the syfs symlinks, ls -l /sys/class/drm/card*
‎[01:30] ‎<‎Lekensteyn‎>‎ 00:02.0 is the intel one, 01:00.0 (or 02:00.0, etc.) is the nvidia one
‎[01:32] ‎<‎tetris4‎>‎ that's weird, does this make sense then?
‎[01:32] ‎<‎tetris4‎>‎ ah, sorry, its correct, 02 is intel
‎[01:33] ‎<‎tetris4‎>‎ I would expect intel to be 01, and nvidia 02
‎[01:33] ‎<‎Lekensteyn‎>‎ 00:01.0 is the PCI root port to which the nvidia PCI device is attached 01:00.0
‎[01:33] ‎<‎Lekensteyn‎>‎ 00:02.0 is the IGD (Integrated Graphics Device)
‎[01:34] ‎<‎Lekensteyn‎>‎ those 00:0x.0 addresses seem pretty standard for a given Intel CPU family
‎[01:34] ‎<‎tetris4‎>‎ so card0 should be IGD?
‎[01:34] ‎<‎Lekensteyn‎>‎ yes
‎[01:34] ‎<‎Lekensteyn‎>‎ normally that is the case
‎[01:34] ‎<‎tetris4‎>‎ ok I think I got it now
‎[01:34] ‎<‎Lekensteyn‎>‎ I haven't seen otherwise
‎[01:35] ‎<‎tetris4‎>‎ Lekensteyn: ok to share this conversation as is on our forum?
‎[01:35] ‎<‎Lekensteyn‎>‎ sure
‎[01:35] ‎<‎tetris4‎>‎ thanks
[01:35] ‎<‎Lekensteyn‎>‎ please spread the knowledge :)
 [01:38] ‎<‎tetris4‎>‎ =D

So some questions that come up:

  1. Does running an application with optirun work for you?
  2. Did you check the output of dmesg | tail -1 after running the tee command to turn the card off?
  3. Any relevant output in /var/log/Xorg.*.log?
  4. Is there any nvidia module in /etc/modules-load.d/ (it shouldn’t)?

(dinolib) #38

Hi tetris. Thank you for your interest.
At first I remember you that as from my last post I solved with the arch forum’s solution.

Trying to solve in the old way, I checked almost every log except xorg.
I confirm that nvidia is blacklisted (I tried to add another blacklist as from arch wiki without luck).
The only error was that nvidia module is in use but I can’t understand by whom.