11:51 a.m.
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...
[2] https://bugs.kde.org/show_bug.cgi?id=370352
11:57 a.m.
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
12:48 p.m.
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
6:20 a.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to kde-leave(a)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.
6:39 a.m.
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
6:44 a.m.
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
6:47 a.m.
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
12:01 p.m.
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
12:47 p.m.
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.
12:59 p.m.
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
1:54 p.m.
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.
2:04 p.m.
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
2736
days inactive
2738
days old
12 comments
4 participants
participants (4)
-
Neal Becker -
Reindl Harald -
Rex Dieter -
Sudhir Khanger