Comments (12)
It seems that arch has released an update ddcutil-2.1.0-2 that solved this problem
from ddcutil.
Commit 7f157f6 in branch 2.1.1-dev is the proper solution to the asserti(sys_drm_connectors) failure. PowerDevil uses the libddcutil API in an unexpected way, and because of a bug in libddcutil initialization, sys_drm_connectors was not being set. A more detailed explanation can be found in the commit message.
from ddcutil.
This issue is pretty widespread :(
from ddcutil.
Backtrace from https://bugs.kde.org/show_bug.cgi?id=480030
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
tid = <optimized out>
ret = 0
pd = <optimized out>
old_mask = {__val = {206158430256}}
ret = <optimized out>
#1 0x000077fb998ac8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x000077fb9985c668 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
ret = <optimized out>
#3 0x000077fb998444b8 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {140728311536560, 96582981365184, 96582981365184, 96582980837392, 0, 12884901656, 0, 140728311536744, 0, 5, 140728311536592, 131922497604720, 131922497642944, 18446744073709551384, 2, 131922402651749}}, sa_flags = -1718897837, sa_restorer = 0x77fb999f5070 <_IO_file_jumps>}
#4 0x000077fb998443dc in __assert_fail_base
(fmt=0x77fb999bdae8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x77fb93f30d95 "sys_drm_connectors", file=file@entry=0x77fb93f2ae65 "i2c_bus_core.c", line=line@entry=614, function=function@entry=0x77fb93f56ec8 <__PRETTY_FUNCTION__.13> "i2c_check_bus") at assert.c:92
str = 0x57d77a4badc0 "J\033;\a\322W"
total = 4096
#5 0x000077fb99854d26 in __assert_fail
(assertion=assertion@entry=0x77fb93f30d95 "sys_drm_connectors", file=file@entry=0x77fb93f2ae65 "i2c_bus_core.c", line=line@entry=614, function=function@entry=0x77fb93f56ec8 <__PRETTY_FUNCTION__.13> "i2c_check_bus")
at assert.c:101
#6 0x000077fb93ee92b9 in i2c_check_bus (bus_info=0x57d77a4b3750) at i2c/i2c_bus_core.c:614
__func__ = "i2c_check_bus"
__PRETTY_FUNCTION__ = "i2c_check_bus"
#7 0x000077fb93eebf35 in i2c_non_async_scan (i2c_buses=0x57d77a4b3f00) at i2c/i2c_bus_core.c:828
businfo = 0x57d77a4b3750
ndx = 0
debug = false
i2c_bus_bva = <optimized out>
buses = 0x57d77a4b3f00
__func__ = "i2c_detect_buses0"
#8 i2c_detect_buses0 () at i2c/i2c_bus_core.c:901
i2c_bus_bva = <optimized out>
buses = 0x57d77a4b3f00
__func__ = "i2c_detect_buses0"
#9 0x000077fb93eec1f5 in i2c_detect_buses () at i2c/i2c_bus_core.c:970
result = <optimized out>
__func__ = "i2c_detect_buses"
#10 0x000077fb93f1016b in ddci_init (libopts=<optimized out>, syslog_level_arg=<optimized out>, opts=<optimized out>, infomsg_loc=<optimized out>) at libmain/api_base.c:700
debug = <optimized out>
s = <optimized out>
parsed_cmd = <optimized out>
master_error = <optimized out>
ddcrc = 0
__func__ = "ddci_init"
__PRETTY_FUNCTION__ = "ddci_init"
#11 0x000077fb93f178a2 in ddca_get_display_info_list2 (include_invalid_displays=<optimized out>, dlist_loc=0x7ffddd04df78) at libmain/api_displays.c:983
filtered_ct = <optimized out>
ddcrc = <optimized out>
filtered_displays = <optimized out>
reqd_size = <optimized out>
result_list = <optimized out>
curinfo = <optimized out>
__func__ = "ddca_get_display_info_list2"
#12 0x000077fb94500d37 in DDCutilBrightness::detect() (this=0x57d77a497bc0) at /usr/src/debug/powerdevil/powerdevil-5.27.10/daemon/backends/upower/ddcutilbrightness.cpp:52
rc = <optimized out>
dlist = 0x0
#13 0x000077fb9450262e in PowerDevilUPowerBackend::initWithBrightness(bool) (this=0x57d77a4a20e0, screenBrightnessAvailable=false)
at /usr/src/debug/powerdevil/powerdevil-5.27.10/daemon/backends/upower/powerdevilupowerbackend.cpp:156
controls = {{d = 0x0, e = 0x0}}
from ddcutil.
I also experience this issue, it's pretty serious in my opinion. Downgraded to earlier version temporarily, but I hope this gets resolved ASAP.
from ddcutil.
My powerdevil is also restarting in a loop. I found sample_clients/clmain.c that reproduces the problem on my system. I have no idea how to ./configure to compile the samples. Anyway, I prepared myself the following script:
#!/bin/bash
set -xeuo pipefail
git clean -fdx
if ! (
trap 'git checkout ./configure.ac' EXIT &&
NOCONFIGURE=1 ./autogen.sh &&
./configure --prefix=/home/kamil/tmp/prefix CFLAGS='-ggdb3 -O0' DBG=1 --with-gnu-ld --disable-doxygen-doc --enable-drm=no &&
make -j &&
gcc src/sample_clients/clmain.c -I src/ -L src/.libs/ -lddcutil -Wl,-rpath,src/.libs
); then
# skip
exit 125
fi
if ! ./a.out; then
exit 1
fi
Then I started bisecting:
git bisect start master v2.0.0
git bisect run ../script.sh
And continued drinking my sour beer. After a few back-and-forth fixes and cycles with the bisecting, I found this guy to blame:
3808a0ad55cb2315ca3c53c42e58b0049939fb5f is the first bad commit
No wonder - it just introduces assert(sys_drm_connectors);
into i2c_check_bus
Just blindly checking out master and removing the assertion makes the sample execute successfully for me. So is the assertion needed there? It is hard to analyze the call flow.
edit Just moving the assertion just a few lines below makes it not fire anymore:
*/
void i2c_check_bus(I2C_Bus_Info * bus_info) {
bool debug = false;
DBGTRC_STARTING(debug, TRACE_GROUP, "busno=%d, bus_info=%p", bus_info->busno, bus_info );
DBGTRC_NOPREFIX(debug, DDCA_TRC_NONE, "force_read_edid=%s", sbool(force_read_edid));
assert(bus_info && ( memcmp(bus_info->marker, I2C_BUS_INFO_MARKER, 4) == 0) );
assert( (bus_info->flags & I2C_BUS_EXISTS) &&
(bus_info->flags & I2C_BUS_VALID_NAME_CHECKED) &&
(bus_info->flags & I2C_BUS_HAS_VALID_NAME)
);
if (!(bus_info->flags & I2C_BUS_PROBED)) {
DBGTRC_NOPREFIX(debug, DDCA_TRC_NONE, "Probing");
bus_info->flags |= I2C_BUS_PROBED;
bus_info->driver = get_driver_for_busno(bus_info->busno);
char * connector = get_drm_connector_name_by_busno(bus_info->busno);
assert(sys_drm_connectors);
It looks like get_drm_connector_name_by_busno
initializes sys_drm_connectors
. Analyzing the call graph it happens in get_drm_connector_name_by_busno
-> find_sys_drm_connector_by_busno
-> find_sys_drm_connector
-> if (!sys_drm_connectors) sys_drm_connectors = scan_sys_drm_connectors(-1);
. The variable is just getting initialized.
Bottom line, so I think, the assertion just shouldn't be there. With that in mind, I'll create a pull request.
from ddcutil.
It seems that arch has released an update ddcutil-2.1.0-2 that solved this problem
Well, yea, -DNDEBUG is the ultimate solution. https://gitlab.archlinux.org/archlinux/packaging/packages/ddcutil/-/blob/main/PKGBUILD?ref_type=heads#L25
from ddcutil.
It seems that arch has released an update ddcutil-2.1.0-2 that solved this problem
Well, yea, -DNDEBUG is the ultimate solution. https://gitlab.archlinux.org/archlinux/packaging/packages/ddcutil/-/blob/main/PKGBUILD?ref_type=heads#L25
All that does is disable assertions entirely, which you don't really want to do long-term, heh. As rockowitz mentioned, 2.1.1-dev fixes the actual issue which is an uninitialized sys_drm_connectors because of how PowerDevil uses the API.
from ddcutil.
PowerDevil uses the libddcutil API in an unexpected way, and because of a bug in libddcutil initialization, sys_drm_connectors was not being set.
Thanks.
This would also mean that starting from Plasma 6.0 RC1, which explicitly calls ddca_init()
before making any other API calls, it should be safe to use libddcutil 2.1.0. The issue was reported for Plasma 5.27, which is in bugfix-only mode and has not been targeting the new 2.0 API explicitly. @nicolasfella, maybe we want to backport the ddca_init()
call to the 5.27 branch as well to provide a second layer of fixing?
from ddcutil.
I have pulled the code from the powerdevil master branch. Unfortunately, I don't have the KDE infrastructure to build it. What I can say is that I earlier saw the PowerDevil crash problem when booted in Fedora 39. and could recreate it in gdb. With libddcutil built from the current ddcutil 5.1.1-dev branch, the assert() failure did not occur.
from ddcutil.
It seems that arch has released an update ddcutil-2.1.0-2 that solved this problem
Well, yea, -DNDEBUG is the ultimate solution. https://gitlab.archlinux.org/archlinux/packaging/packages/ddcutil/-/blob/main/PKGBUILD?ref_type=heads#L25
I really didn't go into detail about how this was solved, but it seems that now a commit named "Fix crashes in powerdevil properly" solves the problem as it should
from ddcutil.
It seems that arch has released an update ddcutil-2.1.0-2 that solved this problem
Well, yea, -DNDEBUG is the ultimate solution. https://gitlab.archlinux.org/archlinux/packaging/packages/ddcutil/-/blob/main/PKGBUILD?ref_type=heads#L25
I really didn't go into detail about how this was solved, but it seems that now a commit named "Fix crashes in powerdevil properly" solves the problem as it should
It's taking rockowitz' patch and applying it to the existing codebase, so yeah, this one actually fixes it correctly :)
from ddcutil.
Related Issues (20)
- ddcutil 2.1.4 - display not found; ddcutil 1.4.1 works HOT 4
- ddcutil Fails to Detect EDID on New Ubuntu System with AOpen Monitor HOT 1
- TEMPORARY ALTERNATIVE REPOS HOT 1
- Does this work with Alienware AW3423DW?
- libddcutil ddca_get_display_info_list2 returns DDCRC_OTHER (-3022) HOT 2
- libddcutil behaves differently/fails after a hotplug compared to ddcutil HOT 2
- Bricked LG Monitor HOT 6
- Ubuntu 24.04 LTS prebuild package HOT 2
- Unable to set input source on Gigabyte M27Q HOT 2
- Failed assertion in check_video_adapters_list_implements_drm HOT 1
- Small suggestion for ddcutil documentation on the website HOT 1
- Dell UltraSharp 2209WAf: DDC communication failed HOT 4
- Ubuntu and Debian packages in OBS are missing libddcutil.so.x.x.x HOT 2
- Enhancement - consider packaging module loading HOT 2
- "Keeping adjust sleep multiplier" warning shown many times HOT 1
- Monitor resets many times on boot after new udev rule installed HOT 9
- System cannot enter S0ix sleep after running ddcutil detect HOT 5
- No (DisplayLink) displays found on 2.1.4, but works on 2.0.0 HOT 6
- ddcutil 2.1.4-1: DDC communication failed HOT 3
- [debian] updating linux-image pkg fails due to ddcutil dkms module failure HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ddcutil.