Switching between X and virtual terminals results in crash in Slackware 14.2
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have another partition on the Dell that is basically a duplicate of the partition that I now have 14.2 on. The other partition has 14.1, and I can switch between virtual screens with no problem. I noticed that I get the same messages in the Xorg log about creating /dev/dri/card0 (both udev and xfree are trying to create or access it), and almost the same message about drm not being initialized. So I began to think that there might be some other problem. I noticed that I did not have the X modesetting driver in 14.1 (separate file), but it is in 14.2 (as part of xorg-server). So I loaded the modesetting file into 14.1, but was still able to switch with no problems. I disabled modesetting in 14.2 (renamed the driver and made it non-executable), but still have the switching problem. I am out of ideas at this point. It seems the only solution is to start X, exit and then restart it. I'm going to put 14.2 on my other computer with an Intel graphics chip (G41 instead of 845G) and see what happens.
It looks like only xfree try to set up /dev/dri/card0, but udev didn't. It appears that you went back and forth several times between X and a virtual screen, if I'm reading the AIGLX statements correctly. When did the crash occur?
Distribution: Slackware64 15.0 (started with 13.37). Testing -current in a spare partition.
Posts: 928
Rep:
Now that you mentioned, I remember that the crash was after I switched to a screen without any X session running,
for example crtl-alt-f8 then f1, f7,f1 and then crash.
Distribution: Slackware64 15.0 (started with 13.37). Testing -current in a spare partition.
Posts: 928
Rep:
I installed 14.1 in a spare partition to test it, because I remember that this
problem didn't happen in 14.1.
I'm posting this from 14.1 installed and tested right out of the box, and
all is ok. I'm switching like a mad man from ctrl-alt-f1 to f12 without any problem,
with one X session, with two, without any problem.
Then updated a massive 2 1/2 years (didn't remember that 14.1 had a kernel update, but with same version)
of upgrades bringing it to 14.1 up to date, and I can copy and paste my report above:
"all is ok. I'm switching like a mad man from ctrl-alt-f1 to f12 without any problem,
with one X session, with two, without any problem."
I think this is strange because 'up to date 14.1' is practically the same as 14.2, so I think
it should crash as well.
That does seem strange. Well, I backtracked X somewhat to the 14.1 version. That is, I removed the 14.2 versions of xorg-server, xf86-video-intel, ..v4l, ..vesa, and xf86-input-evdev, and replaced them with the 14.1 versions (I also had to make a symlink to a libnettle version). So far I have rebooted once and been able to switch between X and virtual terminals as before (NO problems). I'm going to reboot again, and if OK I will upgrade my main computer to 14.2 to see what happens.
I'm thinking right now that the problem is somewhere in xorg-server, the intel driver or the evdev driver. I'll post again after upgrading the main computer. Can you check to see if the versions of the 3 files mentioned that work for you are the same as in the official 14.2?
Distribution: Slackware64 15.0 (started with 13.37). Testing -current in a spare partition.
Posts: 928
Rep:
Quote:
Originally Posted by kevjamsis
..I'm thinking right now that the problem is somewhere in xorg-server, the intel driver or the evdev driver. I'll post again after upgrading the main computer. Can you check to see if the versions of the 3 files mentioned that work for you are the same as in the official 14.2?
Don't know if I understood correctly, if these are the files you asked.
Files from /var/log/packages are from 14.2 up to date. From /mnt/zip/... are from 14.1 up to date.
Code:
# ls /var/log/packages/*xorg-server*
/var/log/packages/xorg-server-1.18.3-x86_64-2
/var/log/packages/xorg-server-xephyr-1.18.3-x86_64-2
/var/log/packages/xorg-server-xnest-1.18.3-x86_64-2
/var/log/packages/xorg-server-xvfb-1.18.3-x86_64-2
# ls /var/log/packages/*intel*
/var/log/packages/intel-gpu-tools-1.9-x86_64-2
/var/log/packages/libva-intel-driver-1.6.2-x86_64-1
/var/log/packages/libva-intel-driver-compat32-1.6.2-x86_64-1compat32
/var/log/packages/xf86-video-intel-git_20160601_b617f80-x86_64-1
# ls /var/log/packages/*evdev*
/var/log/packages/libevdev-1.4.1-x86_64-1
/var/log/packages/xf86-input-evdev-2.10.3-x86_64-1
# ls /mnt/zip/var/log/packages/*xorg-server*
/mnt/zip/var/log/packages/xorg-server-1.14.3-x86_64-3_slack14.1
/mnt/zip/var/log/packages/xorg-server-xephyr-1.14.3-x86_64-3_slack14.1
/mnt/zip/var/log/packages/xorg-server-xnest-1.14.3-x86_64-3_slack14.1
/mnt/zip/var/log/packages/xorg-server-xvfb-1.14.3-x86_64-3_slack14.1
# ls /mnt/zip/var/log/packages/*intel*
/mnt/zip/var/log/packages/intel-gpu-tools-1.3-x86_64-1
/mnt/zip/var/log/packages/xf86-video-intel-2.21.15-x86_64-1
# ls /mnt/zip/var/log/packages/*evdev*
/mnt/zip/var/log/packages/xf86-input-evdev-2.8.2-x86_64-1
There is an intel compat32 package due to multilib in my 14.2 installation.
I will uninstall it and reboot to see what happens.
I upgraded my main computer from 14.1 to 14.2, with the exception of the X software (kept that as it was). I had no problems switching between X and a virtual terminal. Then I upgraded the X software to what is included in 14.2, and the switching problem started happening. Then I replaced 3 files from 14.2 with their counterparts from 14.1: xorg-server-1.14.3-i486-2, xf86-video-intel-2.21.15-i486-1, and xf86-input-evdev-2.8.2-i486-1. I have rebooted several times and have not had the switching problem using the 3 above files. This is the same behavior as I have on the Dell, so I am assuming the problem is in one or more of these 3 files that came with 14.2 : xorg-server-1.18.3-i586-2, xf86-input-evdev-2.10.3-i586-1, and xf86-video-intel-git_20160601_b617f80-i586-1.
Do your self a favor create another user and test it.
Second as root go to run level 3 and run
rm -rf /tmp/* this deletes all the files in temp and or a stale socket that is not being deleted at
restart.
then run reboot
lets find out if we have a stale file left over from a update that is what the second step does.
first step finds out if you have a permission problem with that users .Xauthority
give it a shot.
Distribution: Slackware64 15.0 (started with 13.37). Testing -current in a spare partition.
Posts: 928
Rep:
Quote:
Originally Posted by Drakeo
Do your self a favor create another user and test it.
Hi Drakeo, thanks for your ideas.
I have two users and did a test with them logged in and with X sessions running.
The crash seems to happen switching to a X screen without X running and trying to
go back to crtl-alt-f1 or another. I don't have other video chipset to test, but
it seems that only Intel is affected.
The crash doesn't happen on 14.1 for sure.
Quote:
Originally Posted by Drakeo
Second as root go to run level 3 and run
rm -rf /tmp/* this deletes all the files in temp and or a stale socket that is not being deleted at
restart.
My rc.local_shutdown deletes everything inside /tmp since 2013/2014 IIRC
(ps- rm -rf /tmp/* won't remove dot files/dirs)
Quote:
Originally Posted by Drakeo
first step finds out if you have a permission problem with that users .Xauthority
give it a shot.
Is there any side effect if I delete .Xauthority file(s) from a user? I will try this in my -current install,
since there is no important personal data over there, is just to test.
The problem affects the -current install too (up to date with new xorg).
Drakeo: I have run as root several times (no .Xauthority) on both computers and still had the switching problem until I changed back to the 3 files from 14.1. I have also cleaned out the /tmp directory at least once - no effect on the switching problem. The only thing that has worked so far is swapping out the 3 files.
My /tmp is mounted on tmpfs and is wiped clean each time I reboot. I am able to reproduce after I return from hibernation/suspend to disk. I cannot reproduce after a sleep/suspend to ram. Occasionally I find a black screen when I try to unlock the screen (using xlock). I do not see this issue on a normal reboot or power on of the system. This happens on my ZaReason Strata 7440 which has intel graphics.
I did not notice this issue until I did a fresh installation of 14.2 on this system, which previously had been running -current for months before the stable release. My .xsession-errors or Xorg.log report no errors, so I doubt it is related to KDE or Fluxbox.
EDIT: I failed to mention I am running a 4.4.15 kernel. It looks like a 4.4.16 kernel source is available on kernel.org with a number if i915 module changes, so I will be trying that out.
Here is my video card:
Code:
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. [MSI] 4th Gen Core Processor Integrated Graphics Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 31
Region 0: Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=64]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00018 Data: 0000
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915
Kernel modules: i915
I patched the Slackware 4.4.14 kernel source to 4.4.16 and used Pat's kernel config. I can switch between virtual terminals and Xorg just fine after a kernel recompile. pm-hibernate, pm-suspend, and normal vt switching all seems to work.
Distribution: Slackware64 15.0 (started with 13.37). Testing -current in a spare partition.
Posts: 928
Rep:
Quote:
Originally Posted by mralk3
I patched the Slackware 4.4.14 kernel source to 4.4.16 and used Pat's kernel config. I can switch between virtual terminals and Xorg just fine after a kernel recompile. pm-hibernate, pm-suspend, and normal vt switching all seems to work.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.