Hi, guys, I'm sorry, but wyland is a disaster for me. I do work on lots of different software platforms, and things are just not working well. They kind-of-work, which is the really worst condition one can have. My new video board won't work with wyland, my pixycam software won't work with wyland, some other graphics have changed colors, or don't fully resolve with wyland, and finding compatible third party products which was tough enough on linux to begin with is now virtually impossible. The web compatible products work, like MPLABX from microchip, but occasionally crash. Gscheme crashes randomly, and there are others I haven't tried recently, but which I expect to have issues supporting.
Whatever the impetus was to change, it must have been driven by somebody that doesn't really use the system. I have tried starting as an Xorg login, but somehow that seems less than operating for similar reasons, all surrounding graphics I suspect. So whether it is wyland or the new graphics driver, kind-of-working is not a good deal. Yes, I can change distributions, and if that is the only solution, I will, but isn't that contradictory to the idea of becoming the OS of choice?
I expected that all these nagging issues would be worked out by now. But there is no sign of improvement. Worse I am not getting my stuff done. Granted I am just a hobbyiest, but doesn't this also affect your more professional users?
Regards, Les H
On 20/01/18 19:14, Howard Howell wrote:
Hi, guys, I'm sorry, but wyland is a disaster for me. I do work on lots of different software platforms, and things are just not working well. They kind-of-work, which is the really worst condition one can have.
For me, this looks more like a support issue and as such doesn't not belong to this development list. I suggest that you:
- Reach out for help in a support channel e. g. Ask Fedora [1] - When you do, divide you problems into small, well-defined ones, giving folks a chance to help - Learn to spell Wayland ;)
Cheers!
--alec
On 20 Jan 2018, at 8:24 PM, Alec Leamas leamas.alec@gmail.com wrote:
I'm sorry, but wyland is a disaster for me. I do work on lots of different software platforms, and things are just not working well. They kind-of-work, which is the really worst condition one can have.
For me, this looks more like a support issue and as such doesn't not belong to this development list. I suggest that you:
I disagree, this looks like an overarching observation of interest to the development community. Anyone else seen this as a pattern?
Regards, Graham —
On 21/01/18 12:06, Graham Leggett wrote:
On 20 Jan 2018, at 8:24 PM, Alec Leamas leamas.alec@gmail.com wrote:
I'm sorry, but wyland is a disaster for me. I do work on lots of different software platforms, and things are just not working well. They kind-of-work, which is the really worst condition one can have.
For me, this looks more like a support issue and as such doesn't not belong to this development list. I suggest that you:
I disagree, this looks like an overarching observation of interest to the development community.
Not really. It's a grab bag of different things that may or not be related to Wayland.
As Alec said, it's a support issue for now where each point needs to be investigated to determine a cause.
Anyone else seen this as a pattern?
No.
Tom
On 01/21/2018 07:23 AM, Tom Hughes wrote:
Not really. It's a grab bag of different things that may or not be related to Wayland.
I think this problem is compounded by the fact that Wayland and several other system features such as Gnome session setup are very integrated, and it's hard to debug them.
For instance, I observed a reliable desktop session crash on exiting Pan newsreader. I don't know how to debug it because it crashes the session and I get logged out.
This is a pretty serious issue in my opinion, because if I can crash the entire desktop session then it's not unreasonable to expect fuzzing issues with serious security implications (e.g. snooping on your desktop session from code running in the browser).
I tried to run strace on the pan process and save results to the disk file, but it was inconclusive; whatever kills the login session seems to happen outside of the pan process.
Can anyone suggest ways of debugging this?
On Wed, Jan 24, 2018 at 1:37 PM, Przemek Klosowski przemek.klosowski@nist.gov wrote:
Can anyone suggest ways of debugging this?
Run coredumpctl to see what processes crashed. There should be at least a gnome-shell crash, maybe also a gnome-session crash, maybe also an XWayland crash. Usually only the gnome-shell and gnome-session crashes are interesting. Use 'coredumpctl gdb' to get backtraces for each crash in gdb. Be sure to install the debuginfo via the dnf command that gdb will suggest and then restart gdb each time, to get a high-quality backtrace.
Once you have a backtrace, you have all you need for a quality crash report. Skip Red Hat Bugzilla and go straight to upstream for best results. The gnome-shell crash should be reported at https://gitlab.gnome.org/GNOME/gnome-shell/issues (yes, it's a new issue tracker, I'm afraid you just missed being first!). If there's also a gnome-session crash, that should be reported at https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-session.
Hope that helps,
Michael
On Wed, 24 Jan 2018 14:37:30 -0500 Przemek Klosowski przemek.klosowski@nist.gov wrote:
For instance, I observed a reliable desktop session crash on exiting Pan newsreader. I don't know how to debug it because it crashes the session and I get logged out.
I think this is because the C++ used in Pan is incompatible with current versions of g++ being used. More specifically, when I saw this issue in F25, I was able to end it by compiling the src.rpm with optimization set to O0. This type of thing also occurred in firefox when the latest C++ was released, as it made some things commonly used in earlier versions errors.
On the other hand, it could be completely unrelated to your problem.
On 24/01/18 15:06 -0700, stan wrote:
On Wed, 24 Jan 2018 14:37:30 -0500 Przemek Klosowski przemek.klosowski@nist.gov wrote:
For instance, I observed a reliable desktop session crash on exiting Pan newsreader. I don't know how to debug it because it crashes the session and I get logged out.
I think this is because the C++ used in Pan is incompatible with current versions of g++ being used.
That's a funny way to say the package is buggy.
More specifically, when I saw this issue in F25, I was able to end it by compiling the src.rpm with optimization set to O0. This type of thing also occurred in firefox when the latest C++ was released, as it made some things commonly used in earlier versions errors.
Yes, firefox code was buggy, it plays lots of nasty undefined tricks.
"It worked OK until now" doesn't mean something isn't a bug if you're not following the rules of the language.
On 21/01/18 13:06, Graham Leggett wrote:
On 20 Jan 2018, at 8:24 PM, Alec Leamas leamas.alec@gmail.com wrote:
I'm sorry, but wyland is a disaster for me. I do work on lots of different software platforms, and things are just not working well. They kind-of-work, which is the really worst condition one can have.
For me, this looks more like a support issue and as such doesn't not belong to this development list. I suggest that you:
I disagree, this looks like an overarching observation of interest to the development community. Anyone else seen this as a pattern?
I started to see it when I realized that most of the crashes that where reported to me by users (forums, chats, face-to-face) were related (directly or indirectly) to Wayland: every time that I heard someone with an application that won't start or crashes every time after a few clicks, I suggest to report the bug (and a strange Gnome Abrt pops-up with two or three buttons labeled "Report" "Report" "Report") and switch temporary to Xorg, which fixes the problem most of the time.
When users see that a Xorg session works as expected and they gain nothing valuable to them from using Wayland, they stick with Xorg. They realize that their crashes are not related to bugs in their code (many of them don't, so they blame Audacity, Pitivi, Steam, etc.), but to Wayland or some other related component, they start to avoid the Gnome/Wayland session and it is reasonable to receive mails like the one from Howard Howell (the user who started this discussion).
Note: some users have a password-less account, and it is not possible to set an alternative session from GDM if you have no password (the gear icon appears only when GDM prompts for the password), so the user should set a password first, log out, select Gnome with Xorg, log in, remove the password (this is not related with Wayland, it is just a usability issue with GDM and/or with the Gnome user settings control panel).
Cheers, Frafra
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Folks, please move this discussion to users@lists.fedoraproject.org. - -- - -Igor Gnatenko
On Sun, 2018-01-21 at 15:25 +0100, Igor Gnatenko wrote:
Folks, please move this discussion to users@lists.fedoraproject.org. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
HI, Igor, I posted here on purpose. Users cannot change the direction of Linux, only you guys, the developers, have that capability. I like the direction the discussion has taken. I want the group to think responsibily about the users. Not just the technology, because technology that is not useful on a widely distributed operating system is not beneficial to anyone.
As to my misspelling of Wayland, that is ignorance on my part. I regret that, but as they say, it's on the internet, and immortal.
Regards, Les H
On 21 January 2018 at 14:06, Howard Howell hlhowell@pacbell.net wrote:
On Sun, 2018-01-21 at 15:25 +0100, Igor Gnatenko wrote:
Folks, please move this discussion to users@lists.fedoraproject.org. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
HI, Igor, I posted here on purpose. Users cannot change the direction of Linux, only you guys, the developers, have that capability. I like the direction the discussion has taken. I want the group to think responsibily about the users. Not just the technology, because technology that is not useful on a widely distributed operating system is not beneficial to anyone.
Posting a diatribe to the devel list usually has the opposite effect than getting people to think about things.
First off this list does not develop Wayland. It does not develop GNOME or KDE. It may incorporate those into the finished OS but it is too late in the process to change the direction.
Second, most of the people on this list have no say in what is going on there and have no way to 'change direction'. The people who agree with you on this aren't doing anything to change direction.. saying "I agree" doesn't mean that anyone is fixing anything or finding why something is crashing, etc. It doesn't mean that any developer who actually works on the stuff is going to see your emails.
Third, if you actually wanted to change people's opinions you would not have come into this list like a drunk with a broken bottle. Calling a project a disaster, mis-spelling it constantly like it was a slur, and not actually putting any details like bug reports screams "I am just here to abuse you for your work." It says to the people who might actually have the power to fix to ignore it and send the thread to spam. Yes you have people saying "I agree" but they aren't actually moving the conversation forward... they are just echoing empty affirmation. It doesn't mean anyone is going to do anything.. and thinking that it does is foolish.
As to my misspelling of Wayland, that is ignorance on my part.I regret that, but as they say, it's on the internet, and immortal.
Thank you for the apology. I would say to start this over again do the following:
1. Research your actual problems. Get bug reports. If you are having problems figuring them out ask on the appropriate list "Hey I am having a problem using Wayland on my <fill in detailed hardware description>. It is crashing when I do <detailed application>. I don't know how to debug this better." 2. Don't post an email with a drama queen title calling something a disaster or "end of the world". Be clear and concise.
Regards, Les H _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
----- Original Message -----
From: "Stephen John Smoogen" smooge@gmail.com To: hlhowell@pacbell.net, "Development discussions related to Fedora" devel@lists.fedoraproject.org Cc: "Francesco Frassinelli" fraph24@gmail.com Sent: Sunday, January 21, 2018 8:42:46 PM Subject: Re: Wyland is a disaster
On 21 January 2018 at 14:06, Howard Howell hlhowell@pacbell.net wrote:
On Sun, 2018-01-21 at 15:25 +0100, Igor Gnatenko wrote:
Folks, please move this discussion to users@lists.fedoraproject.org. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
HI, Igor, I posted here on purpose. Users cannot change the direction of Linux, only you guys, the developers, have that capability. I like the direction the discussion has taken. I want the group to think responsibily about the users. Not just the technology, because technology that is not useful on a widely distributed operating system is not beneficial to anyone.
Posting a diatribe to the devel list usually has the opposite effect than getting people to think about things.
First off this list does not develop Wayland. It does not develop GNOME or KDE. It may incorporate those into the finished OS but it is too late in the process to change the direction.
Second, most of the people on this list have no say in what is going on there and have no way to 'change direction'. The people who agree with you on this aren't doing anything to change direction.. saying "I agree" doesn't mean that anyone is fixing anything or finding why something is crashing, etc. It doesn't mean that any developer who actually works on the stuff is going to see your emails.
Third, if you actually wanted to change people's opinions you would not have come into this list like a drunk with a broken bottle. Calling a project a disaster, mis-spelling it constantly like it was a slur, and not actually putting any details like bug reports screams "I am just here to abuse you for your work." It says to the people who might actually have the power to fix to ignore it and send the thread to spam. Yes you have people saying "I agree" but they aren't actually moving the conversation forward... they are just echoing empty affirmation. It doesn't mean anyone is going to do anything.. and thinking that it does is foolish.
As to my misspelling of Wayland, that is ignorance on my part.I regret that, but as they say, it's on the internet, and immortal.
Thank you for the apology. I would say to start this over again do the following:
- Research your actual problems. Get bug reports. If you are having
problems figuring them out ask on the appropriate list "Hey I am having a problem using Wayland on my <fill in detailed hardware description>. It is crashing when I do <detailed application>. I don't know how to debug this better." 2. Don't post an email with a drama queen title calling something a disaster or "end of the world". Be clear and concise.
Regards, Les H _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
-- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
While you are correct with your observations I'd like to point out that OP might just be frustrated with the unusability of wayland and that's his way of communicating it.
And i'm saying that because wayland has been for me also an absolutely frustrating experience (on F27 that is). F26 was fine on wayland and xorg, however currently on F27 with the same setup (T450s with docking station and two monitors) wayland is unusable due to crashes and xorg just makes gnome-shell crash less. And at the same time I have tried to debug the issues, filed reports, compiled rpm's with various fixes, but it just seems that gnome-shell keeps crashing for a different reason each time.
Again that was not the case with F26, so I keep wondering what went wrong with the latest gnome (or wayland), on F27.
Hi there, I am sad to hear that people are having issues when using Wayland (and even the X.org session). Be aware though that we have devs dedicated at RH to look at Fedora Wayland bugs, so if you file bugs we will try our best to look at them and figure out what is happening. It obviously works well for many of us, including the devs themselves, so there must be some specific hardware and or software combinations triggering these problems. So please file bugs against Wayland in the Fedora bugzilla and we will try our best to take a look.
Sincerely, Christian Schaller
On Mon, Jan 22, 2018 at 5:43 AM, Charalampos Stratakis cstratak@redhat.com wrote:
----- Original Message -----
From: "Stephen John Smoogen" smooge@gmail.com To: hlhowell@pacbell.net, "Development discussions related to Fedora" <
devel@lists.fedoraproject.org>
Cc: "Francesco Frassinelli" fraph24@gmail.com Sent: Sunday, January 21, 2018 8:42:46 PM Subject: Re: Wyland is a disaster
On 21 January 2018 at 14:06, Howard Howell hlhowell@pacbell.net wrote:
On Sun, 2018-01-21 at 15:25 +0100, Igor Gnatenko wrote:
Folks, please move this discussion to users@lists.fedoraproject.org. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
HI, Igor, I posted here on purpose. Users cannot change the direction of Linux, only you guys, the developers, have that capability. I like the direction the discussion has taken. I want the group to think responsibily about the users. Not just the technology, because technology that is not useful on a widely distributed operating system is not beneficial to anyone.
Posting a diatribe to the devel list usually has the opposite effect than getting people to think about things.
First off this list does not develop Wayland. It does not develop GNOME or KDE. It may incorporate those into the finished OS but it is too late in the process to change the direction.
Second, most of the people on this list have no say in what is going on there and have no way to 'change direction'. The people who agree with you on this aren't doing anything to change direction.. saying "I agree" doesn't mean that anyone is fixing anything or finding why something is crashing, etc. It doesn't mean that any developer who actually works on the stuff is going to see your emails.
Third, if you actually wanted to change people's opinions you would not have come into this list like a drunk with a broken bottle. Calling a project a disaster, mis-spelling it constantly like it was a slur, and not actually putting any details like bug reports screams "I am just here to abuse you for your work." It says to the people who might actually have the power to fix to ignore it and send the thread to spam. Yes you have people saying "I agree" but they aren't actually moving the conversation forward... they are just echoing empty affirmation. It doesn't mean anyone is going to do anything.. and thinking that it does is foolish.
As to my misspelling of Wayland, that is ignorance on my part.I regret that, but as they say, it's on the internet, and immortal.
Thank you for the apology. I would say to start this over again do the following:
- Research your actual problems. Get bug reports. If you are having
problems figuring them out ask on the appropriate list "Hey I am having a problem using Wayland on my <fill in detailed hardware description>. It is crashing when I do <detailed application>. I don't know how to debug this better." 2. Don't post an email with a drama queen title calling something a disaster or "end of the world". Be clear and concise.
Regards, Les H _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
-- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
While you are correct with your observations I'd like to point out that OP might just be frustrated with the unusability of wayland and that's his way of communicating it.
And i'm saying that because wayland has been for me also an absolutely frustrating experience (on F27 that is). F26 was fine on wayland and xorg, however currently on F27 with the same setup (T450s with docking station and two monitors) wayland is unusable due to crashes and xorg just makes gnome-shell crash less. And at the same time I have tried to debug the issues, filed reports, compiled rpm's with various fixes, but it just seems that gnome-shell keeps crashing for a different reason each time.
Again that was not the case with F26, so I keep wondering what went wrong with the latest gnome (or wayland), on F27.
-- Regards,
Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Sorry for responding to myself here, but I thought it could also be worthwhile to mention that one of our primary tools for identifying problems is the Fedora ABRT server. Looking at the current stats it looks to me like F27 is actually doing better than F26 used to in terms of minimizing crashers: https://goo.gl/babuJx
There is always a chance ABRT is not catching the issues of course for some reason, but since the initial email did claim developers don't care about making sure things works well I thought it would be worthwhile pointing out some of the tools we use to try to ensure that things work well.
Christian
On Mon, Jan 22, 2018 at 6:29 AM, Christian Fredrik Schaller < cschalle@redhat.com> wrote:
Hi there, I am sad to hear that people are having issues when using Wayland (and even the X.org session). Be aware though that we have devs dedicated at RH to look at Fedora Wayland bugs, so if you file bugs we will try our best to look at them and figure out what is happening. It obviously works well for many of us, including the devs themselves, so there must be some specific hardware and or software combinations triggering these problems. So please file bugs against Wayland in the Fedora bugzilla and we will try our best to take a look.
Sincerely, Christian Schaller
On Mon, Jan 22, 2018 at 5:43 AM, Charalampos Stratakis < cstratak@redhat.com> wrote:
----- Original Message -----
From: "Stephen John Smoogen" smooge@gmail.com To: hlhowell@pacbell.net, "Development discussions related to Fedora" <
devel@lists.fedoraproject.org>
Cc: "Francesco Frassinelli" fraph24@gmail.com Sent: Sunday, January 21, 2018 8:42:46 PM Subject: Re: Wyland is a disaster
On 21 January 2018 at 14:06, Howard Howell hlhowell@pacbell.net
wrote:
On Sun, 2018-01-21 at 15:25 +0100, Igor Gnatenko wrote:
Folks, please move this discussion to users@lists.fedoraproject.org. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
HI, Igor, I posted here on purpose. Users cannot change the direction
of
Linux, only you guys, the developers, have that capability. I like
the
direction the discussion has taken. I want the group to think responsibily about the users. Not just the technology, because technology that is not useful on a widely distributed operating system is not beneficial to anyone.
Posting a diatribe to the devel list usually has the opposite effect than getting people to think about things.
First off this list does not develop Wayland. It does not develop GNOME or KDE. It may incorporate those into the finished OS but it is too late in the process to change the direction.
Second, most of the people on this list have no say in what is going on there and have no way to 'change direction'. The people who agree with you on this aren't doing anything to change direction.. saying "I agree" doesn't mean that anyone is fixing anything or finding why something is crashing, etc. It doesn't mean that any developer who actually works on the stuff is going to see your emails.
Third, if you actually wanted to change people's opinions you would not have come into this list like a drunk with a broken bottle. Calling a project a disaster, mis-spelling it constantly like it was a slur, and not actually putting any details like bug reports screams "I am just here to abuse you for your work." It says to the people who might actually have the power to fix to ignore it and send the thread to spam. Yes you have people saying "I agree" but they aren't actually moving the conversation forward... they are just echoing empty affirmation. It doesn't mean anyone is going to do anything.. and thinking that it does is foolish.
As to my misspelling of Wayland, that is ignorance on my part.I regret that, but as they say, it's on the internet, and immortal.
Thank you for the apology. I would say to start this over again do the following:
- Research your actual problems. Get bug reports. If you are having
problems figuring them out ask on the appropriate list "Hey I am having a problem using Wayland on my <fill in detailed hardware description>. It is crashing when I do <detailed application>. I don't know how to debug this better." 2. Don't post an email with a drama queen title calling something a disaster or "end of the world". Be clear and concise.
Regards, Les H _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
-- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
While you are correct with your observations I'd like to point out that OP might just be frustrated with the unusability of wayland and that's his way of communicating it.
And i'm saying that because wayland has been for me also an absolutely frustrating experience (on F27 that is). F26 was fine on wayland and xorg, however currently on F27 with the same setup (T450s with docking station and two monitors) wayland is unusable due to crashes and xorg just makes gnome-shell crash less. And at the same time I have tried to debug the issues, filed reports, compiled rpm's with various fixes, but it just seems that gnome-shell keeps crashing for a different reason each time.
Again that was not the case with F26, so I keep wondering what went wrong with the latest gnome (or wayland), on F27.
-- Regards,
Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Mon, 2018-01-22 at 07:16 -0500, Christian Fredrik Schaller wrote:
Sorry for responding to myself here, but I thought it could also be worthwhile to mention that one of our primary tools for identifying problems is the Fedora ABRT server. Looking at the current stats it looks to me like F27 is actually doing better than F26 used to in terms of minimizing crashers: https://goo.gl/babuJx
There is always a chance ABRT is not catching the issues of course for some reason,
Well, see my mails from last month or so to desktop@ . There's several problems with how abrt interacts with GNOME and Wayland; I'm not sure to what extent these distort the figures.
First problem: abrt considers *lots* of actually-unrelated crashes to be duplicates, because their tracebacks look similar - this happens because glib has a special 'logging' function which actually means (more or less) 'die intentionally, with this log message'. abrt tends to interpret many bugs that crash along that path as dupes of each other, even if the actual cause of the crash - whatever triggers that special log message call - is different in each case. I've filed a couple of variants of this at: https://bugzilla.redhat.com/show_bug.cgi?id=1509086
Second problem: I *think* there's a similar issue with the recently- introduced `dump_gjs_stack_on_signal_handler` path; I've found at least some cases of apparently-unrelated bugs being marked as dupes due to that path. Details: https://github.com/abrt/satyr/issues/272
Third problem: abrt doesn't do a very good job of reporting any crash that's caused by Xwayland dying. All you get is a backtrace that basically tells you "Xwayland crashed", but no useful information about why. Sometimes the system log extract that abrt captures happens to shed some light on the reason, but sometimes it doesn't. Details: https://github.com/abrt/satyr/issues/271
I did some cleanup on false dupes and things caused by these problems, but it's necessarily incomplete, and I know more dupes have been filed since I did the cleanup...
Hi
On Mon, Jan 22, 2018 at 4:54 PM, Adam Williamson <adamwill@fedoraproject.org
wrote:
On Mon, 2018-01-22 at 07:16 -0500, Christian Fredrik Schaller wrote:
Sorry for responding to myself here, but I thought it could also be worthwhile to mention that one of our primary tools for identifying problems is the Fedora ABRT server. Looking at the current stats it looks to me like F27 is actually doing better than F26 used to in terms of minimizing crashers: https://goo.gl/babuJx
There is always a chance ABRT is not catching the issues of course for
some
reason,
Well, see my mails from last month or so to desktop@ . There's several problems with how abrt interacts with GNOME and Wayland; I'm not sure to what extent these distort the figures.
First problem: abrt considers *lots* of actually-unrelated crashes to be duplicates, because their tracebacks look similar - this happens because glib has a special 'logging' function which actually means (more or less) 'die intentionally, with this log message'. abrt tends to interpret many bugs that crash along that path as dupes of each other, even if the actual cause of the crash - whatever triggers that special log message call - is different in each case. I've filed a couple of variants of this at: https://bugzilla.redhat.com/show_bug.cgi?id=1509086
Second problem: I *think* there's a similar issue with the recently- introduced `dump_gjs_stack_on_signal_handler` path; I've found at least some cases of apparently-unrelated bugs being marked as dupes due to that path. Details: https://github.com/abrt/satyr/issues/272
Third problem: abrt doesn't do a very good job of reporting any crash that's caused by Xwayland dying. All you get is a backtrace that basically tells you "Xwayland crashed", but no useful information about why. Sometimes the system log extract that abrt captures happens to shed some light on the reason, but sometimes it doesn't. Details: https://github.com/abrt/satyr/issues/271
I did some cleanup on false dupes and things caused by these problems, but it's necessarily incomplete, and I know more dupes have been filed since I did the cleanup...
Regarding the characterization of issues with Wayland, there is a bit of history behind all this, and are a couple things to consider as well.
With GNOME on Wayland, gnome-shell/mutter is the display server and gnome-shell/mutter still depends on Xwayland to run [1] and cannot survive a crash in Xwayland.
Xwayland is an X server for the X11 clients but a Wayland client as well, so if gnome-shell/mutter crashes, Xwayland will lose its connection to the Wayland compositor and therefore dies as well.
So both components (gnome-shell/mutter and Xwayland) are tightly coupled and cannot survive one each other (in GNOME).
That alone makes automatically (or even manually) root causing an issue afterwards a bit of a challenge sometimes, one has first to determine which of the two components has died first and taken the other with it.
To make things slightly more challenging, Xwayland would not generate a core file on a crash, just a self-generated backtrace that could be found in journalctl, so in some case, it would be almost impossible to tell why the Wayland session crashed as no core file for Xwayland would be available (and the self-generated backtrace is rarely of much help, sadly).
So gnome-shell/mutter added “-core” to the Wayland command line (Xwayland being started automatically by gnome-shell/mutter) so that we could capture a core file every time Xwayland would crash [2].
Unfortunately, using “-core” instructs Xwayland to generate a core file each time a fatal error occurs, and losing the connection to the Wayland compositor is a fatal error for Xwayland, so now each time gnome-shell/mutter crashes, we also get a core file for Xwayland and get reports about a bug in Xwayland whereas the issue come from gnome-shell/mutter. That alone generates a lot of false positive for Xwayland, and a lot of duplicates (the backtrace usually contains “xwl_read_events()”)
The way to solve that problem is to change Xwayland to not call FatalError() when the Wayland compositor dies so that no core is generated in this case, a patch for this has already landed in the xserver master branch upstream [3].
With this, we should get a core file for “real” crashes but not when Xwayland is aborting because the Wayland compositor (gnome-shell/mutter) has crashed, hopefully that will help with a better characterization of Wayland issues in the future.
HTH,
Cheers, Olivier
[1] https://bugzilla.gnome.org/show_bug.cgi?id=759538 [2] https://bugzilla.gnome.org/show_bug.cgi?id=789086 [3] https://cgit.freedesktop.org/xorg/xserver/commit/?id= fe46cbea0f19959d469ca4d1f09be379dc7b1e45
On Mon, Jan 22, 2018 at 4:29 AM, Christian Fredrik Schaller cschalle@redhat.com wrote:
I am sad to hear that people are having issues when using Wayland (and even the X.org session). Be aware though that we have devs dedicated at RH to look at Fedora Wayland bugs, so if you file bugs we will try our best to look at them and figure out what is happening. It obviously works well for many of us, including the devs themselves, so there must be some specific hardware and or software combinations triggering these problems. So please file bugs against Wayland in the Fedora bugzilla and we will try our best to take a look.
Thanks, Christian. It's good to know that people are working on these issues.
One configuration that appears to be particularly unstable is a dual-monitor setup with nouveau. I experience frequent system hangs with that setup, and don't seem to be alone; e.g., https://bugzilla.redhat.com/show_bug.cgi?id=1491565. (Note that I do not have a HiDPI monitor, but I also don't see all of the issues the reporter of that bug noted.) I'm going to try using X sessions this week to see if that helps at all. If not, they are probably nouveau bugs unrelated to Wayland.
Regards,
On 22/01/18 15:26, Jerry James wrote:
On Mon, Jan 22, 2018 at 4:29 AM, Christian Fredrik Schaller cschalle@redhat.com wrote:
I am sad to hear that people are having issues when using Wayland (and even the X.org session). Be aware though that we have devs dedicated at RH to look at Fedora Wayland bugs, so if you file bugs we will try our best to look at them and figure out what is happening. It obviously works well for many of us, including the devs themselves, so there must be some specific hardware and or software combinations triggering these problems. So please file bugs against Wayland in the Fedora bugzilla and we will try our best to take a look.
Thanks, Christian. It's good to know that people are working on these issues.
One configuration that appears to be particularly unstable is a dual-monitor setup with nouveau. I experience frequent system hangs with that setup, and don't seem to be alone; e.g., https://bugzilla.redhat.com/show_bug.cgi?id=1491565. (Note that I do not have a HiDPI monitor, but I also don't see all of the issues the reporter of that bug noted.) I'm going to try using X sessions this week to see if that helps at all. If not, they are probably nouveau bugs unrelated to Wayland.
Does wayland actually support that?
I have a triple monitor setup with nouveau on one machine and that has always fallen back to X so I just assumed wayland didn't support that yet.
My machines which are using wayland, which admittedly aren't using nvidia graphics at all, seem perfectly fine with it.
Tom
On 22/01/18 15:34, Tom Hughes wrote:
On 22/01/18 15:26, Jerry James wrote:
One configuration that appears to be particularly unstable is a dual-monitor setup with nouveau. I experience frequent system hangs with that setup, and don't seem to be alone; e.g., https://bugzilla.redhat.com/show_bug.cgi?id=1491565.%C2%A0 (Note that I do not have a HiDPI monitor, but I also don't see all of the issues the reporter of that bug noted.) I'm going to try using X sessions this week to see if that helps at all. If not, they are probably nouveau bugs unrelated to Wayland.
Does wayland actually support that?
I have a triple monitor setup with nouveau on one machine and that has always fallen back to X so I just assumed wayland didn't support that yet.
Actually thinking about it I think it's the fact that two of the monitors have a rotation applied that blocks wayland.
Tom
On Mon, 2018-01-22 at 15:39 +0000, Tom Hughes wrote:
On 22/01/18 15:34, Tom Hughes wrote:
On 22/01/18 15:26, Jerry James wrote:
One configuration that appears to be particularly unstable is a dual-monitor setup with nouveau. I experience frequent system hangs with that setup, and don't seem to be alone; e.g., https://bugzilla.redhat.com/show_bug.cgi?id=1491565. (Note that I do not have a HiDPI monitor, but I also don't see all of the issues the reporter of that bug noted.) I'm going to try using X sessions this week to see if that helps at all. If not, they are probably nouveau bugs unrelated to Wayland.
Does wayland actually support that?
I have a triple monitor setup with nouveau on one machine and that has always fallen back to X so I just assumed wayland didn't support that yet.
Actually thinking about it I think it's the fact that two of the monitors have a rotation applied that blocks wayland.
I have a dual monitor setup with both monitors rotated, using an NVIDIA adapter (9600 GT). Works fine, uses Wayland. Again, you need to be *very specific* about graphics issues. They are very often very specific to the exact hardware in use - down to the model of the graphics card and which specific outputs are used.
On 22/01/18 15:58, Adam Williamson wrote:
I have a dual monitor setup with both monitors rotated, using an NVIDIA adapter (9600 GT). Works fine, uses Wayland. Again, you need to be *very specific* about graphics issues. They are very often very specific to the exact hardware in use - down to the model of the graphics card and which specific outputs are used.
1 x NVIDIA Corporation G84 [GeForce 8600 GT]
with DVI-I-1 connected to 2560x1600 panel and DVI-I-2 connected to 1600x1200 panel rotated right
1 x NVIDIA Corporation GT218 [GeForce 210]
with DVI-I-1-3 connected to 1600x1200 panel rotated right
I can't see any obvious indication in the logs of why it fell back but if it's not rotation maybe it's having multiple cards?
Tom
On Mon, 2018-01-22 at 19:53 +0000, Tom Hughes wrote:
On 22/01/18 15:58, Adam Williamson wrote:
I have a dual monitor setup with both monitors rotated, using an NVIDIA adapter (9600 GT). Works fine, uses Wayland. Again, you need to be *very specific* about graphics issues. They are very often very specific to the exact hardware in use - down to the model of the graphics card and which specific outputs are used.
1 x NVIDIA Corporation G84 [GeForce 8600 GT]
with DVI-I-1 connected to 2560x1600 panel and DVI-I-2 connected to 1600x1200 panel rotated right
1 x NVIDIA Corporation GT218 [GeForce 210]
with DVI-I-1-3 connected to 1600x1200 panel rotated right
I can't see any obvious indication in the logs of why it fell back but if it's not rotation maybe it's having multiple cards?
Yeah, I'd bet that's it.
On Mon, 2018-01-22 at 19:53 +0000, Tom Hughes wrote:
On 22/01/18 15:58, Adam Williamson wrote:
I have a dual monitor setup with both monitors rotated, using an NVIDIA adapter (9600 GT). Works fine, uses Wayland. Again, you need to be *very specific* about graphics issues. They are very often very specific to the exact hardware in use - down to the model of the graphics card and which specific outputs are used.
1 x NVIDIA Corporation G84 [GeForce 8600 GT]
with DVI-I-1 connected to 2560x1600 panel and DVI-I-2 connected to 1600x1200 panel rotated right
1 x NVIDIA Corporation GT218 [GeForce 210]
with DVI-I-1-3 connected to 1600x1200 panel rotated right
I can't see any obvious indication in the logs of why it fell back but if it's not rotation maybe it's having multiple cards?
Tom
-- Tom Hughes (tom@compton.nu) http://compton.nu/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
My setup is as follows: AMD Fx(tm)-8300 eight-core processor x8 64-bit AMD Oland graphics Gnome 3.24.2 976GB disk Dual monitors ViewSonic 23" Primary Samsung Electric Company 23" Fedora 26 Wayland (normal login, but Xorg login has similar issues) Programs experiencing issues: PixyMon after rebuild crashes Gscheme simply goes away System updated at each prompt, including today. Running Gschem by invoking it from a terminal provides no unusual information. Tried on both monitors. LibreOffice Calc has died once or twice, not sure, can't repeat that. Occasionally rapid mouse movement to the Activities bar causes logout. Can't get repeatable to determine if any application causes it. Frequently my use has up to 20 tabs open in firefox, evolution up (like now), and one or two other applications open simultaneously, like now I have settings showing the display info.
Checking jounalctl and dmesg has not revealed anything pertinent. Can you gentlefolk suggest anyplace else to look? Or is there any more information you need?
I thought there was a tool to list installed boards, but can't find it. Any thoughts there, other than opening up the system and getting the label information?
Regards, Les H
On Tue, 2018-01-23 at 12:35 -0800, Samuel Sieb wrote:
On 01/23/2018 12:22 PM, Howard Howell wrote:
I thought there was a tool to list installed boards, but can't find it. Any thoughts there, other than opening up the system and getting the label information?
lshw and/or lshw-gui _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Tried invoking the command. Got the prompt to install it, entered the su password, and got this response.
description: Computer width: 64 bits capabilities: smp vsyscall32 *-core description: Motherboard physical id: 0 *-memory description: System memory physical id: 0 size: 15GiB *-cpu product: AMD FX(tm)-8300 Eight-Core Processor vendor: Advanced Micro Devices [AMD] physical id: 1 bus info: cpu@0 size: 1450MHz capacity: 3300MHz width: 64 bits capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp x86-64 constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate retpoline retpoline_amd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold cpufreq *-pci:0 description: Host bridge product: RD9x0/RX980 Host Bridge vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 100 bus info: pci@0000:00:00.0 version: 02 width: 32 bits clock: 33MHz *-pci:0 description: PCI bridge product: RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GFX port 0) vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 2 bus info: pci@0000:00:02.0 version: 00 width: 32 bits clock: 33MHz capabilities: pci normal_decode bus_master cap_list configuration: driver=pcieport resources: irq:24 ioport:e000(size=4096) memory:fea00000- feafffff ioport:c0000000(size=268435456) *-display description: VGA compatible controller product: Oland [Radeon HD 8570 / R7 240/340 OEM] vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 0 bus info: pci@0000:01:00.0 version: 00 width: 64 bits clock: 33MHz capabilities: vga_controller bus_master cap_list rom configuration: driver=radeon latency=0 resources: irq:47 memory:c0000000-cfffffff memory:fea00000-fea3ffff ioport:e000(size=256) memory:c0000-dffff *-multimedia description: Audio device product: Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series] vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 0.1 bus info: pci@0000:01:00.1 version: 00 width: 64 bits clock: 33MHz capabilities: bus_master cap_list configuration: driver=snd_hda_intel latency=0 resources: irq:49 memory:fea60000-fea63fff *-pci:1 description: PCI bridge product: RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 0) vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 4 bus info: pci@0000:00:04.0 version: 00 width: 32 bits clock: 33MHz capabilities: pci normal_decode bus_master cap_list configuration: driver=pcieport resources: irq:24 ioport:d000(size=4096) memory:fe900000- fe9fffff ioport:d0000000(size=1048576) *-network description: Ethernet interface product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller vendor: Realtek Semiconductor Co., Ltd. physical id: 0 bus info: pci@0000:02:00.0 logical name: enp2s0 version: 0c serial: d8:50:e6:5b:cd:af size: 100Mbit/s capacity: 1Gbit/s width: 64 bits clock: 33MHz capabilities: bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl8168g- 2_0.0.1 02/06/13 ip=192.168.0.4 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s resources: irq:45 ioport:d000(size=256) memory:fe900000-fe900fff memory:d0000000-d0003fff *-pci:2 description: PCI bridge product: RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 1) vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 5 bus info: pci@0000:00:05.0 version: 00 width: 32 bits clock: 33MHz capabilities: pci normal_decode bus_master cap_list configuration: driver=pcieport resources: irq:24 memory:fe800000-fe8fffff *-usb description: USB controller product: ASM1042 SuperSpeed USB Host Controller vendor: ASMedia Technology Inc. physical id: 0 bus info: pci@0000:03:00.0 version: 00 width: 64 bits clock: 33MHz capabilities: xhci bus_master cap_list configuration: driver=xhci_hcd latency=0 resources: irq:26 memory:fe800000-fe807fff *-pci:3 description: PCI bridge product: RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 3) vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 7 bus info: pci@0000:00:07.0 version: 00 width: 32 bits clock: 33MHz capabilities: pci normal_decode bus_master cap_list configuration: driver=pcieport resources: irq:25 memory:fe700000-fe7fffff *-usb description: USB controller product: ASM1042 SuperSpeed USB Host Controller vendor: ASMedia Technology Inc. physical id: 0 bus info: pci@0000:04:00.0 version: 00 width: 64 bits clock: 33MHz capabilities: xhci bus_master cap_list configuration: driver=xhci_hcd latency=0 resources: irq:35 memory:fe700000-fe707fff *-storage description: SATA controller product: SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 11 bus info: pci@0000:00:11.0 version: 40 width: 32 bits clock: 66MHz capabilities: storage ahci_1.0 bus_master cap_list configuration: driver=ahci latency=32 resources: irq:19 ioport:f040(size=8) ioport:f030(size=4) ioport:f020(size=8) ioport:f010(size=4) ioport:f000(size=16) memory:feb0b000-feb0b3ff *-usb:0 description: USB controller product: SB7x0/SB8x0/SB9x0 USB OHCI0 Controller vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 12 bus info: pci@0000:00:12.0 version: 00 width: 32 bits clock: 66MHz capabilities: ohci bus_master configuration: driver=ohci-pci latency=32 resources: irq:18 memory:feb0a000-feb0afff *-usb:1 description: USB controller product: SB7x0/SB8x0/SB9x0 USB EHCI Controller vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 12.2 bus info: pci@0000:00:12.2 version: 00 width: 32 bits clock: 66MHz capabilities: ehci bus_master cap_list configuration: driver=ehci-pci latency=32 resources: irq:17 memory:feb09000-feb090ff *-usb:2 description: USB controller product: SB7x0/SB8x0/SB9x0 USB OHCI0 Controller vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 13 bus info: pci@0000:00:13.0 version: 00 width: 32 bits clock: 66MHz capabilities: ohci bus_master configuration: driver=ohci-pci latency=32 resources: irq:20 memory:feb08000-feb08fff *-usb:3 description: USB controller product: SB7x0/SB8x0/SB9x0 USB EHCI Controller vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 13.2 bus info: pci@0000:00:13.2 version: 00 width: 32 bits clock: 66MHz capabilities: ehci bus_master cap_list configuration: driver=ehci-pci latency=32 resources: irq:21 memory:feb07000-feb070ff *-serial description: SMBus product: SBx00 SMBus Controller vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 14 bus info: pci@0000:00:14.0 version: 42 width: 32 bits clock: 66MHz configuration: driver=piix4_smbus latency=0 resources: irq:0 *-multimedia description: Audio device product: SBx00 Azalia (Intel HDA) vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 14.2 bus info: pci@0000:00:14.2 version: 40 width: 64 bits clock: 33MHz capabilities: bus_master cap_list configuration: driver=snd_hda_intel latency=32 resources: irq:16 memory:feb00000-feb03fff *-isa description: ISA bridge product: SB7x0/SB8x0/SB9x0 LPC host controller vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 14.3 bus info: pci@0000:00:14.3 version: 40 width: 32 bits clock: 66MHz capabilities: isa bus_master configuration: latency=0 *-pci:4 description: PCI bridge product: SBx00 PCI to PCI Bridge vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 14.4 bus info: pci@0000:00:14.4 version: 40 width: 32 bits clock: 66MHz capabilities: pci subtractive_decode bus_master vga_palette *-usb:4 description: USB controller product: SB7x0/SB8x0/SB9x0 USB OHCI2 Controller vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 14.5 bus info: pci@0000:00:14.5 version: 00 width: 32 bits clock: 66MHz capabilities: ohci bus_master configuration: driver=ohci-pci latency=32 resources: irq:18 memory:feb06000-feb06fff *-usb:5 description: USB controller product: SB7x0/SB8x0/SB9x0 USB OHCI0 Controller vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 16 bus info: pci@0000:00:16.0 version: 00 width: 32 bits clock: 66MHz capabilities: ohci bus_master configuration: driver=ohci-pci latency=32 resources: irq:22 memory:feb05000-feb05fff *-usb:6 description: USB controller product: SB7x0/SB8x0/SB9x0 USB EHCI Controller vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 16.2 bus info: pci@0000:00:16.2 version: 00 width: 32 bits clock: 66MHz capabilities: ehci bus_master cap_list configuration: driver=ehci-pci latency=32 resources: irq:23 memory:feb04000-feb040ff *-pci:1 description: Host bridge product: Family 15h Processor Function 0 vendor: Advanced Micro Devices, Inc. [AMD] physical id: 101 bus info: pci@0000:00:18.0 version: 00 width: 32 bits clock: 33MHz *-pci:2 description: Host bridge product: Family 15h Processor Function 1 vendor: Advanced Micro Devices, Inc. [AMD] physical id: 102 bus info: pci@0000:00:18.1 version: 00 width: 32 bits clock: 33MHz *-pci:3 description: Host bridge product: Family 15h Processor Function 2 vendor: Advanced Micro Devices, Inc. [AMD] physical id: 103 bus info: pci@0000:00:18.2 version: 00 width: 32 bits clock: 33MHz *-pci:4 description: Host bridge product: Family 15h Processor Function 3 vendor: Advanced Micro Devices, Inc. [AMD] physical id: 104 bus info: pci@0000:00:18.3 version: 00 width: 32 bits clock: 33MHz configuration: driver=k10temp resources: irq:0 *-pci:5 description: Host bridge product: Family 15h Processor Function 4 vendor: Advanced Micro Devices, Inc. [AMD] physical id: 105 bus info: pci@0000:00:18.4 version: 00 width: 32 bits clock: 33MHz configuration: driver=fam15h_power resources: irq:0 *-pci:6 description: Host bridge product: Family 15h Processor Function 5 vendor: Advanced Micro Devices, Inc. [AMD] physical id: 106 bus info: pci@0000:00:18.5 version: 00 width: 32 bits clock: 33MHz *-scsi physical id: 2 logical name: scsi3 capabilities: emulated *-cdrom description: DVD-RAM writer product: RAM GHB1N vendor: ASUS DVD physical id: 0.0.0 bus info: scsi@3:0.0.0 logical name: /dev/cdrom logical name: /dev/sr0 version: AS00 capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram configuration: ansiversion=5 status=ready *-medium physical id: 0 logical name: /dev/cdrom *-scsi physical id: 1 bus info: scsi@5 logical name: scsi5 capabilities: scsi-host configuration: driver=usb-storage *-network:0 description: Ethernet interface physical id: 2 logical name: virbr0 serial: 52:54:00:74:b3:17 capabilities: ethernet physical configuration: broadcast=yes driver=bridge driverversion=2.3 firmware=N/A ip=192.168.122.1 link=no multicast=yes *-network:1 DISABLED description: Ethernet interface physical id: 3 logical name: virbr0-nic serial: 52:54:00:74:b3:17 size: 10Mbit/s capabilities: ethernet physical configuration: autonegotiation=off broadcast=yes driver=tun driverversion=1.6 duplex=full link=no multicast=yes port=twisted pair speed=10Mbit/s WARNING: output may be incomplete or inaccurate, you should run this program as super-user.
*********************************************************************** Due to that last line, issued su and password and ran it again: # lshw Segmentation fault (core dumped) # OK???!!??? Regards, Les H
On Tue, Jan 23, 2018 at 6:56 PM, Howard Howell hlhowell@pacbell.net wrote:
Due to that last line, issued su and password and ran it again: # lshw Segmentation fault (core dumped) #
Due to the fact that you're having segfaults in command-line programs as well, I'm tempted to say you've got a bigger (hardware?) problem on your hands, and that Wayland crashing is just a symptom of that larger issue.
-- Jared Smith
On Tue, 2018-01-23 at 19:52 -0500, Jared K. Smith wrote:
On Tue, Jan 23, 2018 at 6:56 PM, Howard Howell hlhowell@pacbell.net wrote:
Due to that last line, issued su and password and ran it again:
# lshw
Segmentation fault (core dumped)
#
Due to the fact that you're having segfaults in command-line programs as well, I'm tempted to say you've got a bigger (hardware?) problem on your hands, and that Wayland crashing is just a symptom of that larger issue.
-- Jared Smith
That's the first real crash from command line. Regards, Les H
On 01/23/2018 06:56 PM, Howard Howell wrote:
Due to that last line, issued su and password and ran it again: # lshw Segmentation fault (core dumped)
ok, great---so now do 'gdb lshw', type 'r' in gdb, and see where it crashes.
You may need to debuginfo-install few packages if gdb says it can't find debugging symbols, and you may need to install also some -source packages because the recent changes in packaging and dnf fail to do so. Then, report whether the crash happens reliably in a single location, or is random as it would be if your hardware is flaky.
On Wed, 2018-01-24 at 14:29 -0500, Przemek Klosowski wrote:
On 01/23/2018 06:56 PM, Howard Howell wrote:
Due to that last line, issued su and password and ran it again: # lshw Segmentation fault (core dumped)
ok, great---so now do 'gdb lshw', type 'r' in gdb, and see where it crashes.
You may need to debuginfo-install few packages if gdb says it can't find debugging symbols, and you may need to install also some -source packages because the recent changes in packaging and dnf fail to do so. Then, report whether the crash happens reliably in a single location, or is random as it would be if your hardware is flaky. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
It did not crash. Here are the last 2 lines it output:
configuration: autonegotiation=off broadcast=yes driver=tun driverversion=1.6 duplex=full link=no multicast=yes port=twisted pair speed=10Mbit/s WARNING: output may be incomplete or inaccurate, you should run this program as super-user. [Inferior 1 (process 3063) exited normally]
The things I would point out are that Terminal is in a window, and when that crash occured I had just run the command, and it may not have terminated fully. The command lshw seems to be multithreaded.
Regards, Les H
On Thu, 2018-01-25 at 09:51 -0800, Howard Howell wrote:
On Wed, 2018-01-24 at 14:29 -0500, Przemek Klosowski wrote:
On 01/23/2018 06:56 PM, Howard Howell wrote:
Due to that last line, issued su and password and ran it again: # lshw Segmentation fault (core dumped)
ok, great---so now do 'gdb lshw', type 'r' in gdb, and see where it crashes.
You may need to debuginfo-install few packages if gdb says it can't find debugging symbols, and you may need to install also some -source packages because the recent changes in packaging and dnf fail to do so. Then, report whether the crash happens reliably in a single location, or is random as it would be if your hardware is flaky. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
It did not crash. Here are the last 2 lines it output:
configuration: autonegotiation=off broadcast=yes driver=tun driverversion=1.6 duplex=full link=no multicast=yes port=twisted pair speed=10Mbit/s WARNING: output may be incomplete or inaccurate, you should run this program as super-user. [Inferior 1 (process 3063) exited normally]
The things I would point out are that Terminal is in a window, and when that crash occured I had just run the command, and it may not have terminated fully. The command lshw seems to be multithreaded.
Regards, Les H _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Now I'm in a new and apparently unresolvable loop for debug info for glibc. The program gdb when running lshw needs glibc-2.25- 12.fc26.x86_64.
But the install won't pick up that version. Here is the exchange with me (gdb) run Starting program: /usr/sbin/lshw Missing separate debuginfos, use: dnf debuginfo-install glibc-2.25- 12.fc26.x86_64 USB Program received signal SIGSEGV, Segmentation fault. 0x00007ffff72c1b70 in feof () from /lib64/libc.so.6 (gdb) exit Undefined command: "exit". Try "help". (gdb) quit A debugging session is active.
Inferior 1 [process 5734] will be killed.
Quit anyway? (y or n) y [root@school lesh]# dnf debuginfo-install glibc-2.25-12.fc26.x86_64 enabling updates-debuginfo repository enabling fedora-debuginfo repository enabling rpmfusion-free-updates-debuginfo repository enabling rpmfusion-free-debuginfo repository enabling rpmfusion-nonfree-updates-debuginfo repository enabling rpmfusion-nonfree-debuginfo repository Last metadata expiration check: 0:46:46 ago on Thu 25 Jan 2018 11:11:19 AM PST. Package glibc-debuginfo-2.23.1-11.fc24.x86_64 is already installed, skipping. Dependencies resolved. Nothing to do. Complete! [root@school lesh]# gdb lshw GNU gdb (GDB) Fedora 8.0.1-33.fc26 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl .html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from lshw...Reading symbols from /usr/lib/debug/usr/sbin/lshw.debug...done. done. (gdb) run Starting program: /usr/sbin/lshw Missing separate debuginfos, use: dnf debuginfo-install glibc-2.25- 12.fc26.x86_64 USB Program received signal SIGSEGV, Segmentation fault. 0x00007ffff72c1b70 in feof () from /lib64/libc.so.6 (gdb) and gdb running lshw:
FWIW, I too have Wayland crashing every few days. I can't pin-point a pattern: Just now it crashed while trying to open a pdf attachment in Thunderbird (using the default Document Viewer). After rebooting, the same attachment opened with no problems.
Given that the apps I use are pretty good about recovering from a crash, it's not a show-stopper for me, but it is annoying.
If any logs or monitoring tools would be helpful, I'll be happy to help.
I'm running an updated Fedora 27 on an HP Spectre. I have a 4k Sceptre monitor (cheap and possibly buggy) connected via a Thunderbolt-3-to-HDMI dongle - or maybe it's a USB-C-to-HDMI dongle :-).
On Mon, Jan 29, 2018 at 7:39 PM, Per Bothner per@bothner.com wrote:
If any logs or monitoring tools would be helpful, I'll be happy to help.
Please see my earlier post in this thread regarding how to get a stacktrace out of coredumpctl. If you post an issue report with a stacktrace at https://gitlab.gnome.org/GNOME/gnome-shell/issues, then the developers will have a chance to investigate.
Thanks,
Michael
On 01/29/2018 09:33 PM, mcatanzaro@gnome.org wrote:
Please see my earlier post in this thread regarding how to get a stacktrace out of coredumpctl
This is a great debugging harness; thanks for pointing it out as I didn't know about it.
I am currently reporting my pan-crashing-Wayland crashing issue on gnome.org---but in the true Heisenbug fashion it stopped crashing, so I can't reproduce it now. It was crashing almost every time I used the pan newsreader (the three crash dumps I submitted were just few days apart in my coredumpctl records), but now they're as solid as rock.
I have to say that the GNOME developers responded almost immediately, and I feel stupid for not being able to demonstrate replication. I am really curious about the nature of this bug: it must be some weird interaction---perhaps related to memory use or something like that.
On Tue, Jan 30, 2018 at 9:49 AM, Przemek Klosowski przemek.klosowski@nist.gov wrote:
I am currently reporting my pan-crashing-Wayland crashing issue on gnome.org---but in the true Heisenbug fashion it stopped crashing, so I can't reproduce it now. It was crashing almost every time I used the pan newsreader (the three crash dumps I submitted were just few days apart in my coredumpctl records), but now they're as solid as rock.
That's the great thing about coredumpctl: as long as the issue occurs again sometime in the future, the backtrace will be there waiting for you at that time, so it's not a big deal that you can't reproduce immediately.
Michael
On Tue, 2018-01-30 at 10:49 -0500, Przemek Klosowski wrote:
On 01/29/2018 09:33 PM, mcatanzaro@gnome.org wrote:
Please see my earlier post in this thread regarding how to get a stacktrace out of coredumpctl
This is a great debugging harness; thanks for pointing it out as I didn't know about it.
I am currently reporting my pan-crashing-Wayland crashing issue on gnome.org---but in the true Heisenbug fashion it stopped crashing, so I can't reproduce it now. It was crashing almost every time I used the pan newsreader (the three crash dumps I submitted were just few days apart in my coredumpctl records), but now they're as solid as rock.
IIRC we did fix at least one of the more commonly encountered crashers recently, so you might've been running into that one. There are still a few out there, though.
On Tue, 2018-01-30 at 10:49 -0500, Przemek Klosowski wrote:
On 01/29/2018 09:33 PM, mcatanzaro@gnome.org wrote:
Please see my earlier post in this thread regarding how to get a stacktrace out of coredumpctl
This is a great debugging harness; thanks for pointing it out as I didn't know about it.
I am currently reporting my pan-crashing-Wayland crashing issue on gnome.org---but in the true Heisenbug fashion it stopped crashing, so I can't reproduce it now. It was crashing almost every time I used the pan newsreader (the three crash dumps I submitted were just few days apart in my coredumpctl records), but now they're as solid as rock.
I have to say that the GNOME developers responded almost immediately, and I feel stupid for not being able to demonstrate replication. I am really curious about the nature of this bug: it must be some weird interaction---perhaps related to memory use or something like that. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
I had the same experience. I loaded all the tools that were recommended, and the crashes seem to have stopped ( that is no crashes since I loaded all the tools.) Maybe there is a hidden fix in the debug stuff.
Regards, Les H
On Tue, 2018-01-30 at 10:15 -0800, Howard Howell wrote:
On Tue, 2018-01-30 at 10:49 -0500, Przemek Klosowski wrote:
On 01/29/2018 09:33 PM, mcatanzaro@gnome.org wrote:
Please see my earlier post in this thread regarding how to get a stacktrace out of coredumpctl
This is a great debugging harness; thanks for pointing it out as I didn't know about it.
I am currently reporting my pan-crashing-Wayland crashing issue on gnome.org---but in the true Heisenbug fashion it stopped crashing, so I can't reproduce it now. It was crashing almost every time I used the pan newsreader (the three crash dumps I submitted were just few days apart in my coredumpctl records), but now they're as solid as rock.
I have to say that the GNOME developers responded almost immediately, and I feel stupid for not being able to demonstrate replication. I am really curious about the nature of this bug: it must be some weird interaction---perhaps related to memory use or something like that. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
I had the same experience. I loaded all the tools that were recommended, and the crashes seem to have stopped ( that is no crashes since I loaded all the tools.) Maybe there is a hidden fix in the debug stuff.
Regards, Les H _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
spoke too soon. Just got logged out. Had just finished looking up some info on bitcoin on the web, then closed the browser, moved the mouse toward the top annunciation in the top banner of the desktop. Screen went dark and dropped me out to the login window.
Checking logs and backtrace to see if I can find anything useful... Later post if I do.
Regards, Les H
On Wed, 2018-01-31 at 01:28 -0800, Howard Howell wrote:
On Tue, 2018-01-30 at 10:15 -0800, Howard Howell wrote:
On Tue, 2018-01-30 at 10:49 -0500, Przemek Klosowski wrote:
On 01/29/2018 09:33 PM, mcatanzaro@gnome.org wrote:
Please see my earlier post in this thread regarding how to get a stacktrace out of coredumpctl
This is a great debugging harness; thanks for pointing it out as I didn't know about it.
I am currently reporting my pan-crashing-Wayland crashing issue on gnome.org---but in the true Heisenbug fashion it stopped crashing, so I can't reproduce it now. It was crashing almost every time I used the pan newsreader (the three crash dumps I submitted were just few days apart in my coredumpctl records), but now they're as solid as rock.
I have to say that the GNOME developers responded almost immediately, and I feel stupid for not being able to demonstrate replication. I am really curious about the nature of this bug: it must be some weird interaction---perhaps related to memory use or something like that. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel- leave@lists.fedoraproject.org
I had the same experience. I loaded all the tools that were recommended, and the crashes seem to have stopped ( that is no crashes since I loaded all the tools.) Maybe there is a hidden fix in the debug stuff.
Regards, Les H _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
spoke too soon. Just got logged out. Had just finished looking up some info on bitcoin on the web, then closed the browser, moved the mouse toward the top annunciation in the top banner of the desktop. Screen went dark and dropped me out to the login window.
Checking logs and backtrace to see if I can find anything useful... Later post if I do.
Regards, Les H _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Well, Journalctl shows the following. Jan 31 00:00:00 school evolution-alarm[2297]: /builddir/build/BUILD/evolution-3.24.6/src/calendar/alarm- notify/alarm.c:251: Jan 31 00:19:56 school sol.desktop[24828]: xkbcommon: ERROR: Key "<CAPS>" added to modifier map for multiple modifiers; Usi Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /var/tmp/systemd-private-3d6dfe8707be46aa9187 Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /var/tmp/systemd-private-3d6dfe8707be46aa9187 Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /var/tmp/systemd-private-3d6dfe8707be46aa9187 Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /var/tmp/systemd-private-3d6dfe8707be46aa9187 Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /tmp/systemd-private-3d6dfe8707be46aa9187e85e Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /tmp/systemd-private-3d6dfe8707be46aa9187e85e Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /tmp/systemd-private-3d6dfe8707be46aa9187e85e Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /tmp/systemd-private-3d6dfe8707be46aa9187e85e Jan 31 01:09:51 school org.gnome.Calculator.desktop[25129]: xkbcommon: ERROR: Key "<CAPS>" added to modifier map for multip Jan 31 01:10:45 school gnome-calculato[25129]: gtk_container_remove: assertion 'GTK_IS_WIDGET (widget)' failed Jan 31 01:14:08 school evolution-alarm[2297]: Error reading events from display: Broken pipe Jan 31 01:14:08 school gnome-software[2301]: Error reading events from display: Broken pipe Jan 31 01:14:08 school gnome-session-binary[1715]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1 Jan 31 01:14:08 school gnome-session[1715]: gnome-session-binary[1715]: WARNING: App 'org.gnome.Shell.desktop' exited with Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: Window manager error: Could not find cursor. Perhaps set XCURSOR_PATH Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: Fatal server error: Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: (EE) failed to read Wayland events: Broken pipe Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: (EE) Jan 31 01:14:08 school gnome-session-binary[1715]: Unrecoverable failure in required component org.gnome.Shell.desktop Jan 31 01:14:08 school org.gnome.SettingsDaemon.MediaKeys.desktop[2048]: xcb_connection_has_error() returned true Jan 31 01:14:08 school gsd-housekeepin[2045]: gsd-housekeeping: Fatal IO error 11 (Resource temporarily unavailable) on X s Jan 31 01:14:08 school gsd-print-notif[2013]: gsd-print-notifications: Fatal IO error 11 (Resource temporarily unavailable) Jan 31 01:14:08 school at-spi-bus-launcher[1825]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ": ESCOC
This doesn't tell me anything, but I'll bet some of you systems guys can see through it to see the root cause, or at least a good trail to follow.
Regards, Les H
Hi,
What you logs tells is:
On Wed, Jan 31, 2018 at 10:37 AM, Howard Howell hlhowell@pacbell.net wrote:
Jan 31 01:14:08 school evolution-alarm[2297]: Error reading events from display: Broken pipe Jan 31 01:14:08 school gnome-software[2301]: Error reading events from display: Broken pipe
Wayland native applications exiting with broken pipe, means the Wayland compositor (gnome-shell is dead)
Jan 31 01:14:08 school gnome-session-binary[1715]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
gnome-session tells us that gnome-shell is gone
Jan 31 01:14:08 school gnome-session[1715]: gnome-session-binary[1715]: WARNING: App 'org.gnome.Shell.desktop' exited with Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: Window manager error: Could not find cursor. Perhaps set XCURSOR_PATH
Interesting, that could be the problem! gnome-shell is both a Wayland compositor (thus the display server) and an X11 window manager.
Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: Fatal server error: Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: (EE) failed to read Wayland events: Broken pipe Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: (EE)
Then Xwayland exits with “broken pipe”, like the other Wayland clients, because the Wayland compositor is, well ,dead.
Jan 31 01:14:08 school gnome-session-binary[1715]: Unrecoverable failure in required component org.gnome.Shell.desktop
gnome-session says something goes really wrong...
Jan 31 01:14:08 school org.gnome.SettingsDaemon.MediaKeys.desktop[2048]: xcb_connection_has_error() returned true Jan 31 01:14:08 school gsd-housekeepin[2045]: gsd-housekeeping: Fatal IO error 11 (Resource temporarily unavailable) on X s Jan 31 01:14:08 school gsd-print-notif[2013]: gsd-print-notifications: Fatal IO error 11 (Resource temporarily unavailable) Jan 31 01:14:08 school at-spi-bus-launcher[1825]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ": ESCOC
And now, the X11 clients (hence depending on the X server, thus Xwayland) all quit as well, because the X server (Xwayland) is dead, because the Wayland compositor is dead...
This doesn't tell me anything, but I'll bet some of you systems guys can see through it to see the root cause, or at least a good trail to follow.
I think we should keep those discussions, including these important bits, in the issue you filed upstream ( https://gitlab.gnome.org/GNOME/gnome-shell/issues/9) and not in a downstream mailing list :)
Cheers, Olivier
Hi
On Wed, Jan 31, 2018 at 1:58 PM, Olivier Fourdan ofourdan@redhat.com wrote:
Jan 31 01:14:08 school gnome-session[1715]: gnome-session-binary[1715]: WARNING: App 'org.gnome.Shell.desktop' exited with
Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: Window manager error: Could not find cursor. Perhaps set XCURSOR_PATH
Interesting, that could be the problem! gnome-shell is both a Wayland compositor (thus the display server) and an X11 window manager.
Are you using a custom cursor theme or the default “Adwaita” cursor theme?
I think we should keep those discussions, including these important bits, in the issue you filed upstream (https://gitlab.gnome.org/GNOM E/gnome-shell/issues/9) and not in a downstream mailing list :)
And... I got confused by multiple issues being reported in the same mail thread, that issue was filed by Przemek, so probably different from yours...
Cheers, Olivier
On Wed, 2018-01-31 at 14:14 +0100, Olivier Fourdan wrote:
Hi
On Wed, Jan 31, 2018 at 1:58 PM, Olivier Fourdan <ofourdan@redhat.com
wrote: Jan 31 01:14:08 school gnome-session[1715]: gnome-session- binary[1715]: WARNING: App 'org.gnome.Shell.desktop' exited with
Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: Window manager error: Could not find cursor. Perhaps set XCURSOR_PATH
Interesting, that could be the problem! gnome-shell is both a Wayland compositor (thus the display server) and an X11 window manager.
Are you using a custom cursor theme or the default “Adwaita” cursor theme?
I think we should keep those discussions, including these important bits, in the issue you filed upstream (https://gitlabgnome.org/GNOM E/gnome-shell/issues/9) and not in a downstream mailing list :)
And... I got confused by multiple issues being reported in the same mail thread, that issue was filed by Przemek, so probably different from yours...
Cheers, Olivier
OK! I did change the cursor theme. According to gnome-tweak-tool, it is Gamma.Gold. I have some vision problems and this looked good to me.
Regards, Les H
On Wed, 2018-01-31 at 09:43 -0800, Howard Howell wrote:
On Wed, 2018-01-31 at 14:14 +0100, Olivier Fourdan wrote:
Hi
On Wed, Jan 31, 2018 at 1:58 PM, Olivier Fourdan <ofourdan@redhat.c om> wrote:
Jan 31 01:14:08 school gnome-session[1715]: gnome-session- binary[1715]: WARNING: App 'org.gnome.Shell.desktop' exited with
Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: Window manager error: Could not find cursor. Perhaps set XCURSOR_PATH
Interesting, that could be the problem! gnome-shell is both a Wayland compositor (thus the display server) and an X11 window manager.
Are you using a custom cursor theme or the default “Adwaita” cursor theme?
I think we should keep those discussions, including these important bits, in the issue you filed upstream (https://gitlabgn ome.org/GNOME/gnome-shell/issues/9) and not in a downstream mailing list :)
And... I got confused by multiple issues being reported in the same mail thread, that issue was filed by Przemek, so probably different from yours...
Cheers, Olivier
OK! I did change the cursor theme. According to gnome-tweak-tool, it is Gamma.Gold. I have some vision problems and this looked good to me.
Regards, Les H _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
I replied back to this message because the laters ones all are either mine or another thread within this topic... Olivier, I left my system logged in, and several journal entries occured while I slept. Then today there are lots of messages about evolution. And after being on the system for only 20 minutes, I got logged off again.
I captured the messages to a file (744 lines) and have attached it here.
Regards, Les H
On Thu, 2018-02-01 at 09:08 -0800, Howard Howell wrote:
On Wed, 2018-01-31 at 09:43 -0800, Howard Howell wrote:
On Wed, 2018-01-31 at 14:14 +0100, Olivier Fourdan wrote:
Hi
On Wed, Jan 31, 2018 at 1:58 PM, Olivier Fourdan <ofourdan@redhat .com> wrote:
Jan 31 01:14:08 school gnome-session[1715]: gnome-session- binary[1715]: WARNING: App 'org.gnome.Shell.desktop' exited with
Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: Window manager error: Could not find cursor. Perhaps set XCURSOR_PATH
Interesting, that could be the problem! gnome-shell is both a Wayland compositor (thus the display server) and an X11 window manager.
Are you using a custom cursor theme or the default “Adwaita” cursor theme?
I think we should keep those discussions, including these important bits, in the issue you filed upstream (https://gitlab gnome.org/GNOME/gnome-shell/issues/9) and not in a downstream mailing list :)
And... I got confused by multiple issues being reported in the same mail thread, that issue was filed by Przemek, so probably different from yours...
Cheers, Olivier
OK! I did change the cursor theme. According to gnome-tweak-tool, it is Gamma.Gold. I have some vision problems and this looked good to me.
Regards, Les H _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
I replied back to this message because the laters ones all are either mine or another thread within this topic... Olivier, I left my system logged in, and several journal entries occured while I slept. Then today there are lots of messages about evolution. And after being on the system for only 20 minutes, I got logged off again.
I captured the messages to a file (744 lines) and have attached it here.
Regards, Les H _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Latest finding... running gpartd, which I wanted to use to reformat an SD card for use with a raspberry PI, drops me out to login immediately. attached is the latest journalctl after the third attempt. I clicked on gpartd at 17:36:14, and ended up logging back in at 17:37:01
I don't know if this helps, but gpartd seems to fire the issue every time.
Regards, Les H
On 02/03/2018 05:58 PM, Howard Howell wrote:
Latest finding... running gpartd, which I wanted to use to reformat an SD card for use with a raspberry PI, drops me out to login immediately. attached is the latest journalctl after the third attempt. I clicked on gpartd at 17:36:14, and ended up logging back in at 17:37:01
I don't know if this helps, but gpartd seems to fire the issue every time.
Did you try switching the cursor theme back to the default to see if that makes a difference? Also, be aware that there's an issue with the Places menu extension that gets triggered in various ways which might be relevant here.
On Sat, 2018-02-03 at 22:58 -0800, Samuel Sieb wrote:
On 02/03/2018 05:58 PM, Howard Howell wrote:
Latest finding... running gpartd, which I wanted to use to reformat an SD card for use with a raspberry PI, drops me out to login immediately. attached is the latest journalctl after the third attempt. I clicked on gpartd at 17:36:14, and ended up logging back in at 17:37:01
I don't know if this helps, but gpartd seems to fire the issue every time.
Did you try switching the cursor theme back to the default to see if that makes a difference? Also, be aware that there's an issue with the Places menu extension that gets triggered in various ways which might be relevant here.
https://bugzilla.redhat.com/show_bug.cgi?id=1538493 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Hi, Samuel, I did switch the cursors back using gnome-tweak-tool. While doing that I noticed that there was no selection for the shell theme, not even the default nor was default or Adwaita available in the pull down. I installed the only one I could find from dnf, which was selene. Once that was done, the alarm ( a triangle with an "!" in it) disappeared, and both default and Adwaita appeared in the pull down. I selected default. It appears that the default setup doesn't actually load the shell theme.
So far, so good, but I really miss the gamma.gold cursors which are much easier for me to see and use.
No problems so far. If it goes one week, I will again attempt the Gamma.Gold cursors because I need the visibility. My eyes hurt after a few hours trying to find the smaller and darker default cursors.
Regards, Les H
On 02/05/2018 01:35 PM, Howard Howell wrote:
My eyes hurt after a few hours trying to find the smaller and darker default cursors.
Do you know that you can simply increase the size of the cursors?
dconf write /org/gnome/desktop/interface/cursor-size 48
I swear I saw it in one of GNOME GUI tools but I can't find it now (doesn't seem to be in Settings or Gnome-tweaks)
On Mon, 2018-02-05 at 16:39 -0500, Przemek Klosowski wrote:
On 02/05/2018 01:35 PM, Howard Howell wrote:
My eyes hurt after a few hours trying to find the smaller and darker default cursors.
Do you know that you can simply increase the size of the cursors?
dconf write /org/gnome/desktop/interface/cursor-size 48
I swear I saw it in one of GNOME GUI tools but I can't find it now (doesn't seem to be in Settings or Gnome-tweaks) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
You are on my hero's list. Somebody figure out how to make this part of gnome-tweak-tool, PLEASE, or on the accessibility menu.
Thank YOU!!! Les H
On Tue, 2018-02-06 at 08:53 -0800, Howard Howell wrote:
On Mon, 2018-02-05 at 16:39 -0500, Przemek Klosowski wrote:
On 02/05/2018 01:35 PM, Howard Howell wrote:
My eyes hurt after a few hours trying to find the smaller and darker default cursors.
Do you know that you can simply increase the size of the cursors?
dconf write /org/gnome/desktop/interface/cursor-size 48
I swear I saw it in one of GNOME GUI tools but I can't find it now (doesn't seem to be in Settings or Gnome-tweaks) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
You are on my hero's list. Somebody figure out how to make this part of gnome-tweak-tool, PLEASE, or on the accessibility menu.
In GNOME Settings 3.26.2, go to "Universal Access" then change the "Cursor Size" option.
On 02/06/2018 11:53 AM, Howard Howell wrote:
On Mon, 2018-02-05 at 16:39 -0500, Przemek Klosowski wrote:
On 02/05/2018 01:35 PM, Howard Howell wrote:
My eyes hurt after a few hours trying to find the smaller and darker default cursors.
Do you know that you can simply increase the size of the cursors?
You are on my hero's list. Somebody figure out how to make this part of gnome-tweak-tool, PLEASE, or on the accessibility menu.
We older folk need to support each other; let us start the Fedora Grandpa Edition :)
Trigger warning: what follows is a rant from an older person in your midst. I don't know what's the right solution to the issues I raise, but I do think I have a point. I hope the young developers consider these in future design decisions.
I am beginning to think that in pursuit of flexibility and increased functionality we end up making systems that are too complex and too hard to discover. Users with cognitive or physical limitations have increasingly harder time negotiating the technology:
* My 82-year-old dad has difficulties operating his iPhone simply because there are too many options on it * on your stereo, is netflix on Fire, Chromecast, Blueray player or cable box?
I do like the functionality when it 'just works' but when it doesn't, it's often a debacle. There should be a way to dial back the complexity; show less options, etc. The old tradeoff was between simple systems with limited functionality, and complex but capable systems. Maybe there's a way to have both: annotate OS features by how fancy they are, and provide a dial that selects more or less of those advanced features, to accommodate both power users and those who want a simple, basic, utilitarian system.
On Tue, 2018-02-06 at 13:37 -0500, Przemek Klosowski wrote:
I am beginning to think that in pursuit of flexibility and increased functionality we end up making systems that are too complex and too hard to discover. Users with cognitive or physical limitations have increasingly harder time negotiating the technology:
s/Users with cognitive or physical limitations/Users/ ...
On 02/05/2018 10:35 AM, Howard Howell wrote:
So far, so good, but I really miss the gamma.gold cursors which are much easier for me to see and use.
No problems so far. If it goes one week, I will again attempt the Gamma.Gold cursors because I need the visibility. My eyes hurt after a few hours trying to find the smaller and darker default cursors.
Maybe try contacting the authors and mention that the theme is incomplete. You could also check yourself to find out which ones are missing and make replacements.
On Wed, 2018-01-31 at 13:58 +0100, Olivier Fourdan wrote:
Hi,
What you logs tells is:
On Wed, Jan 31, 2018 at 10:37 AM, Howard Howell <hlhowell@pacbell.net
wrote: Jan 31 01:14:08 school evolution-alarm[2297]: Error reading events from display: Broken pipeJan 31 01:14:08 school gnome- software[2301]: Error reading events from display: Broken pipe
Wayland native applications exiting with broken pipe, means the Wayland compositor (gnome-shell is dead)
Jan 31 01:14:08 school gnome-session-binary[1715]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
gnome-session tells us that gnome-shell is gone
Jan 31 01:14:08 school gnome-session[1715]: gnome-session- binary[1715]: WARNING: App 'org.gnome.Shell.desktop' exited with Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: Window manager error: Could not find cursor. Perhaps set XCURSOR_PATH
Interesting, that could be the problem! gnome-shell is both a Wayland compositor (thus the display server) and an X11 window manager.
Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: Fatal server error: Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: (EE) failed to read Wayland events: Broken pipe Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: (EE)
Then Xwayland exits with “broken pipe”, like the other Wayland clients, because the Wayland compositor is, well ,dead.
Jan 31 01:14:08 school gnome-session-binary[1715]: Unrecoverable failure in required component org.gnome.Shell.desktop
gnome-session says something goes really wrong...
Jan 31 01:14:08 school org.gnome.SettingsDaemon.MediaKeys.desktop[2048]: xcb_connection_has_error() returned true Jan 31 01:14:08 school gsd-housekeepin[2045]: gsd-housekeeping: Fatal IO error 11 (Resource temporarily unavailable) on X s Jan 31 01:14:08 school gsd-print-notif[2013]: gsd-print- notifications: Fatal IO error 11 (Resource temporarily unavailable) Jan 31 01:14:08 school at-spi-bus-launcher[1825]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ": ESCOC
And now, the X11 clients (hence depending on the X server, thus Xwayland) all quit as well, because the X server (Xwayland) is dead, because the Wayland compositor is dead...
This doesn't tell me anything, but I'll bet some of you systems guys can see through it to see the root cause, or at least a good trail to follow.
I think we should keep those discussions, including these important bits, in the issue you filed upstream (https://gitlab.gnome.org/GNOME /gnome-shell/issues/9) and not in a downstream mailing list :)
Cheers, Olivier
Do you want me to repost at that address?
On 31 January 2018 at 09:37, Howard Howell hlhowell@pacbell.net wrote: [..]
Well, Journalctl shows the following. Jan 31 00:00:00 school evolution-alarm[2297]: /builddir/build/BUILD/evolution-3.24.6/src/calendar/alarm- notify/alarm.c:251: Jan 31 00:19:56 school sol.desktop[24828]: xkbcommon: ERROR: Key "<CAPS>" added to modifier map for multiple modifiers; Usi Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /var/tmp/systemd-private-3d6dfe8707be46aa9187 Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /var/tmp/systemd-private-3d6dfe8707be46aa9187 Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /var/tmp/systemd-private-3d6dfe8707be46aa9187 Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /var/tmp/systemd-private-3d6dfe8707be46aa9187 Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /tmp/systemd-private-3d6dfe8707be46aa9187e85e Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /tmp/systemd-private-3d6dfe8707be46aa9187e85e Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /tmp/systemd-private-3d6dfe8707be46aa9187e85e Jan 31 00:59:38 school gsd-housekeepin[2045]: Failed to enumerate children of /tmp/systemd-private-3d6dfe8707be46aa9187e85e Jan 31 01:09:51 school org.gnome.Calculator.desktop[25129]: xkbcommon: ERROR: Key "<CAPS>" added to modifier map for multip Jan 31 01:10:45 school gnome-calculato[25129]: gtk_container_remove: assertion 'GTK_IS_WIDGET (widget)' failed Jan 31 01:14:08 school evolution-alarm[2297]: Error reading events from display: Broken pipe Jan 31 01:14:08 school gnome-software[2301]: Error reading events from display: Broken pipe Jan 31 01:14:08 school gnome-session-binary[1715]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1 Jan 31 01:14:08 school gnome-session[1715]: gnome-session-binary[1715]: WARNING: App 'org.gnome.Shell.desktop' exited with Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: Window manager error: Could not find cursor. Perhaps set XCURSOR_PATH Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: Fatal server error: Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: (EE) failed to read Wayland events: Broken pipe Jan 31 01:14:08 school org.gnome.Shell.desktop[1785]: (EE) Jan 31 01:14:08 school gnome-session-binary[1715]: Unrecoverable failure in required component org.gnome.Shell.desktop Jan 31 01:14:08 school org.gnome.SettingsDaemon.MediaKeys.desktop[2048]: xcb_connection_has_error() returned true Jan 31 01:14:08 school gsd-housekeepin[2045]: gsd-housekeeping: Fatal IO error 11 (Resource temporarily unavailable) on X s Jan 31 01:14:08 school gsd-print-notif[2013]: gsd-print-notifications: Fatal IO error 11 (Resource temporarily unavailable) Jan 31 01:14:08 school at-spi-bus-launcher[1825]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ": ESCOC
This doesn't tell me anything, but I'll bet some of you systems guys can see through it to see the root cause, or at least a good trail to follow.
After update today to latest rawhide and reboot I'v decided to change GUI from X11 to Wyland. In logs I see similar entries like above.
Additionally what I found so far after few hours:
1) sometimes pressing single key is causing to generate many keystrokes. Very annoying .. I had such effect at least 10 times in last hour. Looks like some libinput effect.
2) I have wireless Logitech mouse and when I'm moving mouse cursor after at least few seconds whole desktop stops for about 0.5 to less than second (with mouse cursor as well) and each time after this in dmesg I see sequence of lines like:
[26683.059926] [drm] PCIE gen 2 link speeds already enabled [26683.069526] [drm] PCIE GART of 1024M enabled (table at 0x0000000000162000). [26683.069637] radeon 0000:01:00.0: WB enabled [26683.069642] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0x00000000d8c75981 [26683.069646] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0x000000001142ed24 [26683.070395] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0x00000000095357f2 [26683.086835] [drm] ring test on 0 succeeded in 2 usecs [26683.086851] [drm] ring test on 3 succeeded in 7 usecs [26683.264201] [drm] ring test on 5 succeeded in 2 usecs [26683.264214] [drm] UVD initialized successfully. [26683.264346] [drm] ib test on ring 0 succeeded in 0 usecs [26683.264481] [drm] ib test on ring 3 succeeded in 0 usecs [26683.919712] [drm] ib test on ring 5 succeeded
Every few times of such sequence additionally I have:
[26815.820342] radeon 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [26815.820349] swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152 [26815.820355] CPU: 0 PID: 7813 Comm: kworker/0:2 Tainted: G W 4.15.0-0.rc9.git4.1.fc28.x86_64 #1 [26815.820359] Hardware name: Sony Corporation VPCSB2M9E/VAIO, BIOS R2087H4 06/15/2012 [26815.820367] Workqueue: pm pm_runtime_work [26815.820372] Call Trace: [26815.820384] dump_stack+0x85/0xbf [26815.820392] swiotlb_alloc_coherent+0xe0/0x150 [26815.820406] ttm_dma_pool_get_pages+0x21b/0x620 [ttm] [26815.820422] ttm_dma_populate+0x24d/0x340 [ttm] [26815.820434] ttm_bo_move_memcpy+0x185/0x610 [ttm] [26815.820444] ? lock_acquire+0x9f/0x200 [26815.820450] ? reservation_object_wait_timeout_rcu+0xb3/0x500 [26815.820500] radeon_bo_move+0x1a7/0x220 [radeon] [26815.820516] ttm_bo_handle_move_mem+0x2a4/0x5d0 [ttm] [26815.820532] ttm_bo_evict+0x186/0x370 [ttm] [26815.820552] ttm_mem_evict_first+0x174/0x1d0 [ttm] [26815.820565] ttm_bo_force_list_clean+0x6d/0x130 [ttm] [26815.820588] radeon_suspend_kms+0x11e/0x3e0 [radeon] [26815.820598] ? vga_switcheroo_runtime_resume+0x60/0x60 [26815.820613] radeon_pmops_runtime_suspend+0x54/0xc0 [radeon] [26815.820619] pci_pm_runtime_suspend+0x61/0x170 [26815.820625] vga_switcheroo_runtime_suspend+0x24/0xa0 [26815.820630] __rpm_callback+0xbc/0x1f0 [26815.820635] ? vga_switcheroo_runtime_resume+0x60/0x60 [26815.820639] rpm_callback+0x1f/0x70 [26815.820644] ? vga_switcheroo_runtime_resume+0x60/0x60 [26815.820648] rpm_suspend+0x12d/0x6e0 [26815.820655] pm_runtime_work+0x73/0xb0 [26815.820661] process_one_work+0x249/0x6b0 [26815.820670] worker_thread+0x3a/0x390 [26815.820675] ? process_one_work+0x6b0/0x6b0 [26815.820680] kthread+0x121/0x140 [26815.820684] ? kthread_create_worker_on_cpu+0x70/0x70 [26815.820691] ret_from_fork+0x3a/0x50
4) Strange log entries like:
Jan 31 12:36:09 domek org.gnome.Shell.desktop[2153]: Window manager warning: last_user_time (26100487) is greater than comparison timestamp (26100483). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around... Jan 31 12:36:09 domek org.gnome.Shell.desktop[2153]: Window manager warning: 0x2200001 (SysOps / D) appears to be one of the offending windows with a timestamp of 261004 87. Working around... Jan 31 12:36:09 domek org.gnome.Shell.desktop[2153]: Window manager warning: last_user_time (26100517) is greater than comparison timestamp (26100514). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around... Jan 31 12:36:09 domek org.gnome.Shell.desktop[2153]: Window manager warning: 0x2200001 (SysOps / D) appears to be one of the offending windows with a timestamp of 261005 17. Working around...
Repeated quite quickly up to ~15 times.
5) other sequence of log entries repeated many times (up to ~30 times in sequence)
Jan 31 12:40:21 domek org.gnome.Shell.desktop[2153]: Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough! Jan 31 12:40:21 domek org.gnome.Shell.desktop[2153]: Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough! Jan 31 12:40:21 domek org.gnome.Shell.desktop[2153]: Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough!
None of those effects is possible to observe under X11
Other strange looking things which I saw under X11:
1) VSZ of all evolution processes is ~100GB (one hundredth GB)
$ ps auxwf | grep evolu tkloczko 2647 0.0 0.3 102237860 26316 tty2 Sl+ 05:24 0:00 _ /usr/libexec/evolution/evolution-alarm-notify tkloczko 2313 0.0 0.3 102233120 26708 ? SLsl 05:24 0:00 _ /usr/libexec/evolution-source-registry tkloczko 2404 0.0 0.6 101788284 52520 ? Ssl 05:24 0:00 _ /usr/libexec/evolution-calendar-factory tkloczko 2496 0.0 0.8 102632304 65420 ? Sl 05:24 0:01 | _ /usr/libexec/evolution-calendar-factory-subprocess --factory caldav --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.Calendarx2404x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/ Calendar/2404/2 tkloczko 2618 0.0 0.6 118691584 51864 ? Sl 05:24 0:00 | _ /usr/libexec/evolution-calendar-factory-subprocess --factory contacts --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.Calendarx2404x3 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/ Calendar/2404/3 tkloczko 2694 0.0 0.6 101907300 51936 ? Sl 05:24 0:00 | _ /usr/libexec/evolution-calendar-factory-subprocess --factory local --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.Calendarx2404x4 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/ Calendar/2404/4 tkloczko 3305 0.0 0.6 102061428 53176 ? Sl 05:25 0:00 | _ /usr/libexec/evolution-calendar-factory-subprocess --factory gtasks --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.Calendarx2404x5 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/ Calendar/2404/5 tkloczko 2646 0.0 0.2 101740068 17236 ? Ssl 05:24 0:00 _ /usr/libexec/evolution-addressbook-factory tkloczko 2728 0.0 0.2 101874972 18036 ? Sl 05:24 0:00 | _ /usr/libexec/evolution-addressbook-factory-subprocess --factory local --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.AddressBookx2646x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/ AddressBook/2646/2
Quite often something like this happens when some files are opened in mmap mode and if current seek pos is quite big. I've been looking on list of opened files by those processes but so far was not able to find why VSZ is so big (RSS as it is possible to see is ~normal)
2) oneliner which allows retrieve 200-300MB RSS after login over GDM:
$ sudo pkill -u gdm
3) Under Weyland and X11 gnome-shell is core dumping:
(gdb) bt #0 0x00007feacdef48d1 in _g_log_abort (breakpoint=1) at gmessages.c:583 #1 0x00007feacdef590c in g_log_default_handler (log_domain=<optimized out>, log_level=<optimized out>, message=<optimized out>, unused_data=<optimized out>) at gmessages.c:3104 #2 0x000055c78df89795 in default_log_handler (log_domain=log_domain@entry=0x7feacc4782be "mutter", log_level=log_level@entry=6, message=message@entry=0x55c790700760 "Connection to xwayland lost", data=data@entry=0x0) at ../src/main.c:311 #3 0x00007feacdef5b9d in g_logv (log_domain=0x7feacc4782be "mutter", log_level=G_LOG_LEVEL_ERROR, format=<optimized out>, args=args@entry =0x7ffcb7de0470) at gmessages.c:1370 #4 0x00007feacdef5d0f in g_log (log_domain=log_domain@entry=0x7feacc4782be "mutter", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x7feacc48a790 "Connection to xwayland lost") at gmessages.c:1432 #5 0x00007feacc43796e in x_io_error (display=<optimized out>) at wayland/meta-xwayland.c:411 #6 0x00007feacab40ede in _XIOError (dpy=dpy@entry=0x55c7903cff10) at XlibInt.c:1469 #7 0x00007feacab3e76d in _XEventsQueued (dpy=dpy@entry=0x55c7903cff10, mode=mode@entry=2) at xcb_io.c:352 #8 0x00007feacab302bd in XPending (dpy=0x55c7903cff10) at Pending.c:55 #9 0x00007feacb695c81 in gdk_check_xpending (display=<optimized out>) at gdkeventsource.c:269 #10 0x00007feacb695c81 in gdk_event_source_check (source=0x55c78ff2b170) at gdkeventsource.c:306 #11 0x00007feacdeee969 in g_main_context_check (context=context@entry=0x55c78ff2e800, max_priority=0, fds=fds@entry=0x55c790629590, n_fds=n_fds@entry=17) at gmain.c:3736 #12 0x00007feacdeeeee0 in g_main_context_iterate (context=0x55c78ff2e800, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3900 #13 0x00007feacdeef2d2 in g_main_loop_run (loop=0x55c79039b8d0) at gmain.c:4099 #14 0x00007feacc40319c in meta_run () at core/main.c:648 #15 0x000055c78df892b7 in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.c:462
Especially #2 looks a bit odd ("Connection to xwayland lost")
kloczek
- sometimes pressing single key is causing to generate many keystrokes.
Very annoying ..
That can get more than annoying when it combines with the inverse effect: eating keystrokes and refusing to output them (sometimes regurgitating parts of what it ate as few seconds later in the middle of something else you're typing)
Though that seems to happen mostly when I use a wireless logitech keyboard, not with the built-in laptop keyboard
Visibly input is not baked yet in Wayland
Regards,
On Wed, Jan 31, 2018 at 01:37:15PM +0000, Tomasz Kłoczko wrote:
After update today to latest rawhide and reboot I'v decided to change GUI from X11 to Wyland. In logs I see similar entries like above.
Additionally what I found so far after few hours:
- sometimes pressing single key is causing to generate many keystrokes.
Very annoying .. I had such effect at least 10 times in last hour. Looks like some libinput effect.
This one is a peculiarity of GNOME Terminal; I've reported it over a decade ago: https://bugzilla.gnome.org/show_bug.cgi?id=354329 I don't think it's related to Wayland or libinput.
On 31 January 2018 at 21:00, Tomasz Torcz 👁️ tomek@pipebreaker.pl wrote:
On Wed, Jan 31, 2018 at 01:37:15PM +0000, Tomasz Kłoczko wrote:
After update today to latest rawhide and reboot I'v decided to change GUI from X11 to Wyland. In logs I see similar entries like above.
Additionally what I found so far after few hours:
- sometimes pressing single key is causing to generate many keystrokes.
Very annoying .. I had such effect at least 10 times in last hour. Looks like some libinput effect.
This one is a peculiarity of GNOME Terminal; I've reported it over a decade ago: https://bugzilla.gnome.org/show_bug.cgi?id=354329 I don't think it's related to Wayland or libinput.
I see this mainly in chrome and polari. In less than 24h of using Weyland so far I've not been able to observe this with gnome-terminal. Looks like this effect is not limited to only one application. As I wrote I don't see this repeating keystrokes effect under X11.
Why I think that it may be related to libinput? Because in logs I see as well another type of entries:
# journalctl -xe | grep libinput Jan 31 21:55:18 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event5 debounce: offset negative (-354ms) Jan 31 21:55:18 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event5 debounce short: offset negative (-368ms) Jan 31 21:56:27 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event5 debounce: offset negative (-1107ms) Jan 31 21:56:27 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event5 debounce short: offset negative (-1120ms) Jan 31 22:05:12 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event4 keyboard: offset negative (-331ms) Jan 31 22:06:05 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event4 keyboard: offset negative (-750ms) Jan 31 22:06:05 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event4 keyboard: offset negative (-413ms)
kloczek
On 31 January 2018 at 22:09, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote: [..]
Why I think that it may be related to libinput? Because in logs I see as well another type of entries:
# journalctl -xe | grep libinput Jan 31 21:55:18 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event5 debounce: offset negative (-354ms) Jan 31 21:55:18 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event5 debounce short: offset negative (-368ms) Jan 31 21:56:27 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event5 debounce: offset negative (-1107ms) Jan 31 21:56:27 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event5 debounce short: offset negative (-1120ms) Jan 31 22:05:12 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event4 keyboard: offset negative (-331ms) Jan 31 22:06:05 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event4 keyboard: offset negative (-750ms) Jan 31 22:06:05 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event4 keyboard: offset negative (-413ms)
Correction:
# libinput list-devices | grep ^Device -A1 Device: Video Bus Kernel: /dev/input/event7 -- Device: Sony Vaio Jogdial Kernel: /dev/input/event9 -- Device: Sony Vaio Keys Kernel: /dev/input/event8 -- Device: Video Bus Kernel: /dev/input/event6 -- Device: Power Button Kernel: /dev/input/event1 -- Device: Lid Switch Kernel: /dev/input/event0 -- Device: USB 2.0 Camera: USB Camera Kernel: /dev/input/event13 -- Device: HDA Intel PCH Headphone Kernel: /dev/input/event10 -- Device: HDA Intel PCH HDMI/DP,pcm=3 Kernel: /dev/input/event11 -- Device: HDA Intel PCH HDMI/DP,pcm=7 Kernel: /dev/input/event12 -- Device: Logitech M185 Kernel: /dev/input/event5 -- Device: CD002 CD002 Kernel: /dev/input/event3 -- Device: AT Translated Set 2 keyboard Kernel: /dev/input/event2 -- Device: AlpsPS/2 ALPS GlidePoint Kernel: /dev/input/event4
So event4 it is in my case touch pad and event5 it is Logitech M185 mouse. In other words: those "libinput bug" log entries looks like are not related to emitting those short bursts of repeating keystrokes.
kloczek
On Wed, Jan 31, 2018 at 10:18:14PM +0000, Tomasz Kłoczko wrote:
On 31 January 2018 at 22:09, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote: [..]
Why I think that it may be related to libinput? Because in logs I see as well another type of entries:
# journalctl -xe | grep libinput Jan 31 21:55:18 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event5 debounce: offset negative (-354ms) Jan 31 21:55:18 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event5 debounce short: offset negative (-368ms) Jan 31 21:56:27 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event5 debounce: offset negative (-1107ms) Jan 31 21:56:27 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event5 debounce short: offset negative (-1120ms) Jan 31 22:05:12 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event4 keyboard: offset negative (-331ms) Jan 31 22:06:05 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event4 keyboard: offset negative (-750ms) Jan 31 22:06:05 domek org.gnome.Shell.desktop[2153]: libinput error: libinput bug: timer event4 keyboard: offset negative (-413ms)
timer offset bugs almost always mean that libinput_dispatch() isn't called quickly enough when its fd triggers. We rely on the compositor for that, so you can blame gnome shell here.
Internally, libinput uses event timestamps and uses them for timers (e.g. tap timer, debouncing, etc.). Let's assume an event happens, our timeout is 150ms but it takes 500ms after the event before calling libinput_dispatch(), the timer offset is now 350ms in the past - that's what libinput warns about.
It's not a killer but it does mean that whatever libinput was trying to do won't work correctly. In your case, the 'keyboard' timer is the one used in disable-while-typing. So expect that not to work correctly.
Also: the keyboard timer is 500ms, and you have a neg. offset of 750ms. This is a delay of 1250ms, that's crazy! Something's hogging gnome shell here and it doesn't get to handle input.
Correction:
# libinput list-devices | grep ^Device -A1 Device: Video Bus Kernel: /dev/input/event7 -- Device: Sony Vaio Jogdial Kernel: /dev/input/event9 -- Device: Sony Vaio Keys Kernel: /dev/input/event8 -- Device: Video Bus Kernel: /dev/input/event6 -- Device: Power Button Kernel: /dev/input/event1 -- Device: Lid Switch Kernel: /dev/input/event0 -- Device: USB 2.0 Camera: USB Camera Kernel: /dev/input/event13 -- Device: HDA Intel PCH Headphone Kernel: /dev/input/event10 -- Device: HDA Intel PCH HDMI/DP,pcm=3 Kernel: /dev/input/event11 -- Device: HDA Intel PCH HDMI/DP,pcm=7 Kernel: /dev/input/event12 -- Device: Logitech M185 Kernel: /dev/input/event5 -- Device: CD002 CD002 Kernel: /dev/input/event3 -- Device: AT Translated Set 2 keyboard Kernel: /dev/input/event2 -- Device: AlpsPS/2 ALPS GlidePoint Kernel: /dev/input/event4
So event4 it is in my case touch pad and event5 it is Logitech M185 mouse. In other words: those "libinput bug" log entries looks like are not related to emitting those short bursts of repeating keystrokes.
not directly, but they indicate where the issue is: key repeat is handled in the clients, not in libinput. With delays like this it's easy to see why you would get key repeat - if your key release event is delayed by 300ms or more the client will handle repeats before it gets the events.
But the real cause of the issue is that you're getting crazy delays because gnome-shell is too busy with something else. The rest is fallout from that.
Cheers, Peter
On 1 February 2018 at 01:42, Peter Hutterer peter.hutterer@who-t.net wrote: [..]
So event4 it is in my case touch pad and event5 it is Logitech M185
mouse.
In other words: those "libinput bug" log entries looks like are not
related
to emitting those short bursts of repeating keystrokes.
not directly, but they indicate where the issue is: key repeat is handled in the clients, not in libinput. With delays like this it's easy to see why you would get key repeat - if your key release event is delayed by 300ms or more the client will handle repeats before it gets the events.
But the real cause of the issue is that you're getting crazy delays because gnome-shell is too busy with something else. The rest is fallout from that.
So that is quite possible explanation and cause of those delays probably is in what I've already described. Every few second in kernel messages I have sequence:
[74330.405990] [drm] PCIE gen 2 link speeds already enabled [74330.417096] [drm] PCIE GART of 1024M enabled (table at 0x0000000000162000). [74330.417206] radeon 0000:01:00.0: WB enabled [74330.417212] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0x00000000d8c75981 [74330.417216] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0x000000001142ed24 [74330.417965] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0x00000000095357f2 [74330.434413] [drm] ring test on 0 succeeded in 2 usecs [74330.434428] [drm] ring test on 3 succeeded in 7 usecs [74330.611793] [drm] ring test on 5 succeeded in 2 usecs [74330.611809] [drm] UVD initialized successfully. [74330.611949] [drm] ib test on ring 0 succeeded in 0 usecs [74330.612118] [drm] ib test on ring 3 succeeded in 0 usecs [74331.267267] [drm] ib test on ring 5 succeeded [74340.515810] radeon 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [74340.515819] swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152 [74340.515827] CPU: 0 PID: 27342 Comm: kworker/0:1 Tainted: G W 4.15.0-0.rc9.git4.1.fc28.x86_64 #1 [74340.515832] Hardware name: Sony Corporation VPCSB2M9E/VAIO, BIOS R2087H4 06/15/2012 [74340.515841] Workqueue: pm pm_runtime_work [74340.515849] Call Trace: [74340.515862] dump_stack+0x85/0xbf [74340.515871] swiotlb_alloc_coherent+0xe0/0x150 [74340.515889] ttm_dma_pool_get_pages+0x21b/0x620 [ttm] [74340.515908] ttm_dma_populate+0x24d/0x340 [ttm] [74340.515923] ttm_bo_move_memcpy+0x185/0x610 [ttm] [74340.515933] ? lock_acquire+0x9f/0x200 [74340.515940] ? reservation_object_wait_timeout_rcu+0xb3/0x500 [74340.515987] radeon_bo_move+0x1a7/0x220 [radeon] [74340.516003] ttm_bo_handle_move_mem+0x2a4/0x5d0 [ttm] [74340.516021] ttm_bo_evict+0x186/0x370 [ttm] [74340.516046] ttm_mem_evict_first+0x174/0x1d0 [ttm] [74340.516060] ttm_bo_force_list_clean+0x6d/0x130 [ttm] [74340.516089] radeon_suspend_kms+0x11e/0x3e0 [radeon] [74340.516103] ? vga_switcheroo_runtime_resume+0x60/0x60 [74340.516126] radeon_pmops_runtime_suspend+0x54/0xc0 [radeon] [74340.516135] pci_pm_runtime_suspend+0x61/0x170 [74340.516144] vga_switcheroo_runtime_suspend+0x24/0xa0 [74340.516151] __rpm_callback+0xbc/0x1f0 [74340.516160] ? vga_switcheroo_runtime_resume+0x60/0x60 [74340.516168] rpm_callback+0x1f/0x70 [74340.516175] ? vga_switcheroo_runtime_resume+0x60/0x60 [74340.516181] rpm_suspend+0x12d/0x6e0 [74340.516195] pm_runtime_work+0x73/0xb0 [74340.516204] process_one_work+0x249/0x6b0 [74340.516219] worker_thread+0x3a/0x390 [74340.516229] ? process_one_work+0x6b0/0x6b0 [74340.516236] kthread+0x121/0x140 [74340.516243] ? kthread_create_worker_on_cpu+0x70/0x70 [74340.516253] ret_from_fork+0x3a/0x50
during which whole desktop is frozen for fraction of the second. During those freezes it is not possible even to move mouse cursor. Do you have idea what it may be?
# lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series] (rev ff)
kloczek
On Thu, Feb 1, 2018 at 12:13 PM, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On 1 February 2018 at 01:42, Peter Hutterer peter.hutterer@who-t.net wrote: [..]
So event4 it is in my case touch pad and event5 it is Logitech M185
mouse.
In other words: those "libinput bug" log entries looks like are not
related
to emitting those short bursts of repeating keystrokes.
not directly, but they indicate where the issue is: key repeat is handled in the clients, not in libinput. With delays like this it's easy to see why you would get key repeat - if your key release event is delayed by 300ms or more the client will handle repeats before it gets the events.
But the real cause of the issue is that you're getting crazy delays because gnome-shell is too busy with something else. The rest is fallout from that.
So that is quite possible explanation and cause of those delays probably is in what I've already described. Every few second in kernel messages I have sequence:
[74330.405990] [drm] PCIE gen 2 link speeds already enabled [74330.417096] [drm] PCIE GART of 1024M enabled (table at 0x0000000000162000). [74330.417206] radeon 0000:01:00.0: WB enabled [74330.417212] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0x00000000d8c75981 [74330.417216] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0x000000001142ed24 [74330.417965] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0x00000000095357f2 [74330.434413] [drm] ring test on 0 succeeded in 2 usecs [74330.434428] [drm] ring test on 3 succeeded in 7 usecs [74330.611793] [drm] ring test on 5 succeeded in 2 usecs [74330.611809] [drm] UVD initialized successfully. [74330.611949] [drm] ib test on ring 0 succeeded in 0 usecs [74330.612118] [drm] ib test on ring 3 succeeded in 0 usecs [74331.267267] [drm] ib test on ring 5 succeeded [74340.515810] radeon 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [74340.515819] swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152 [74340.515827] CPU: 0 PID: 27342 Comm: kworker/0:1 Tainted: G W 4.15.0-0.rc9.git4.1.fc28.x86_64 #1 [74340.515832] Hardware name: Sony Corporation VPCSB2M9E/VAIO, BIOS R2087H4 06/15/2012 [74340.515841] Workqueue: pm pm_runtime_work [74340.515849] Call Trace: [74340.515862] dump_stack+0x85/0xbf [74340.515871] swiotlb_alloc_coherent+0xe0/0x150 [74340.515889] ttm_dma_pool_get_pages+0x21b/0x620 [ttm] [74340.515908] ttm_dma_populate+0x24d/0x340 [ttm] [74340.515923] ttm_bo_move_memcpy+0x185/0x610 [ttm] [74340.515933] ? lock_acquire+0x9f/0x200 [74340.515940] ? reservation_object_wait_timeout_rcu+0xb3/0x500 [74340.515987] radeon_bo_move+0x1a7/0x220 [radeon] [74340.516003] ttm_bo_handle_move_mem+0x2a4/0x5d0 [ttm] [74340.516021] ttm_bo_evict+0x186/0x370 [ttm] [74340.516046] ttm_mem_evict_first+0x174/0x1d0 [ttm] [74340.516060] ttm_bo_force_list_clean+0x6d/0x130 [ttm] [74340.516089] radeon_suspend_kms+0x11e/0x3e0 [radeon] [74340.516103] ? vga_switcheroo_runtime_resume+0x60/0x60 [74340.516126] radeon_pmops_runtime_suspend+0x54/0xc0 [radeon] [74340.516135] pci_pm_runtime_suspend+0x61/0x170 [74340.516144] vga_switcheroo_runtime_suspend+0x24/0xa0 [74340.516151] __rpm_callback+0xbc/0x1f0 [74340.516160] ? vga_switcheroo_runtime_resume+0x60/0x60 [74340.516168] rpm_callback+0x1f/0x70 [74340.516175] ? vga_switcheroo_runtime_resume+0x60/0x60 [74340.516181] rpm_suspend+0x12d/0x6e0 [74340.516195] pm_runtime_work+0x73/0xb0 [74340.516204] process_one_work+0x249/0x6b0 [74340.516219] worker_thread+0x3a/0x390 [74340.516229] ? process_one_work+0x6b0/0x6b0 [74340.516236] kthread+0x121/0x140 [74340.516243] ? kthread_create_worker_on_cpu+0x70/0x70 [74340.516253] ret_from_fork+0x3a/0x50
during which whole desktop is frozen for fraction of the second. During those freezes it is not possible even to move mouse cursor. Do you have idea what it may be?
Try booting with radeon.runpm=0
Dave.
On Mon, 2018-01-22 at 08:26 -0700, Jerry James wrote:
One configuration that appears to be particularly unstable is a dual-monitor setup with nouveau. I experience frequent system hangs with that setup, and don't seem to be alone; e.g., https://bugzilla.redhat.com/show_bug.cgi?id=1491565.
On the other hand, I'm running Rawhide on a dual-monitor setup with "nouveau" and not hitting that at all. (Though it recently stopped being able to resume from suspend successfully).
Point being, 'nouveau' is insufficiently specific. The main graphics drivers these days support a huge range of hardware, and have very different codepaths depending on what your particular adapter is. So, you need to ensure that a report of this precisely identifies your hardware, and ideally includes at least a log from booting with 'drm.debug=14'.
And yeah, it doesn't sound like this is necessarily related to Wayland at all.
On 21 January 2018 at 14:42, Stephen John Smoogen smooge@gmail.com wrote:
On 21 January 2018 at 14:06, Howard Howell hlhowell@pacbell.net wrote:
On Sun, 2018-01-21 at 15:25 +0100, Igor Gnatenko wrote:
Folks, please move this discussion to users@lists.fedoraproject.org. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
HI, Igor, I posted here on purpose. Users cannot change the direction of Linux, only you guys, the developers, have that capability. I like the direction the discussion has taken. I want the group to think responsibily about the users. Not just the technology, because technology that is not useful on a widely distributed operating system is not beneficial to anyone.
Posting a diatribe to the devel list usually has the opposite effect than getting people to think about things.
I am apologizing to the readers of the list and to Les. My comments were not helpful and were rather hurtful in several parts. I was wrong to have compared the post to a drunk with a broken bottle.
On Mon, 2018-01-22 at 18:57 -0500, Stephen John Smoogen wrote:
On 21 January 2018 at 14:42, Stephen John Smoogen smooge@gmail.com wrote:
On 21 January 2018 at 14:06, Howard Howell hlhowell@pacbell.net wrote:
On Sun, 2018-01-21 at 15:25 +0100, Igor Gnatenko wrote:
Folks, please move this discussion to users@lists.fedoraproject .org. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject .org
HI, Igor, I posted here on purpose. Users cannot change the direction of Linux, only you guys, the developers, have that capability. I like the direction the discussion has taken. I want the group to think responsibily about the users. Not just the technology, because technology that is not useful on a widely distributed operating system is not beneficial to anyone.
Posting a diatribe to the devel list usually has the opposite effect than getting people to think about things.
I am apologizing to the readers of the list and to Les. My comments were not helpful and were rather hurtful in several parts. I was wrong to have compared the post to a drunk with a broken bottle.
No worries, Stephen, I have sometimes experienced hoof in mouth disease myself. Maybe this is kind of one of those times, for me, too. I just really really like Fedora. I have been with the system for a long time, at least since 5 or something like that. I cannot contribute much, but I do what I can.
Regards, Les H
On Sun, Jan 21, 2018 at 5:06 AM, Graham Leggett minfrin@sharp.fm wrote:
On 20 Jan 2018, at 8:24 PM, Alec Leamas leamas.alec@gmail.com wrote:
I'm sorry, but wyland is a disaster for me. I do work on lotsof different software platforms, and things are just not working well. They kind-of-work, which is the really worst condition one can have.
For me, this looks more like a support issue and as such doesn't not belong to this development list. I suggest that you:
I disagree, this looks like an overarching observation of interest to the development community. Anyone else seen this as a pattern?
Not really. There are no cited bug reports. The description lacks any specificity pointing toward a graphics driver problem vs a particular Wayland compositor problem vs a bug related to legacy applications interfacing with XWayland?
Now if you want to go down the rabbit hole of how tedious it is for users to file bugs...
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Alec Leamas -
Charalampos Stratakis -
Chris Murphy -
Christian Fredrik Schaller -
David Airlie -
Francesco Frassinelli -
Graham Leggett -
Howard Howell -
Igor Gnatenko -
Jared K. Smith -
Jerry James -
Jonathan Wakely -
Mathieu Bridon -
mcatanzaro＠gnome.org -
nicolas.mailhot＠laposte.net -
Olivier Fourdan -
Per Bothner -
Peter Hutterer -
Przemek Klosowski -
Samuel Sieb -
stan -
Stephen John Smoogen -
Tom Hughes -
Tomasz Kłoczko -
Tomasz Torcz 👁️