Hello,
For months I have been suffering from this nasty bug where I can't unlock my system. I lose my data every time my Fedora KDE box hangs in the blank state.
I am trying out things Martin Gräßlin has suggested in the bug report. The first things is to switch from xorg-intel to xorg-modesettings driver. Any idea how to do it?
I have posted about it here[1] and the see the bug report here[2]. Bugs like these make me wonder why do I bother with Linux at all.
Regards, Sudhir.
[1] https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/me... [2] https://bugs.kde.org/show_bug.cgi?id=370352
Sudhir Khanger wrote:
Hello,
For months I have been suffering from this nasty bug where I can't unlock my system. I lose my data every time my Fedora KDE box hangs in the blank state.
I am trying out things Martin Gräßlin has suggested in the bug report. The first things is to switch from xorg-intel to xorg-modesettings driver. Any idea how to do it?
Easiest way imo, is to simply remove/uninstall the package: xorg-x11-drv-intel
and then modesetting should get used instead on the next reboot.
-- Rex
Sudhir Khanger wrote:
Easiest way imo, is to simply remove/uninstall the package:
xorg-x11-drv-intel
and then modesetting should get used instead on the next reboot.
Thanks Rex.
Should I expect any breakage as a result of this?
I didn't notice anything (much less any breakage).
-- Rex
Rex Dieter wrote:
Sudhir Khanger wrote:
Easiest way imo, is to simply remove/uninstall the package:
xorg-x11-drv-intel
and then modesetting should get used instead on the next reboot.
Thanks Rex.
Should I expect any breakage as a result of this?
I didn't notice anything (much less any breakage).
-- Rex _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org
The only diff I can see vs. using the suggested Section "Device" Identifier "Intel Graphics" Driver "modesetting" Option "AccelMethod" "glamor" Option "DRI3" "1" EndSection
Is that I see no mention of "DRI3" in /var/log/Xorg.0.log, so maybe this isn't on by default if you have no xorg config file with modesetting driver? Don't know if it matters.
Am 27.10.2016 um 13:20 schrieb Neal Becker:
Rex Dieter wrote:
Sudhir Khanger wrote:
Easiest way imo, is to simply remove/uninstall the package:
xorg-x11-drv-intel
and then modesetting should get used instead on the next reboot.
Thanks Rex.
Should I expect any breakage as a result of this?
I didn't notice anything (much less any breakage).
The only diff I can see vs. using the suggested Section "Device" Identifier "Intel Graphics" Driver "modesetting" Option "AccelMethod" "glamor" Option "DRI3" "1" EndSection
Is that I see no mention of "DRI3" in /var/log/Xorg.0.log, so maybe this isn't on by default if you have no xorg config file with modesetting driver? Don't know if it matters
logs indicate that with "modesetting" DRI3 is ignored or there is a difference between "DRI3 1" and "DRI 3" and it's nonsense copy&paste from somewhere else...
but i can assure that "uxa" and "DRI 3" in case of the intel driver (commented old settings bfore trying modeset did make a dramatical difference, DRI3 is AFAIK in the meantime on for the intel-drivers, maybe just the OP should try the intel driver with the settings below
# Section "Device" # Identifier "Videocard0" # Option "AccelMethod" "uxa" # Option "TearFree" "true" # Option "DRI" "3" # EndSection
[ 13.694] X.Org Video Driver: 20.0 [ 13.694] X.Org XInput driver : 22.1 [ 13.695] (II) xfree86: Adding drm device (/dev/dri/card0) [ 14.110] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 14.151] Module class: X.Org Video Driver [ 14.151] ABI class: X.Org Video Driver, version 20.0 [ 14.151] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 14.156] (II) modeset(0): using drv /dev/dri/card0 [ 14.286] (II) glamor: OpenGL accelerated X.org driver based. [ 14.479] (II) glamor: EGL version 1.4 (DRI2): [ 14.876] (II) modeset(0): [DRI2] Setup complete [ 14.876] (II) modeset(0): [DRI2] DRI driver: i965 [ 14.876] (II) modeset(0): [DRI2] VDPAU driver: i965 [ 14.939] (II) GLX: Initialized DRI2 GL provider for screen 0 [ 17.451] Module class: X.Org XInput Driver [ 17.451] ABI class: X.Org XInput driver, version 22.1
Am 27.10.2016 um 13:39 schrieb Reindl Harald:
Am 27.10.2016 um 13:20 schrieb Neal Becker:
Rex Dieter wrote:
Sudhir Khanger wrote:
Easiest way imo, is to simply remove/uninstall the package:
xorg-x11-drv-intel
and then modesetting should get used instead on the next reboot.
Should I expect any breakage as a result of this?
I didn't notice anything (much less any breakage).
The only diff I can see vs. using the suggested Section "Device" Identifier "Intel Graphics" Driver "modesetting" Option "AccelMethod" "glamor" Option "DRI3" "1" EndSection
in fact the suggsted "DRI3" is nonsense with the "modesetting" driver, it's only relevant with the intel-driver
[ 16450.853] (WW) modeset(0): Option "DRI3" is not used [ 16450.853] (II) modeset(0): [DRI2] Setup complete [ 16450.853] (II) modeset(0): [DRI2] DRI driver: i965 [ 16450.853] (II) modeset(0): [DRI2] VDPAU driver: i965
[ 16394.681] (WW) modeset(0): Option "DRI" is not used [ 16394.681] (II) modeset(0): [DRI2] Setup complete [ 16394.681] (II) modeset(0): [DRI2] DRI driver: i965 [ 16394.681] (II) modeset(0): [DRI2] VDPAU driver: i965
Is that I see no mention of "DRI3" in /var/log/Xorg.0.log, so maybe this isn't on by default if you have no xorg config file with modesetting driver? Don't know if it matters
logs indicate that with "modesetting" DRI3 is ignored or there is a difference between "DRI3 1" and "DRI 3" and it's nonsense copy&paste from somewhere else...
but i can assure that "uxa" and "DRI 3" in case of the intel driver (commented old settings bfore trying modeset did make a dramatical difference, DRI3 is AFAIK in the meantime on for the intel-drivers, maybe just the OP should try the intel driver with the settings below
# Section "Device" # Identifier "Videocard0" # Option "AccelMethod" "uxa" # Option "TearFree" "true" # Option "DRI" "3" # EndSection
[ 13.694] X.Org Video Driver: 20.0 [ 13.694] X.Org XInput driver : 22.1 [ 13.695] (II) xfree86: Adding drm device (/dev/dri/card0) [ 14.110] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 14.151] Module class: X.Org Video Driver [ 14.151] ABI class: X.Org Video Driver, version 20.0 [ 14.151] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 14.156] (II) modeset(0): using drv /dev/dri/card0 [ 14.286] (II) glamor: OpenGL accelerated X.org driver based. [ 14.479] (II) glamor: EGL version 1.4 (DRI2): [ 14.876] (II) modeset(0): [DRI2] Setup complete [ 14.876] (II) modeset(0): [DRI2] DRI driver: i965 [ 14.876] (II) modeset(0): [DRI2] VDPAU driver: i965 [ 14.939] (II) GLX: Initialized DRI2 GL provider for screen 0 [ 17.451] Module class: X.Org XInput Driver [ 17.451] ABI class: X.Org XInput driver, version 22.1
I removed the intel driver. I don't really understand the difference between them or what I am suppose to expect. So far there is no difference. I will report back to the bug report if I don't see the bug with intel drivers removed.
It would be nice to figure out what is behind this severe bug. If it's kernel or intel driver or if it is a Plasma stack bug.
Here's my Xorg.0.log https://gist.github.com/sudhirkhanger/bbf1ee49ac578a78e938e179a333dcd7
Am 26.10.2016 um 18:51 schrieb Sudhir Khanger:
For months I have been suffering from this nasty bug where I can't unlock my system. I lose my data every time my Fedora KDE box hangs in the blank state.
I am trying out things Martin Gräßlin has suggested in the bug report. The first things is to switch from xorg-intel to xorg-modesettings driver. Any idea how to do it?
[root@srv-rhsoft:~]$ cat /etc/X11/xorg.conf.d/02-intel.conf # Section "Device" # Identifier "Videocard0" # Option "AccelMethod" "uxa" # Option "TearFree" "true" # Option "DRI" "3" # EndSection
Section "Device" Identifier "Videocard0" Driver "modesetting" Option "AccelMethod" "glamor" EndSection
I have posted about it here[1] and the see the bug report here[2]. Bugs like these make me wonder why do I bother with Linux at all.
and windows would do anything you need to do fast, secure and without a ton of other issues? no it won't
Thanks Reindl will try that.
and windows would do anything you need to do fast, secure and without a
ton of other issues? no it won't
I have to hard reboot my system or restart X every time I encounter this bug which means I lose time and any unsaved work. Another option is to leave the system unlocked for everyone to pry. This happens randomly so I can never tell when I am going to lose unsaved progress which may include several hours of work and more time to reboot and get everything in the working state again. Not to mention you lose your chain of thought when this happens.
Am 26.10.2016 um 19:47 schrieb Sudhir Khanger:
Thanks Reindl will try that.
and windows would do anything you need to do fast, secure and without a
ton of other issues? no it won't
the be happy with windows - you are talking about a *single* issue here
I have to hard reboot my system or restart X every time I encounter this bug which means I lose time and any unsaved work. Another option is to leave the system unlocked for everyone to pry. This happens randomly so I can never tell when I am going to lose unsaved progress which may include several hours of work and more time to reboot and get everything in the working state again. Not to mention you lose your chain of thought when this happens.
and i have no problems at all with intel or modesetting drivers over years if KDE would fix it's damned memory leaks i would not need ot logout for days and weeks unless there is a kernel/glibc/pcre/openssl update
and i have no problems at all with intel or modesetting drivers over
years if KDE would fix it's damned memory leaks i would not need ot logout for days and weeks unless there is a kernel/glibc/pcre/openssl update
Just because you aren't affected doesn't mean it doesn't exist.
I use the dnf tracer plugin and I do weekly updates if not more and I am almost always told to either logout or reboot. I kept the logs for several weeks and then lost the interest. Either tracer plugin is faulty or the saying that Linux doesn't need to reboot/logout is false.
Am 26.10.2016 um 20:54 schrieb Sudhir Khanger:
and i have no problems at all with intel or modesetting drivers over
years if KDE would fix it's damned memory leaks i would not need ot logout for days and weeks unless there is a kernel/glibc/pcre/openssl update
Just because you aren't affected doesn't mean it doesn't exist.
where did i say that?
i am just annoyed by the silly statement "make me wonder why do I bother with Linux at all"
I use the dnf tracer plugin and I do weekly updates if not more and I am almost always told to either logout or reboot. I kept the logs for several weeks and then lost the interest. Either tracer plugin is faulty or the saying that Linux doesn't need to reboot/logout is false.
bla - i do daily updates, often enough directly from koji and have at least updates-testing enabled all the time - you likely don#t see most of my updates at all
after more than a decade i know how libraries and dependecies work togehter and in doubt "lsof | grep DEL | grep /usr" will tell you what needs to be restarted because it has old libraries in use
just reboot is the easy solution which is likely enough for the most non-technical users - when i have virtual machines with 6 GB and more vmem running which are suspended before shutdown and restored at boot while the machine is router, firewall, music daemon, WLAN-AP and what not for a whole network i try to avoid useless reboots especially in case of updates where the only entry in the changlog is some irrelevant stuff for the next fedora version and nobody knows why it was rebuilt for stable at all
-
Neal Becker -
Reindl Harald -
Rex Dieter -
Sudhir Khanger