You are not logged in.
I've got a problem that's been making me tear my hair out for the past few days.
I've recently reinstalled Arch on my laptop, along with xorg and dwm (the latter which I've configured and compiled myself). Everything works fine, but sometimes (more often than not) when I exit X, the screen locks up and I have to power off the laptop manually. This often results in filesystem errors and nothing good.
I've tried modifying the files in xorg.conf.d, but I can't seem to stop it from happening. Does anyone have an idea of what to fix? Thanks.
I forgot to mention, xfce worked fine before, strangely.
EDIT: ...oddly enough, the problem only seems to happen after I open any sort of virtual terminal, be it st, rxvt, or a virtual console.
Last edited by TwosComplement (2013-07-22 17:58:42)
Offline
I have the same problem, only with an atom desktop, also using dwm. When I kill X the screen blanks and everything is unresponsive. Recent update to intel driver, mesa, or maybe dwm-git is to blame, but I don't know which.
Offline
I don't know how to solve your freezing problem, but you should check out the "Magic Sysrq" key. The basics of its usage are covered on the Keyboard Shortcuts wiki page. Basically, as long as your kernel is still repsonsive, this should still work.
Offline
I'll check that shortcut out, it could save me from nuking my Skype profile for the umpteenth time.
The strangest thing is, the problem only occurs after I start another terminal. I don't think it's bash, since my scripts (which use bash) cause no issues if I run them via dmenu. I tried removing my .bash* files, but it still happens. Something weird is going on for sure.
EDIT: Nope, as soon as X is killed, nothing works.
Last edited by TwosComplement (2013-07-23 18:50:57)
Offline
Try creating a new user and see if it continues to happen with a fresh $HOME.
Offline
I just want to confirm that my atom desktop problem is the same. If I don't open a terminal (st in this case) X closes cleanly. If I do, and afterwards kill X, everything freezes. Shortcut keys, nothing works. dmesg and Xorg.0.log don't show anything. Interesting we're both using dwm, but no one else is complaining.
Offline
I don't think this has anything to do with dwm. I think that is must be how something is configured in your systems. Skeerly, can you try creating a new user as well to test to see if the problem persists outside of your own regular user?
Offline
WonderWoofy: Yes it does, completely bare new user can quit X only if the terminal (st) is not opened. Otherwise freeze-up. Thanks for troubleshooting this. (I feel out of place on the laptop forum).
Offline
Okay, I figured it out. I had started background processes in .xinitrc like
skype&
Changing it to
exec skype&
worked.
I hope this helps you out, skeerly.
Offline
This wouldn't have any effect on a new user though. Skeerly is indicating that this happens even with a completely fresh user. So unless he copied the config that borked the stuffs to the new user, he shouldn't be getting it there as well.
@skeerly, a few questions. Does this happen with all terminals within X, or is it just certain terminals? Also, how do you start X in the first place? Do you use a DM or just a simple startx from the TTY (or some variant like autologin via your profile)?
Offline
Your solution points to .xinitrc but all I have in that file is a do loop that populates the status bar. I've had it for years. Nothing else is backgrounded. The new user has only exec dwm, but still the problem. Something upset X. I'll have to do more digging.
@wonderwoof: St is the only xterm I have. Maybe I'll try another. I start X with startx and kill it within dwm with Alt-Shf-q.
Last edited by skeerly (2013-07-24 01:59:20)
Offline
If you move to a TTY, and then issue a "pkill X" does it still lock up the TTY?
Offline
I can't open a TTY with Alt-F(n) or quit X with Ctl-backspace. Maybe I'm doing it wrong. I'm left with Alt-Shf-q and then having to unplug and boot.
Offline
To get to a TTY from X you have to use Ctrl+Atl+F(n). Once you are in the TTY, you can then just use Alt+F(n) or Alt+{Left,Right}.
Edit: BTW, if you are experiencing these problems, it might be wise to turn on the full functionality of the Magic Sysrq key. Just create a file in /etc/sysctl.d that will get parsed lexicographically before 50-default.conf and have it contain "kernel.sysrq=1". I just called the file 00-custom.conf so that I can drop in whatever I need there, and know that it will be before everything else.
Then once the full functionality of sysrq is enabled, use R, E, I, S, U, B (Reboot Even If System Utterly Broken).
Last edited by WonderWoofy (2013-07-24 02:23:12)
Offline
I got the TTY sequence straighted out. The result is the same: if I don't open the xterm the pkill command from TTY2 kills X. If I do, then it doesn't. I'll create the sysrq=1 command in sysctl.d in order to bail out until this gets fixed. Thanks for your help.
EDIT: I didn't mean to hijack this thread. I think I should open another one in a day or two when I'm better informed.
CONCLUSION: After experimenting I discovered that another xterm (lilyterm) doesn't cause the problem, and that I can get out of X cleanly if I launch my usual terminal (st) from dwm's dmenu instead of the Alt-Return keybinding. The key combination spawns
static const char *termcmd[] = { "st", "-f", font, NULL };
I don't know if this is a dwm bug. Maybe someone who knows dwm better could suggest a fix.
Last edited by skeerly (2013-07-24 13:24:53)
Offline
...Wow, you're right. I thought that changing .xinitrc helped, but it turns out that I did all of my testing by spawning terminals by dmenu rather than the shortcut. Spawning with the shortcut causes X to crash, but using dmenu works fine.
My termcmd looks looks like
static const char *termcmd[] { "st", NULL };
Changing it to xterm and using the keyboard combination does work. So it seems like a strange combination of st and dwm.
Sorry for my earlier mistake, but I didn't think this problem would be so... conditional.
EDIT: I should also mention that I'm using the tarball distribution of dwm 6.0 and not 6.1, and I'm using the git distribution of st.
Last edited by TwosComplement (2013-07-24 17:39:58)
Offline
Your code snippet is more up-to-date than mine. Suckless recently patched dwm to remove the font option. I recompiled dwm-git from AUR so it looks like yours now. But as we know it doesn't make any difference. I hope someone else who uses this combination can weigh in.
Offline
Actually, I removed the font option myself, but like you said... it doesn't really matter
Offline
@TwosComplement: Are you still having the problem? I am. Are we the only two? I can open multiple instances of st using dmenu or I can use another xterm, but that's not a solution. I want my shortcut back. I tried swapping the Return key in the shortcut for another key but that didn't help. I don't have an xorg.conf file and nothing out of the ordinary in /etc/X11/xorg.conf.d. I'm using uxa and graysky's ck-kernel for my atom processor and I patched dwm-git 6.1 from AUR with bstack-6.0. That's about it. All this was working perfectly until a week ago. Should I open another thread with a different title?
Offline
Yeah, that sounds best. I really didn't have any idea of what the problem was when I made this thread, but now that we kinda know, it makes sense to make a more accurate thread for this since it's probably not specific to laptops.
Offline
Precisely the same issue here with DWM and ST not playing nicely together. Problem disappears if I use UXterm or URXVT instead of ST but it's more of a workaround than a solution. Don't suppose either of you managed to solve this, did you?
Last edited by CH2IS (2013-08-01 16:45:48)
Offline
I brought it up on the suckless mailing list. Several others confirmed it. I think the suckless devs are working on it but no fix yet as far as I know.
Offline
Hello,
I was looking into the last few commits of st since 0.4.1 and found that the problem (at least for my system) lies in this commit:
http://git.suckless.org/st/commit/?id=f … 7ab5d0ea69
I've reported this to the suckless mailing list you can read here (read the whole thread):
http://lists.suckless.org/dev/1311/18359.html
Maybe you can try st without this commit and see if it works (it does for me).
Greets
A
Last edited by andmars (2013-11-27 05:33:19)
Offline