KDE Power management crash #228
Comments
|
First, please ensure that PowerDevil is picking up the latest libddcutil. The system log should contain a line that looks like libddcutil[258928]: Initializing. ddcutil version 1.2.0 Please run ddcutil environment --very-verbose and submit the output as an attachment. (--very-verbose is an undocumented option, not intended for general use.) Given that the command probes for monitors using many different techniques, it may well trigger the crash. In any event, the output will be useful. Since your trace shows the crash occurs in function ddca_open_display2(), please ensure that your ddcutilrc file includes at least the following options in section [libddcutil]: Again, please send the trace file showing the crash as an attachment rather than including it inline. I look forward to getting a better understanding what is happening. |
|
PowerDevil is definitely picking it up
The output of The tracefie The interesting thing is with the options enabled in the ddcutilrc file kde no longer detects the broghtness control but powerdevil still seems to crash but without a backtrace. |
|
The systrem log difference with ddcutilrc options and without EDIT: |
|
I was finally get a crash with trace while the options were enabled after a few reboots, here's the file, hopefully all this helps |
|
I'm baffled as to what's going on. The coredump trace clearly shows the failure as being within ddca_open_display2(). Yet the trace logs always show ddca_open_display2() returning successfully. Branch 1.2.1-dev contains additional tracing to look at called functions of interest, and to output detailed information for more assert() failures. Perhaps you'll hit a case where the trace file shows a function that doesn't return, or there's useful output in the system log. The libddcutil entry in ddcutilrc should now be: If a crash is occurring within libddcutil I'd like to understand it, but since Gentoo is a source based distribution you can simply unset macro WITH_DDCUTIL when building PowerDevil. The PowerDevil code that uses libddcutil is quite rudimentary, and has not been maintained. The developer recommends that it not be used. |
|
Yes, I can disable the use of ddcutil but i'll try to help with this issue I thought I'll try to use the dev branch and enable the additional tracing maybe tonight or tomorrow |
|
Thanks so much for your help. The lock_distinct_display message is indeed interesting. I suspect what's happening is that after a suspend, PowerDevil tries to open the display again without having closed it. I'm going to take a look at enabling the PowerDevil debug messages along with those from libddcutil. I'll let you know when it makes sense to test again. |
|
I've made several enhancements on the 1.2.1-dev branch to libddcutil tracing. In particular, utility option --f3 causes trace messages to be duplicated to the system log. (This is quick and dirty implementation. Not everything will be caught.) The libddcutil options string should now be: I'm not familiar with KDE programming, but as I understand the documentation setting environment variable Sending both powerdevil and libddcutil tracing to the system log should give a better handle on what is going on. If you can duplicate the crash, please submit the contents of the system log starting from the first libddcutil call. Thanks again for your help. |
|
Here are the log files This is the system log from journalctl I had to reboot, login, logout and login to get the brightness slider, so the lower parts of the logs might be of more interest I added the |
…in current thread Previously asserted failure if display already locked by thread but DREF_OPEN not set in the Display_Ref. However, this can occur if the client has created a new Display_Ref. Addresses the PowerDevil crash reported in issues #228 and #205. However, this fix will probably cause failure within PowerDevil itself, which never calls ddca_close_display(), but instead calls ddca_open_display() with a new Display_Ref after return from suspend.
|
I see the problem (line 1681 in journalctl.txt). PowerDevil never closes a "Display Handle" (sort of like a file handle for the I2C bus). When awakened from sleep, it tries to open a new Display Handle for the I2C bus for the same display using a newly "Display Reference". This puts the data structures into a state I had thought impossible. Function ddca_open_display() on branch 1.2.1-dev now returns DDCRC_ALREADY_OPEN if the display is open in the current thread. This fixes libddcutil, but as I read the PowerDevil code just pushes the failure location to PowerDevil itself. Can we check that libddcutil itself no longer asserts failure, and see how PowerDevil handles the ddca_open_display() failure? I thought that "*powerdevil.info=true" would cause all more severe messages to be output as well. But only info messages appear in the syslog. As a read the documentation just "powerdevil=true" is at least one way to cause all messages to be output. So change the QT_LOGGING_RULES statement to: Again, please send the libddcutil trace file and relevant section of syslog output. Also the coredump trace if PowerDeveil fails. Thank you. |
|
I believe ddcutil is not failing anymore, powerdevil or something still takes down the plasma shell though can't find a coredump using coredumpctl, I need to check more on that. I did get the trace file and system logs though |
|
Your logs confirm that given the fix to function ddca_open_display(), libddcutil no longer crashes, but powerdevil does fail. The immediate problem is that powerdevil does not close an existing display handle before attempting to open another display handle using a different display reference. Until/if powerdevil is fixed, I suggest you disable use of lbiddcutil when installing powerdevil. I haven't installed gentoo so can't say how best to do this when installing the gentoo powerdevil package. The CMakeLists .txt file defines the macro automatically whenever ddcutil is installed. Again, that you for all your help in remotely debugging this elusive problem. |
|
I'll close this as this has been fixed on ddcutil |
I'm experiencing the same issue as #205 but on Gentoo, and with AMD 6700XT
I have updated to ddcutil 1.2 and Plasma 5.23 but still face the same issue.
I've added the ddcutilrc file and will report once i get the error again.
This is what the backtrace looks like using coredumpctl
The text was updated successfully, but these errors were encountered: