X logs me out abruptly

[Zucca]

Hmmm...

[jssilva]

[LIsLinuxIsSogood]

That sounds like a good idea.

Just some final thoughts to consider:
a) with many application or software related crashes...it is helpful to know more about the situation leading up to the incident, yes.
b) from the information you provided the most suspicious messages are not in X logs or the Vbox stuff but the information describing logging in and out...fixing sddm?? (Some other things for you to try would be bypassing sddm, to see if the problems persist).

I think given a bit of time as you said someone with a bit more knowledge of the authentication involved in user/root logins may be able to get you there much faster.

Good luck

EDIT: Another thing I think worth mentioning is that you are 100% in the right to be saying it, about the limited amount of time, but also seeing how you are trying to get the thing working and I may have actually been getting in the way more than anything I'm glad you will continue to hopefully receive help from someone else in this capacity because while I was purposefully misleading you (I assure that is true) that the solution could be a quicker one with someone else's advice than mine (and that I am very sure of)!

[jssilva]

[Zucca]

My guess why this happened is that for some reason elogind thought you were idling and then logging you out.
Some DEs override elogind settings... those that are in logind.conf. logind.conf basically stores the default settings and then your DE can apply its own over it.
To the point: I'd disable idle actions from the logind.conf and set that infamouns KillUserProcs to no.

This is just my guess.

The other guess I have is that the Apple hardware has some quirks that some component of your system reads wrong. Starting from Apple EFI "1.5"... which isn't even a standard.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

[jssilva]

Thank you for stepping in again.

Although I gave up trying to fix the issue systematically, and returned to my former distro for daily work, that doesn't mean I gave it up completely. As I said, I'll take a peek once in a while, mainly in the evening and lunch time. I just took a few days off because I was very frustrated and irritated about this issue. I guess I'm used to solve all the problems I lay my hands on, forgive the immodesty.

[Zucca]

[hceline]

I when you mentioned disabling the radon card, it got me thinking. I experienced the exact same symptoms when I forced the kernel to load i915.ko before radeon.ko while trying to debug an vaapi issue. I've never had X-crashes with no error-message anywhere before, but when I loaded i915.ko before radeon.ko (or had i915 built in and radeon as module) X crashed that way about 4 times a day.
Edit: I'm running X on the i915 and fbcon on radeon.

[Zucca]

I wonder if this need to be configured like Nvidia optimus setups...
On those setups the intel GPU is always the one that's outputting the signal to the screen. The more powerful Nvidia GPU only handles the rendering and sends the image (screen output) to the intel GPU which then does the actual interaction with the screen.

Unfortunately I have no experience on such setups. :(
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

[jssilva]

[jssilva]

Report:

The system had been working without crashes for a full day and then, just for test, I tried to suppress the KillUserProcesses=no that I had set. Another crash after a short time.

Set the KillUserProcesses=no as it was, and the sytem worked normally for a few days, making me very happy, I thought I made it. Suddenly, just a while ago, another crash.

So, this is enough for me. End-of-session.

[LIsLinuxIsSogood]

Hey jssilva, here's some more thoughts on the situation. Although not trying to make another lecture happen
The thing about other OS's is that yes while they are there to be able to work (for you the user), it isn't without its trade-offs that it works like this out of the box. You would be hard pressed to find a more efficient and customizable use of the linux kernel in a system overall, and for myself, having made the switch about 2 years ago from larger distro's of Red Hat and OpenSuse I first hand can tell you that my current system is so much more stable!!!

But that doesn't mean it is any easier to operate. Quite the opposite, it is takes some serious dedication so I don't want to mislead you about that. If you are willing to put up with the learning curve aspects, these are the suggestions for how you might proceed to diagnose a very big problem with no clear solution (someone else can correct any of this if they think it doesn't make sense to do it or alter it however you see fit):

Suggestion 1: Try at least 1 other login manager,

Suggestion 2: Go without a login manager using startx, xinit or just plain old X (make sure it is launched from an accountin which the user has access to the video group)

Suggestion 3: In general, be patient and keep using it just at night like you said until you find that the system (along with X) is in a more stable place. The thing tht is likely going to get you there the fastest is the help from this forum, but it doesn't happen automatically you will need to locate and provide the proper debugging information, or be able to ask the right questions to elicit the quickest response....

Suggestion 4: It may not be right away, or ever even with the particular Macbook that you're using, but when you've successfully implemented some of the steps to get past whatever basic trial of putting X to the test on your Gentoo linux machine, then it will be natural for that to lead you to take greater advantage of it for your other work too.

That's it from me, I hope you are able to bounce back from after this last blow! Just think of it this way, from a standpoint of essential functionality X is either very critical or not at all, since if you want a GUI/DE to be working it is 100% critical, but if you don't it is 0%. And then if you are looking for some interesting things to do while testing the stability of the graphics drivers with X, and the DM then I suggest finding out a bit more about the former, and leaving the latter out of the equation for now. Therefore, my rant is now changed, I'm no longer just anti polkit and anti consoleki, I'm actually anti Desktop environment. And I think the section of the forum could be removed. Jk, maybe just improved.

Remember, don't forget to try using startx to test instead of your login manager, which means removing xdm maybe for the time being from your list of services at boot time, and seeing if that could help.

[jssilva]

Thank you for your continued interest and helping will. I'm sincerely touched.

[LIsLinuxIsSogood]

[jssilva]

As I said, I gave up this matter, at least until a solid clue comes up of what's happening. And our conversations, that I praise, might eventually do that.

[Zucca]

If you ever find a fix for the problem here, please consider writing about the fix to the wiki article at https://wiki.gentoo.org/wiki/Macbook_Pro_(early_2011) .

(I don't remember the %<hex> -codes for (), so just copy-paste the url.)
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

[jssilva]

[Zucca]

[jssilva]

FYI, no problems over the weekend.

Back on-line today for real test, hopefully final.

[LIsLinuxIsSogood]

What DE is it again, and my experience with sddm (plasma's display/login manager) is just like everything in that DE it is difficult to manage without a keen sense of the ins and outs of the entire thing. Maybe a simpler login manager, would be a good cure for the problem at least for now.

can you show cat output to /etc/conf.d/xdm, if you already shared that earlier sorry about it.

[jssilva]

[jssilva]

During this week the system crashed 3 times with the usual symptoms, although on 2 of them it is justified (but not understood). In fact, in these two occasions, it happened about 5 minutes after booting with a modified xorg.conf where I replaced the intel driver with uxa acceleration, by the modesetting driver with glamor acceleration. And I think this is reproducible, but didn't test.

So, despite what I read advising the modesetting driver for SandyBridge chipsets and earlier, apparently it is incompatible with my setup.

So the single relevant crash of the week was unpredictable and silent as before. I had turned off bluetooth and thus concluded that the two messages about it just before the crash were consequences, not reasons. So, almost no logs at all except:

[Zucca]

Since the crashing happens at random, I'd set kernel log level to maximum and maybe install all the possible hardware logging tools, like mcelog. ... Just to rule out hardware problems.
(But did you mention earlier that you ran some other distro without problems?)

But first I need to address this:

[jssilva]

[jssilva]

Just to let you know that after one week, the system had no crashes and even no detected instabilities, hurraaa! and many thanks to all that jumped in to help.

Yesterday I could finally get rid of consolekit by re-emerging the dependent xfce4-power-manager with USE=systemd, imagine that, and the expected systemd truckload was not pulled in. If you feel curious, see https://forums.gentoo.org/viewtopic-t-1072936.html

Today, I also migrated the whole system to profile 17.0 desktop, recompiling everything, and I'm now planning to migrate gcc to v7.

EDIT: After some reading, I think it's better to stick to stable v6.4 until v7.2 is declared stable for amd64.

I guess that all these changes, if the system remains stable, will mask the main reason of the felt X crashes, but I don't mind if I can start trusting it.

Keep well, see you around Gentoo.