I have 32 bit F23, F24 & F25 installed on an i845G test machine, host gx260. Plasma seems to work normally, though painfully slowly, on F23. IceWM works fine on all. F24 was created as a live (DNF) upgrade from F23 last night, while F25 was created similarly from F23 originally and later F24 many weeks ago.
Deleting the k* files from ~/.config doesn't help with $SUBJECT. Replacing ~/.config with counterparts from F23 or F25 doesn't help, other than getting Konsole to autostart and thus allow me to do something besides shove the mouse pointer around. No .xsession-errors is being generated.
https://openqa.fedoraproject.org/tests/14439 shows a similar result.
Tail of ps -A run right before closing F25 session via script run in Konsole showed as follows:
1277 tty2 00:00:00 mc 1278 ? 00:00:00 cons.saver 1279 pts/0 00:00:00 bash 1297 ? 00:00:00 kworker/0:1 1298 tty3 00:00:00 startx 1320 tty3 00:00:00 xinit 1321 tty3 00:00:02 Xorg 1324 ? 00:00:00 startkde 1333 ? 00:00:00 dbus-launch 1334 ? 00:00:00 dbus-daemon 1347 ? 00:00:00 ssh-agent 1383 ? 00:00:00 start_kdeinit 1384 ? 00:00:00 kdeinit5 1385 ? 00:00:00 klauncher 1388 ? 00:00:01 kded5 1390 ? 00:00:00 kcminit_startup 1405 ? 00:00:01 kglobalaccel5 1407 ? 00:00:00 kwrapper5 1409 ? 00:00:01 ksmserver 1410 ? 00:00:00 kaccess 1415 ? 00:00:00 kactivitymanage 1425 ? 00:00:01 kwin_x11 1426 ? 00:00:00 baloo_file 1429 ? 00:00:02 krunner 1434 ? 00:00:00 kscreen_backend 1439 ? 00:00:05 plasmashell 1449 ? 00:00:00 polkit-kde-auth 1455 ? 00:00:00 xembedsniproxy 1462 ? 00:00:00 kmix 1468 ? 00:00:01 konsole 1477 pts/1 00:00:00 bash 1483 pts/2 00:00:00 bash 1533 ? 00:00:00 drkonqi 1545 ? 00:00:00 kworker/u8:2 1550 pts/1 00:00:00 ps
What, if anything, can I do that might lead to whatever this bug is getting fixed? I don't see any open BRC bugs that I can recognize as being on point. This is not the first F24 installation I've had acting similarly. Total F24 installations here, both 32 bit and 64, is upwards of a dozen.
BTW, the restore previous session setting is not producing a restoring of the Konsole session left open on session close, only an empty desktop.
So, you have a dozen installs of not quite beta level software AND how many of a Fedora version that's not even in rawhide yet (that I'm aware anyway)?
I'm terribly lost here.
On Mon, Apr 25, 2016 at 4:32 PM, Felix Miata mrmazda@earthlink.net wrote:
I have 32 bit F23, F24 & F25 installed on an i845G test machine, host gx260. Plasma seems to work normally, though painfully slowly, on F23. IceWM works fine on all. F24 was created as a live (DNF) upgrade from F23 last night, while F25 was created similarly from F23 originally and later F24 many weeks ago.
Deleting the k* files from ~/.config doesn't help with $SUBJECT. Replacing ~/.config with counterparts from F23 or F25 doesn't help, other than getting Konsole to autostart and thus allow me to do something besides shove the mouse pointer around. No .xsession-errors is being generated.
https://openqa.fedoraproject.org/tests/14439 shows a similar result.
Tail of ps -A run right before closing F25 session via script run in Konsole showed as follows:
1277 tty2 00:00:00 mc 1278 ? 00:00:00 cons.saver 1279 pts/0 00:00:00 bash 1297 ? 00:00:00 kworker/0:1 1298 tty3 00:00:00 startx 1320 tty3 00:00:00 xinit 1321 tty3 00:00:02 Xorg 1324 ? 00:00:00 startkde 1333 ? 00:00:00 dbus-launch 1334 ? 00:00:00 dbus-daemon 1347 ? 00:00:00 ssh-agent 1383 ? 00:00:00 start_kdeinit 1384 ? 00:00:00 kdeinit5 1385 ? 00:00:00 klauncher 1388 ? 00:00:01 kded5 1390 ? 00:00:00 kcminit_startup 1405 ? 00:00:01 kglobalaccel5 1407 ? 00:00:00 kwrapper5 1409 ? 00:00:01 ksmserver 1410 ? 00:00:00 kaccess 1415 ? 00:00:00 kactivitymanage 1425 ? 00:00:01 kwin_x11 1426 ? 00:00:00 baloo_file 1429 ? 00:00:02 krunner 1434 ? 00:00:00 kscreen_backend 1439 ? 00:00:05 plasmashell 1449 ? 00:00:00 polkit-kde-auth 1455 ? 00:00:00 xembedsniproxy 1462 ? 00:00:00 kmix 1468 ? 00:00:01 konsole 1477 pts/1 00:00:00 bash 1483 pts/2 00:00:00 bash 1533 ? 00:00:00 drkonqi 1545 ? 00:00:00 kworker/u8:2 1550 pts/1 00:00:00 ps
What, if anything, can I do that might lead to whatever this bug is getting fixed? I don't see any open BRC bugs that I can recognize as being on point. This is not the first F24 installation I've had acting similarly. Total F24 installations here, both 32 bit and 64, is upwards of a dozen.
BTW, the restore previous session setting is not producing a restoring of the Konsole session left open on session close, only an empty desktop. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/ _______________________________________________ kde mailing list kde@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kde@lists.fedoraproject.org
Mark Haney composed on 2016-04-25 17:29 (UTC-0400):
Felix Miata wrote:
I have 32 bit F23, F24 & F25 installed on an i845G test machine, host gx260. Plasma seems to work normally, though painfully slowly, on F23. IceWM works fine on all. F24 was created as a live (DNF) upgrade from F23 last night, while F25 was created similarly from F23 originally and later F24 many weeks ago.
Deleting the k* files from ~/.config doesn't help with $SUBJECT. Replacing ~/.config with counterparts from F23 or F25 doesn't help, other than getting Konsole to autostart and thus allow me to do something besides shove the mouse pointer around. No .xsession-errors is being generated.
https://openqa.fedoraproject.org/tests/14439 shows a similar result.
Tail of ps -A run right before closing F25 session via script run in Konsole showed as follows:
1277 tty2 00:00:00 mc 1278 ? 00:00:00 cons.saver 1279 pts/0 00:00:00 bash 1297 ? 00:00:00 kworker/0:1 1298 tty3 00:00:00 startx 1320 tty3 00:00:00 xinit 1321 tty3 00:00:02 Xorg 1324 ? 00:00:00 startkde 1333 ? 00:00:00 dbus-launch 1334 ? 00:00:00 dbus-daemon 1347 ? 00:00:00 ssh-agent 1383 ? 00:00:00 start_kdeinit 1384 ? 00:00:00 kdeinit5 1385 ? 00:00:00 klauncher 1388 ? 00:00:01 kded5 1390 ? 00:00:00 kcminit_startup 1405 ? 00:00:01 kglobalaccel5 1407 ? 00:00:00 kwrapper5 1409 ? 00:00:01 ksmserver 1410 ? 00:00:00 kaccess 1415 ? 00:00:00 kactivitymanage 1425 ? 00:00:01 kwin_x11 1426 ? 00:00:00 baloo_file 1429 ? 00:00:02 krunner 1434 ? 00:00:00 kscreen_backend 1439 ? 00:00:05 plasmashell 1449 ? 00:00:00 polkit-kde-auth 1455 ? 00:00:00 xembedsniproxy 1462 ? 00:00:00 kmix 1468 ? 00:00:01 konsole 1477 pts/1 00:00:00 bash 1483 pts/2 00:00:00 bash 1533 ? 00:00:00 drkonqi 1545 ? 00:00:00 kworker/u8:2 1550 pts/1 00:00:00 ps
What, if anything, can I do that might lead to whatever this bug is getting fixed? I don't see any open BRC bugs that I can recognize as being on point. This is not the first F24 installation I've had acting similarly. Total F24 installations here, both 32 bit and 64, is upwards of a dozen.
BTW, the restore previous session setting is not producing a restoring of the Konsole session left open on session close, only an empty desktop.
So, you have a dozen installs of not quite beta level software AND how many of a Fedora version that's not even in rawhide yet (that I'm aware anyway)?
# grep 25 /etc/os-release VERSION="25 (Rawhide)" VERSION_ID=25 PRETTY_NAME="Fedora 25 (Rawhide)" CPE_NAME="cpe:/o:fedoraproject:fedora:25"
"25" is the first string that shows up in that identification file as an identifying element, and what will be its attributed release number both when it's branched off of Rawhide, and later when it's no longer supported with updates. It should be clear enough to most Fedora users that any F## that doesn't equate to an announced Fedora final release and has not yet been branched off of Rawhide does equate to Rawhide.
I'm terribly lost here.
I have more than a dozen machines on which all have both F23 and F24 installed, and half or more of which in addition have Rawhide installed. I don't keep a comprehensive exact inventory. I have annotated logs of the HD partitions to see what's on any particular machine that I use to facilitate choosing what to use for particular testing I'm interested in doing.
Un-lost now?
Felix Miata composed on 2016-04-25 16:32 (UTC-0400):
I have 32 bit F23, F24 & F25 installed on an i845G test machine, host gx260. Plasma seems to work normally, though painfully slowly, on F23. IceWM works fine on all. F24 was created as a live (DNF) upgrade from F23 last night, while F25 was created similarly from F23 originally and later F24 many weeks ago.
Deleting the k* files from ~/.config doesn't help with $SUBJECT. Replacing ~/.config with counterparts from F23 or F25 doesn't help, other than getting Konsole to autostart and thus allow me to do something besides shove the mouse pointer around. No .xsession-errors is being generated.
https://openqa.fedoraproject.org/tests/14439 shows a similar result.
Tail of ps -A run right before closing F25 session via script run in Konsole showed as follows:
1277 tty2 00:00:00 mc 1278 ? 00:00:00 cons.saver 1279 pts/0 00:00:00 bash 1297 ? 00:00:00 kworker/0:1 1298 tty3 00:00:00 startx 1320 tty3 00:00:00 xinit 1321 tty3 00:00:02 Xorg 1324 ? 00:00:00 startkde 1333 ? 00:00:00 dbus-launch 1334 ? 00:00:00 dbus-daemon 1347 ? 00:00:00 ssh-agent 1383 ? 00:00:00 start_kdeinit 1384 ? 00:00:00 kdeinit5 1385 ? 00:00:00 klauncher 1388 ? 00:00:01 kded5 1390 ? 00:00:00 kcminit_startup 1405 ? 00:00:01 kglobalaccel5 1407 ? 00:00:00 kwrapper5 1409 ? 00:00:01 ksmserver 1410 ? 00:00:00 kaccess 1415 ? 00:00:00 kactivitymanage 1425 ? 00:00:01 kwin_x11 1426 ? 00:00:00 baloo_file 1429 ? 00:00:02 krunner 1434 ? 00:00:00 kscreen_backend 1439 ? 00:00:05 plasmashell 1449 ? 00:00:00 polkit-kde-auth 1455 ? 00:00:00 xembedsniproxy 1462 ? 00:00:00 kmix 1468 ? 00:00:01 konsole 1477 pts/1 00:00:00 bash 1483 pts/2 00:00:00 bash 1533 ? 00:00:00 drkonqi 1545 ? 00:00:00 kworker/u8:2 1550 pts/1 00:00:00 ps
What, if anything, can I do that might lead to whatever this bug is getting fixed? I don't see any open BRC bugs that I can recognize as being on point. This is not the first F24 installation I've had acting similarly. Total F24 installations here, both 32 bit and 64, is upwards of a dozen.
Same problem on i865G host gx27c in freshly updated F24.
BTW, the restore previous session setting is not producing a restoring of the Konsole session left open on session close, only an empty desktop.
Konsole is restored on restart on gx27c, after having gotten it open via Alt-F2.
On Thu, 2016-04-28 at 15:24 -0400, Felix Miata wrote:
Same problem on i865G host gx27c in freshly updated F24.
BTW, the restore previous session setting is not producing a restoring of the Konsole session left open on session close, only an empty desktop.
Konsole is restored on restart on gx27c, after having gotten it open via Alt-F2.
I filed a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1331593
if there was already one, though, please close as a dupe (and tag the original with 'openqa'). Thanks!
Adam Williamson wrote:
On Thu, 2016-04-28 at 15:24 -0400, Felix Miata wrote:
Same problem on i865G host gx27c in freshly updated F24.
BTW, the restore previous session setting is not producing a restoring of the Konsole session left open on session close, only an empty desktop.
Konsole is restored on restart on gx27c, after having gotten it open via Alt-F2.
I filed a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1331593
if there was already one, though, please close as a dupe (and tag the original with 'openqa'). Thanks!
The symptoms are similar to when plasmashell deadlocks, so getting a backtrace from the presumably-deadlocked plasmashell process may be helpful in diagnosing what's going on.
-- Rex
Rex Dieter composed on 2016-04-29 05:36 (UTC-0500):
Adam Williamson wrote:
On Thu, 2016-04-28 at 15:24 -0400, Felix Miata wrote:
Same problem on i865G host gx27c in freshly updated F24.
BTW, the restore previous session setting is not producing a restoring of the Konsole session left open on session close, only an empty desktop.
Konsole is restored on restart on gx27c, after having gotten it open via Alt-F2.
I filed a bug:
if there was already one, though, please close as a dupe (and tag the original with 'openqa'). Thanks!
The symptoms are similar to when plasmashell deadlocks, so getting a backtrace from the presumably-deadlocked plasmashell process may be helpful in diagnosing what's going on.
In order to preserve limited / filesystem space, I tried minimally following the instructions at https://fedoraproject.org/wiki/StackTraces by installing only gdb and plasma-workspace-debuginfo, but the instructions don't say how to find the coredump. The only one that looked right by name and timestamp is in /var/lib/systemd/coredump/core.plasmashell<blah>.lz4 (@23059K). Gdb complains about that file:
....lz4 is not a core dump. File format not recognized.
Now what do I do?
Felix Miata composed on 2016-04-29 21:07 (UTC-0400):
Rex Dieter composed on 2016-04-29 05:36 (UTC-0500):
Adam Williamson wrote:
On Thu, 2016-04-28 at 15:24 -0400, Felix Miata wrote:
Same problem on i865G host gx27c in freshly updated F24.
BTW, the restore previous session setting is not producing a restoring of the Konsole session left open on session close, only an empty desktop.
Konsole is restored on restart on gx27c, after having gotten it open via Alt-F2.
I filed a bug:
if there was already one, though, please close as a dupe (and tag the original with 'openqa'). Thanks!
The symptoms are similar to when plasmashell deadlocks, so getting a backtrace from the presumably-deadlocked plasmashell process may be helpful in diagnosing what's going on.
In order to preserve limited / filesystem space, I tried minimally following the instructions at https://fedoraproject.org/wiki/StackTraces by installing only gdb and plasma-workspace-debuginfo, but the instructions don't say how to find the coredump. The only one that looked right by name and timestamp is in /var/lib/systemd/coredump/core.plasmashell<blah>.lz4 (@23059K). Gdb complains about that file:
....lz4 is not a core dump. File format not recognized.
Now what do I do?
I found out how to disable core compression and generated a new core, except I got 5 KDE cores[1] rather than one. I tried on the one with plasmashell in the name, and gdb complains "No symbol table info available over and over and waits on me to tell it what next. :-(
[1] drkonqi, kactivitymanager, kactivitymanager, klauncher, plasmashell
Felix Miata composed on 2016-04-29 21:33 (UTC-0400):
Felix Miata composed on 2016-04-29 21:07 (UTC-0400):
Rex Dieter composed on 2016-04-29 05:36 (UTC-0500):
Adam Williamson wrote:
On Thu, 2016-04-28 at 15:24 -0400, Felix Miata wrote:
Same problem on i865G host gx27c in freshly updated F24.
BTW, the restore previous session setting is not producing a restoring of the Konsole session left open on session close, only an empty desktop.
Konsole is restored on restart on gx27c, after having gotten it open via Alt-F2.
I filed a bug:
if there was already one, though, please close as a dupe (and tag the original with 'openqa'). Thanks!
The symptoms are similar to when plasmashell deadlocks, so getting a backtrace from the presumably-deadlocked plasmashell process may be helpful in diagnosing what's going on.
In order to preserve limited / filesystem space, I tried minimally following the instructions at https://fedoraproject.org/wiki/StackTraces by installing only gdb and plasma-workspace-debuginfo, but the instructions don't say how to find the coredump. The only one that looked right by name and timestamp is in /var/lib/systemd/coredump/core.plasmashell<blah>.lz4 (@23059K). Gdb complains about that file:
....lz4 is not a core dump. File format not recognized.
Now what do I do?
I found out how to disable core compression and generated a new core, except I got 5 KDE cores[1] rather than one. I tried on the one with plasmashell in the name, and gdb complains "No symbol table info available over and over and waits on me to tell it what next. :-(
[1] drkonqi, kactivitymanager, kactivitymanager, klauncher, plasmashell
I attached gdb to the running plasmashell, and gdb complains I need to use up 80% of the size of the whole / filesystem, which currently has 30% free, installing 205 packages. There's barely enough freespace to download the 1.2G of packages, and clearly too little room to install them.
On 04/29/2016 10:53 PM, Felix Miata wrote:
Felix Miata composed on 2016-04-29 21:33 (UTC-0400):
Felix Miata composed on 2016-04-29 21:07 (UTC-0400):
Rex Dieter composed on 2016-04-29 05:36 (UTC-0500):
Adam Williamson wrote:
On Thu, 2016-04-28 at 15:24 -0400, Felix Miata wrote:
Same problem on i865G host gx27c in freshly updated F24.
> BTW, the restore previous session setting is not producing a restoring > of the Konsole session left open on session close, only an empty > desktop.
Konsole is restored on restart on gx27c, after having gotten it open via Alt-F2.
I filed a bug:
if there was already one, though, please close as a dupe (and tag the original with 'openqa'). Thanks!
The symptoms are similar to when plasmashell deadlocks, so getting a backtrace from the presumably-deadlocked plasmashell process may be helpful in diagnosing what's going on.
In order to preserve limited / filesystem space, I tried minimally following the instructions at https://fedoraproject.org/wiki/StackTraces by installing only gdb and plasma-workspace-debuginfo, but the instructions don't say how to find the coredump. The only one that looked right by name and timestamp is in /var/lib/systemd/coredump/core.plasmashell<blah>.lz4 (@23059K). Gdb complains about that file:
....lz4 is not a core dump. File format not recognized.Now what do I do?
I found out how to disable core compression and generated a new core, except I got 5 KDE cores[1] rather than one. I tried on the one with plasmashell in the name, and gdb complains "No symbol table info available over and over and waits on me to tell it what next. :-(
[1] drkonqi, kactivitymanager, kactivitymanager, klauncher, plasmashell
I attached gdb to the running plasmashell, and gdb complains I need to use up 80% of the size of the whole / filesystem, which currently has 30% free, installing 205 packages. There's barely enough freespace to download the 1.2G of packages, and clearly too little room to install them.
What size is your / filesystem?
Rex Dieter wrote:
Felix Miata wrote:
I attached gdb to the running plasmashell, and gdb complains I need to use up 80% of the size of the whole / filesystem
Ignore that, and generate a backtrace anyway (though it may be incomplete due to incomplete -debuginfo). We'll see how useful it is.
Oh, and make sure to include all threads, generate backtrace with:
thread apply all backtrace
Rex Dieter composed on 2016-04-30 07:56 (UTC-0500):
Rex Dieter wrote:
Felix Miata wrote:
I attached gdb to the running plasmashell, and gdb complains I need to use up 80% of the size of the whole / filesystem
Ignore that, and generate a backtrace anyway (though it may be incomplete due to incomplete -debuginfo). We'll see how useful it is.
Oh, and make sure to include all threads, generate backtrace with:
thread apply all backtrace
(gdb) thread apply all backtrace
Thread 10 (Thread 0xa5330b40 (LWP 1303)): #0 0xb776adb1 in __kernel_vsyscall () #1 0xb497d07f in poll () from /lib/libc.so.6 #2 0xb3ef709c in g_poll () from /lib/libglib-2.0.so.0 #3 0xb3ee7f78 in g_main_context_iterate.isra () from /lib/libglib-2.0.so.0 #4 0xb3ee80c7 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #5 0xb4f4868f in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #6 0xb4ee3cc0 in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #7 0xb4cf018b in QThread::exec() () from /lib/libQt5Core.so.5 #8 0xb6c975d1 in QQuickPixmapReader::run() () from /lib/libQt5Quick.so.5 #9 0xb4cf6487 in QThreadPrivate::start(void*) () from /lib/libQt5Core.so.5 #10 0xb46c23be in start_thread () from /lib/libpthread.so.0 #11 0xb4989d8e in clone () from /lib/libc.so.6
Thread 9 (Thread 0xa6a67b40 (LWP 1296)): #0 0xb776adb1 in __kernel_vsyscall () #1 0xb46c754c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb75e72c6 in QTWTF::TCMalloc_PageHeap::scavengerThread() () from /lib/libQt5Script.so.5 #3 0xb75e7310 in QTWTF::TCMalloc_PageHeap::runScavengerThread(void*) () from /lib/libQt5Script.so.5 #4 0xb46c23be in start_thread () from /lib/libpthread.so.0 #5 0xb4989d8e in clone () from /lib/libc.so.6
Thread 8 (Thread 0xa7b4cb40 (LWP 1290)): #0 0xb776adb1 in __kernel_vsyscall () #1 0xb497d07f in poll () from /lib/libc.so.6 #2 0xb3ef709c in g_poll () from /lib/libglib-2.0.so.0 #3 0xb3ee7f78 in g_main_context_iterate.isra () from /lib/libglib-2.0.so.0 #4 0xb3ee80c7 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #5 0xb4f48670 in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #6 0xb4ee3cc0 in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #7 0xb4cf018b in QThread::exec() () from /lib/libQt5Core.so.5 #8 0xb692f090 in QQmlThreadPrivate::run() () from /lib/sse2/libQt5Qml.so.5 #9 0xb4cf6487 in QThreadPrivate::start(void*) () from /lib/libQt5Core.so.5 #10 0xb46c23be in start_thread () from /lib/libpthread.so.0 #11 0xb4989d8e in clone () from /lib/libc.so.6
Thread 7 (Thread 0xa8d54b40 (LWP 1285)): #0 0xb776adb1 in __kernel_vsyscall () #1 0xb497d07f in poll () from /lib/libc.so.6 #2 0xb3ef709c in g_poll () from /lib/libglib-2.0.so.0 #3 0xb3ee7f78 in g_main_context_iterate.isra () from /lib/libglib-2.0.so.0 ---Type <return> to continue, or q <return> to quit---
Rex Dieter composed on 2016-04-30 07:56 (UTC-0500):
Rex Dieter wrote:
Felix Miata wrote:
I attached gdb to the running plasmashell, and gdb complains I need to use up 80% of the size of the whole / filesystem
Ignore that, and generate a backtrace anyway (though it may be incomplete due to incomplete -debuginfo). We'll see how useful it is.
Oh, and make sure to include all threads, generate backtrace with:
thread apply all backtrace
(gdb) thread apply all backtrace
Thread 10 (Thread 0xa5330b40 (LWP 1303)): #0 0xb776adb1 in __kernel_vsyscall () #1 0xb497d07f in poll () from /lib/libc.so.6 #2 0xb3ef709c in g_poll () from /lib/libglib-2.0.so.0 #3 0xb3ee7f78 in g_main_context_iterate.isra () from /lib/libglib-2.0.so.0 #4 0xb3ee80c7 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #5 0xb4f4868f in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #6 0xb4ee3cc0 in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #7 0xb4cf018b in QThread::exec() () from /lib/libQt5Core.so.5 #8 0xb6c975d1 in QQuickPixmapReader::run() () from /lib/libQt5Quick.so.5 #9 0xb4cf6487 in QThreadPrivate::start(void*) () from /lib/libQt5Core.so.5 #10 0xb46c23be in start_thread () from /lib/libpthread.so.0 #11 0xb4989d8e in clone () from /lib/libc.so.6
Thread 9 (Thread 0xa6a67b40 (LWP 1296)): #0 0xb776adb1 in __kernel_vsyscall () #1 0xb46c754c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb75e72c6 in QTWTF::TCMalloc_PageHeap::scavengerThread() () from /lib/libQt5Script.so.5 #3 0xb75e7310 in QTWTF::TCMalloc_PageHeap::runScavengerThread(void*) () from /lib/libQt5Script.so.5 #4 0xb46c23be in start_thread () from /lib/libpthread.so.0 #5 0xb4989d8e in clone () from /lib/libc.so.6
Thread 8 (Thread 0xa7b4cb40 (LWP 1290)): #0 0xb776adb1 in __kernel_vsyscall () #1 0xb497d07f in poll () from /lib/libc.so.6 #2 0xb3ef709c in g_poll () from /lib/libglib-2.0.so.0 #3 0xb3ee7f78 in g_main_context_iterate.isra () from /lib/libglib-2.0.so.0 #4 0xb3ee80c7 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #5 0xb4f48670 in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #6 0xb4ee3cc0 in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #7 0xb4cf018b in QThread::exec() () from /lib/libQt5Core.so.5 #8 0xb692f090 in QQmlThreadPrivate::run() () from /lib/sse2/libQt5Qml.so.5 #9 0xb4cf6487 in QThreadPrivate::start(void*) () from /lib/libQt5Core.so.5 #10 0xb46c23be in start_thread () from /lib/libpthread.so.0 #11 0xb4989d8e in clone () from /lib/libc.so.6
Thread 7 (Thread 0xa8d54b40 (LWP 1285)): #0 0xb776adb1 in __kernel_vsyscall () #1 0xb497d07f in poll () from /lib/libc.so.6 #2 0xb3ef709c in g_poll () from /lib/libglib-2.0.so.0 #3 0xb3ee7f78 in g_main_context_iterate.isra () from /lib/libglib-2.0.so.0 ---Type <return> to continue, or q <return> to quit--- - #4 0xb3ee80c7 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #5 0xb4f48670 in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #6 0xb4ee3cc0 in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #7 0xb4cf018b in QThread::exec() () from /lib/libQt5Core.so.5 #8 0xb692f090 in QQmlThreadPrivate::run() () from /lib/sse2/libQt5Qml.so.5 #9 0xb4cf6487 in QThreadPrivate::start(void*) () from /lib/libQt5Core.so.5 #10 0xb46c23be in start_thread () from /lib/libpthread.so.0 #11 0xb4989d8e in clone () from /lib/libc.so.6
Thread 6 (Thread 0xaa5eab40 (LWP 1284)): #0 0xb776adb1 in __kernel_vsyscall () #1 0xb46c754c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xadaf586c in thread_function () from /usr/lib/dri/swrast_dri.so #3 0xb46c23be in start_thread () from /lib/libpthread.so.0 #4 0xb4989d8e in clone () from /lib/libc.so.6
Thread 5 (Thread 0xaadebb40 (LWP 1283)): #0 0xb776adb1 in __kernel_vsyscall () #1 0xb46c754c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xadaf586c in thread_function () from /usr/lib/dri/swrast_dri.so #3 0xb46c23be in start_thread () from /lib/libpthread.so.0 #4 0xb4989d8e in clone () from /lib/libc.so.6
Thread 4 (Thread 0xaf2f4b40 (LWP 1278)): #0 0xb776adb1 in __kernel_vsyscall () #1 0xb497d07f in poll () from /lib/libc.so.6 #2 0xb3ef709c in g_poll () from /lib/libglib-2.0.so.0 #3 0xb3ee7f78 in g_main_context_iterate.isra () from /lib/libglib-2.0.so.0 #4 0xb3ee80c7 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #5 0xb4f48670 in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #6 0xb4ee3cc0 in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #7 0xb4cf018b in QThread::exec() () from /lib/libQt5Core.so.5 #8 0xb692f090 in QQmlThreadPrivate::run() () from /lib/sse2/libQt5Qml.so.5 #9 0xb4cf6487 in QThreadPrivate::start(void*) () from /lib/libQt5Core.so.5 #10 0xb46c23be in start_thread () from /lib/libpthread.so.0 #11 0xb4989d8e in clone () from /lib/libc.so.6
Thread 3 (Thread 0xb0647b40 (LWP 1269)): #0 0xb4f47c90 in postEventSourceCheck(_GSource*) () from /lib/libQt5Core.so.5 #1 0xb3ee790f in g_main_context_check () from /lib/libglib-2.0.so.0 #2 0xb3ee7f12 in g_main_context_iterate.isra () from /lib/libglib-2.0.so.0 #3 0xb3ee80c7 in g_main_context_iteration () from /lib/libglib-2.0.so.0 ---Type <return> to continue, or q <return> to quit--- #4 0xb4f4868f in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #5 0xb4ee3cc0 in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /lib/libQt5Core.so.5 #6 0xb4cf018b in QThread::exec() () from /lib/libQt5Core.so.5 #7 0xb56c17f1 in QDBusConnectionManager::run() () from /lib/libQt5DBus.so.5 #8 0xb4cf6487 in QThreadPrivate::start(void*) () from /lib/libQt5Core.so.5 #9 0xb46c23be in start_thread () from /lib/libpthread.so.0 #10 0xb4989d8e in clone () from /lib/libc.so.6
Thread 2 (Thread 0xb1158b40 (LWP 1267)): #0 0xb776adb1 in __kernel_vsyscall () #1 0xb497d07f in poll () from /lib/libc.so.6 #2 0xb70ba518 in _xcb_conn_wait () from /lib/libxcb.so.1 #3 0xb70bc880 in xcb_wait_for_event () from /lib/libxcb.so.1 #4 0xb13aac0b in QXcbEventReader::run() () from /lib/libQt5XcbQpa.so.5 #5 0xb4cf6487 in QThreadPrivate::start(void*) () from /lib/libQt5Core.so.5 #6 0xb46c23be in start_thread () from /lib/libpthread.so.0 #7 0xb4989d8e in clone () from /lib/libc.so.6
Thread 1 (Thread 0xb177c840 (LWP 1263)): #0 0xb776adb1 in __kernel_vsyscall () #1 0xb4947f9a in nanosleep () from /lib/libc.so.6 #2 0xb4947ec5 in sleep () from /lib/libc.so.6 #3 0xb774c1ec in KCrash::startProcess(int, char const**, bool) () from /lib/libKF5Crash.so.5 #4 0xb774c684 in KCrash::defaultCrashHandler(int) () from /lib/libKF5Crash.so.5 #5 <signal handler called> #6 0xa7c9c4b5 in ?? () #7 0x7ffe0000 in ?? () #8 0xa3d3bb60 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb)
I tried to change the "Look And Feel" from Breeze to F24 by opening systemsettings5 from Konsole. Could this be a clue?
"kcm_lookandfeel" "The shared library was not found." Plugin search paths are ("/usr/lib/qt5/plugins", "/usr/bin") The environment variable QT_PLUGIN_PATH might be not correctly set Trying to use rootObject before initialization is completed, whilst using setInitializationDelayed. Forcing completion
Felix Miata wrote:
I tried to change the "Look And Feel" from Breeze to F24 by opening systemsettings5 from Konsole. Could this be a clue?
"kcm_lookandfeel" "The shared library was not found." Plugin search paths are ("/usr/lib/qt5/plugins", "/usr/bin") The environment variable QT_PLUGIN_PATH might be not correctly set Trying to use rootObject before initialization is completed, whilst using setInitializationDelayed. Forcing completion
I get the same error/warnings on x86_64, but it still shows properly.
I think that warning comes from the fact that kcm_lookandfeel actually lives under /usr/lib(64)/qt5/plugins/kcms
and moving it up one dir makes the warning go away at least.
Can you test if moving (or copying) /usr/lib/qt5/plugins/kcms/kcm_lookandfeel.so to /usr/lib/qt5/plugins/kcm_lookandfeel.so
helps or not? (I'm guessing no, but you never know)
-- Rex
Rex Dieter composed on 2016-05-02 09:25 (UTC-0500):
Felix Miata wrote:
I tried to change the "Look And Feel" from Breeze to F24 by opening systemsettings5 from Konsole. Could this be a clue?
"kcm_lookandfeel" "The shared library was not found." Plugin search paths are ("/usr/lib/qt5/plugins", "/usr/bin") The environment variable QT_PLUGIN_PATH might be not correctly set Trying to use rootObject before initialization is completed, whilst using setInitializationDelayed. Forcing completion
I get the same error/warnings on x86_64, but it still shows properly.
I think that warning comes from the fact that kcm_lookandfeel actually lives under /usr/lib(64)/qt5/plugins/kcms
and moving it up one dir makes the warning go away at least.
Can you test if moving (or copying) /usr/lib/qt5/plugins/kcms/kcm_lookandfeel.so to /usr/lib/qt5/plugins/kcm_lookandfeel.so
helps or not? (I'm guessing no, but you never know)
Making a symlink made the error message go away, but nothing else I can tell about.
To be clear, this not happening only on 32 bit Intel video installations, but also:
nouveau NV11 host gx270 radeon rv200 host gx27b
All these i686 lockups and failures bugs and threads are getting me confused. Latest iteration is kernel boots, I login, startx, and machine's own UI locks up. This is from remote login (where reboot and systemctl reboot commands both fail to restart the machine):
[ 3796.792487] ------------[ cut here ]------------ [ 3796.792744] kernel BUG at include/linux/page-flags.h:272! [ 3796.793037] invalid opcode: 0000 [#1] SMP [ 3796.793143] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache cfg80211 rfkill fuse snd_intel8x0 snd_ac97_codec ac97_bus i915 snd_seq iTCO_wdt gpio_ich snd_seq_device iTCO_vendor_support ppdev snd_pcm dcdbas tg3 video i2c_algo_bit drm_kms_helper ptp snd_timer lpc_ich pps_core parport_pc parport snd i2c_i801 drm soundcore fjes acpi_cpufreq tpm_tis tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc serio_raw ata_generic pata_acpi [ 3796.793143] CPU: 0 PID: 1014 Comm: Xorg Not tainted 4.6.0-0.rc5.git3.1.fc25.i686+PAE #1 [ 3796.793143] Hardware name: Dell Inc. OptiPlex GX280 / , BIOS A07 11/29/2005 [ 3796.793143] task: ee080000 ti: ee206000 task.ti: ee206000 [ 3796.793143] EIP: 0060:[<f81b196a>] EFLAGS: 00013286 CPU: 0 [ 3796.793143] EIP is at drm_pci_alloc+0xca/0x1c0 [drm] [ 3796.793143] EAX: 00000000 EBX: 00004000 ECX: f4c16940 EDX: 00000007 [ 3796.793143] ESI: f0a67320 EDI: c0436d90 EBP: ee207b80 ESP: ee207b58 [ 3796.793143] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 3796.793143] CR0: 80050033 CR2: 08e70104 CR3: 30a69d80 CR4: 000006f0 [ 3796.793143] Stack: [ 3796.793143] 2e280000 00000000 ee280000 f46b2864 ee280000 024040c0 ee4d1eb7 00000000 [ 3796.793143] ee21ea80 ee21eb1c ee207b98 f8784857 00000100 f2e66400 f16f5300 f16f5a80 [ 3796.793143] ee207bcc f87d02d3 00003246 00000000 00000001 00000000 f87c7626 f30fd800 [ 3796.793143] Call Trace: [ 3796.793143] [<f8784857>] i915_gem_object_attach_phys+0xf7/0x1a0 [i915] [ 3796.793143] [<f87d02d3>] intel_prepare_plane_fb+0x193/0x310 [i915] [ 3796.793143] [<f87c7626>] ? intel_atomic_commit+0x96/0x1980 [i915] [ 3796.793143] [<f818a545>] drm_atomic_helper_prepare_planes+0x45/0xb0 [drm_kms_helper] [ 3796.793143] [<f87c781c>] intel_atomic_commit+0x28c/0x1980 [i915] [ 3796.793143] [<f87c9cae>] ? intel_atomic_check+0x30e/0x10e0 [i915] [ 3796.793143] [<c060f200>] ? __kmalloc_track_caller+0x290/0x350 [ 3796.793143] [<f87c99a0>] ? intel_link_compute_m_n+0x50/0x50 [i915] [ 3796.793143] [<f81c76df>] ? drm_atomic_check_only+0x19f/0x670 [drm] [ 3796.793143] [<f81c6e72>] ? drm_atomic_get_crtc_state+0x52/0xb0 [drm] [ 3796.793143] [<c05cf34a>] ? kmemdup+0x2a/0x40 [ 3796.793143] [<f81c7be2>] drm_atomic_commit+0x32/0x60 [drm] [ 3796.793143] [<f818b025>] drm_atomic_helper_update_plane+0xc5/0x110 [drm_kms_helper] [ 3796.793143] [<f81b78af>] __setplane_internal+0x20f/0x260 [drm] [ 3796.793143] [<f81b7a79>] drm_mode_cursor_common+0x179/0x390 [drm] [ 3796.793143] [<f81bb410>] ? drm_mode_setcrtc+0x580/0x580 [drm] [ 3796.793143] [<f81bb467>] drm_mode_cursor_ioctl+0x57/0x70 [drm] [ 3796.793143] [<f81abb09>] drm_ioctl+0x149/0x520 [drm] [ 3796.793143] [<c043a5e8>] ? sched_clock+0x8/0x10 [ 3796.793143] [<f81bb410>] ? drm_mode_setcrtc+0x580/0x580 [drm] [ 3796.793143] [<c043a5e8>] ? sched_clock+0x8/0x10 [ 3796.793143] [<c04b5c89>] ? sched_clock_local+0x49/0x180 [ 3796.793143] [<c04b5ff7>] ? sched_clock_cpu+0x107/0x170 [ 3796.793143] [<f81ab9c0>] ? drm_getmap+0xc0/0xc0 [drm] [ 3796.793143] [<c063cf71>] do_vfs_ioctl+0x91/0x850 [ 3796.793143] [<c04b60a3>] ? local_clock+0x13/0x20 [ 3796.793143] [<c04f99ba>] ? debug_lockdep_rcu_enabled+0x1a/0x20 [ 3796.793143] [<c0649112>] ? __fget_light+0x62/0x90 [ 3796.793143] [<c063d798>] SyS_ioctl+0x68/0x80 [ 3796.793143] [<c0403ba5>] do_fast_syscall_32+0xa5/0x230 [ 3796.793143] [<c0c22833>] sysenter_past_esp+0x4c/0x7f [ 3796.793143] Code: 00 8d 82 00 00 00 40 c1 e8 0c 8d 0c 80 a1 44 56 a8 c1 8d 04 c8 8b 08 80 e5 40 74 15 90 8d 74 26 00 ba c8 98 1d f8 e8 56 d3 42 c8 <0f> 0b 8d 74 26 00 8b 48 14 83 e1 01 75 e8 81 c2 00 10 00 40 66 [ 3796.793143] EIP: [<f81b196a>] drm_pci_alloc+0xca/0x1c0 [drm] SS:ESP 0068:ee207b58 [ 3797.330991] ---[ end trace 615a977558502e55 ]---
Felix Miata wrote:
All these i686 lockups and failures bugs and threads are getting me confused. Latest iteration is kernel boots, I login, startx, and machine's own UI locks up. This is from remote login (where reboot and systemctl reboot commands both fail to restart the machine):
googling gets a hit in bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1303860
...
[ f87c7626 f30fd800 3796.793143] Call Trace: [ 3796.793143] [<f8784857>] i915_gem_object_attach_phys+0xf7/0x1a0 [i915] [ 3796.793143] [<f87d02d3>] intel_prepare_plane_fb+0x193/0x310 [i915] [ 3796.793143] [<f87c7626>] ? intel_atomic_commit+0x96/0x1980 [i915] [ 3796.793143] [<f818a545>] drm_atomic_helper_prepare_planes+0x45/0xb0
...
Rex Dieter composed on 2016-05-03 21:25 (UTC-0500):
Felix Miata wrote:
All these i686 lockups and failures bugs and threads are getting me confused. Latest iteration is kernel boots, I login, startx, and machine's own UI locks up. This is from remote login (where reboot and systemctl reboot commands both fail to restart the machine):
googling gets a hit in bugzilla:
It's certainly not getting much better WRT $SUBJECT, and that bug is tied to Intel video. I have no panel on host big41 in F23, f24 or Rawhide, and with GT218 video and modeset(0) driver. I'm not sure if I've seen a panel in any of my 30+ Fedora installations in the past month or two, and few if any plasma5 anywhere since sometime last year.
:-(
This is from F25 with 4.7.0-0.rc0.git5.1, which has a desktop context menu, but no panel, and no .xsession-errors. [ 1580.164325] show_signal_msg: 9 callbacks suppressed [ 1580.164332] QXcbEventReader[1284]: segfault at 7f9dd944c0c9 ip 00007f9dd944c0c9 sp 00007f9dd67acd20 error 14 in LC_COLLATE[7f9dd9dee000+130000]
Felix Miata wrote:
Rex Dieter composed on 2016-04-29 05:36 (UTC-0500):
Adam Williamson wrote:
On Thu, 2016-04-28 at 15:24 -0400, Felix Miata wrote:
Same problem on i865G host gx27c in freshly updated F24.
BTW, the restore previous session setting is not producing a restoring of the Konsole session left open on session close, only an empty desktop.
Konsole is restored on restart on gx27c, after having gotten it open via Alt-F2.
I filed a bug:
if there was already one, though, please close as a dupe (and tag the original with 'openqa'). Thanks!
The symptoms are similar to when plasmashell deadlocks, so getting a backtrace from the presumably-deadlocked plasmashell process may be helpful in diagnosing what's going on.
In order to preserve limited / filesystem space, I tried minimally following the instructions at https://fedoraproject.org/wiki/StackTraces by installing only gdb and plasma-workspace-debuginfo, but the instructions don't say how to find the coredump.
There is no coredump (nothing is crashed), but attach directly to the currently-running, but deadlocked, plasmashell process
-
Adam Williamson -
Felix Miata -
Mark Haney -
Patrick Boutilier -
Rex Dieter