tty1 strange behavior

aditnsr · 2009-08-14 07:32:58

Hi all,
I just noticed that in tty1, sometimes the key press gets ignored.
For example, if I type 'pacman', it shows something like

$pca
or
$pcm
or
$amn
or sometimes it correctly shows
$pacman

Only in tty1, others (tty2-tty6) are fine.
Does anyone else experience this?
Not a showstopper, but I find this strange and a little annoying.

Allan · 2009-08-14 07:37:04

I have experienced this too, but I never bothered to try and fix it...

nictki · 2009-08-14 12:28:32

dirty hack: hashing dbus section in .xinitrc solved that issue, at least for me

# D-bus
#if which dbus-launch >/dev/null && test -z "$DBUS_SESSION_BUS_ADDRESS"; then
#    eval `dbus-launch --sh-syntax --exit-with-session`
#fi

pyropeter · 2009-10-20 06:57:19

I have a similar Problem on tty3:

08:49 < PyroPeter> when I type in my third virtual terminal, about half of my
keypresses get ignored. the problem occours only on tty3, I
had this two times now. It may be that It only occours after
very high memory usage or high system load (I built a tool
yesterday that accidentially used about 4 Gb of ram, so I
used tty3 to kill it as root, now it has this problems)

the problem persists after re-login

Last edited by pyropeter (2009-10-20 06:58:47)

evilgnome · 2009-12-01 02:40:09

I've had this exact problem (tty1 only, consistently) for a while, it's kind of driving me crazy. The dbus workaround hasn't helped.

Maybe there's a pattern we can find.
Is anyone else here using xf86-video-intel, with i915 or intel_agp modules?
Also, I use no xorg.conf and no login manager. My .xinitrc is just "exec ck-launch-session gnome-session" and my /etc/inittab, sans comment-cruft, is as follows:

id:5:initdefault:

rc::sysinit:/etc/rc.sysinit
rs:S1:once:/etc/rc.single
rm:2345:once:/etc/rc.multi
rh:06:once:/etc/rc.shutdown
su:S:once:/sbin/sulogin -p

c1:2345:respawn:/sbin/agetty -8 -i 38400 tty1 linux
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

x:5:once:/bin/su evilgnome -l -c "/bin/bash -l -c startx >/dev/null 2>&1"

See anything familiar here?

tty1 is distinguished by the -i argument, but I can't see how that could cause this problem.

Allan · 2009-12-01 02:57:07

evilgnome wrote:

xf86-video-intel, with i915

me.

tty1 is distinguished by the -i argument, but I can't see how that could cause this problem.

No "-i" argument for me so confirmed that is not the source.

sparky · 2009-12-20 21:07:03

I second this, seeing the same thing on tty1 only (or so it appears). Also using xf86-video-intel and i915. Have not found a fix...

vonkemp · 2009-12-25 11:14:27

I had the same problem after installing the slim login manager.

http://developer.berlios.de/bugs/?func= … up_id=2663

chpln · 2009-12-25 11:42:31

I haven't came across this issue, so I'll see if I can help rule some things out.

Video device:

% lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

Running with testing and community-testing enabled with everything currently up-to-date except xf86-video-intel (using 2.9.1-1). Stock kernel26 with KMS enabled (kernel defaults).

dbus-launch and dbus-daemon are running, though not invoked through .xinitrc:

% pgrep pgrep dbus-(launch|daemon)
3821
18861
18862

Using xf86-video-intel with i915 and intel_agp modules loaded:

% grep -iE "^\([EWI]{2}\) LoadModule:" /var/log/Xorg.0.log
(II) LoadModule: "extmod"
(II) LoadModule: "dbe"
(II) LoadModule: "glx"
(II) LoadModule: "dri"
(II) LoadModule: "dri2"
(II) LoadModule: "intel"
(II) LoadModule: "fb"
(II) LoadModule: "evdev"
(II) LoadModule: "synaptics"
% lsmod | grep -E "^i915|intel_agp"
i915                  292671  2 
intel_agp              26685  1

I have an /etc/X11/xorg.conf, though it is fairly brief (used only to configure output for multiple displays).

No login manager. Boot into runlevel 3 and log in to tty1; xinit is then invoked via my .zshrc. .xinitrc adjusts the keymap, sets the wallpaper, invokes xmobar and xmonad.

EDIT:

vonkemp wrote:

http://developer.berlios.de/bugs/?func= … up_id=2663

The theory in this link is interesting, specifically:

maokt wrote:

The problem is that slim is still reading from the starting tty; it should close that when it becomes a daemon.

I wonder whether others' problems are being caused by different programs with the same behaviour.

Last edited by chpln (2009-12-25 11:53:15)

sparky · 2009-12-25 15:41:25

vonkemp wrote:

I had the same problem after installing the slim login manager.
http://developer.berlios.de/bugs/?func= … up_id=2663

Doh! I suppose I should have suspected the login manager as well. I'm also running slim.

I can confirm on my system that this behavior seems to be tied to slim, but only if I use /etc/inittab to start it.

My /etc/inittab has this line:

x:5:respawn:/usr/bin/slim >& /dev/null

And my default entry in grub to boot contains:

kernel /vmlinuz26 root=/dev/mapper/vgroup-root ro 5 vga=792

Together, these bring me to a nice graphical login at boot.

I did two tests on my system... The first was to drop to init 3 (stop slim) via tty2, and then ran startx to bring me back into X. Switching to tty1 seemed to show that I was no longer missing keystrokes. After that, I logged out of X, and back in tty2 I issued a `init 5`. After logging in through slim, tty2 was now missing keystrokes. Seems to be following the tty that switches to runlevel 5.

For the second test, I rebooted into runlevel 3 and started the slim daemon manually from tty1: `sudo /etc/rc.d/slim start`. When launched this way, none of my tty's seem to be missing any keystrokes, including tty1.

This seems to confirm what was stated in the link above, which seems to be a bug within slim.

If nothing else, for those that really want tty1 to behave properly, you could start slim from the DAEMONS array until this is fixed upstream. Ugly, but it'll work.

EDIT:
Actually, I may have spoken too soon, it just took a little while and tty1 began missing keystrokes after starting slim using: `sudo /etc/rc.d/slim start`. So...maybe starting from DAEMONS won't fix it after all. Sorry...

Last edited by sparky (2009-12-25 15:48:05)

made_in_nz · 2010-01-05 08:44:25

If nothing else, for those that really want tty1 to behave properly, you could start slim from the DAEMONS array until this is fixed upstream. Ugly, but it'll work. smile
EDIT:
Actually, I may have spoken too soon, it just took a little while and tty1 began missing keystrokes after starting slim using: `sudo /etc/rc.d/slim start`. So...maybe starting from DAEMONS won't fix it after all. Sorry...

i second that. I also have the same problem. I run xf86-video-intel with i915 and intel_agp modules loaded, start slim from the DAEMONS array and experience lost keystrokes on tty1 (not on tty3). Ironically i just switched to slim yesterday as the latest gdm was causing my system to freeze.

makimaki · 2010-01-05 13:02:38

I don't think it's related to slim. I don't have it installed, I boot from runlevel 3, autologin to X and I have the same problem. If I don't start X at all (passing runlevel 4 at boot, x doesn't start in my config) the I have no problem.

inittab

...
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux
c3:2345:respawn:/sbin/agetty -8 38400 tty3 linux
x:235:respawn:/bin/su peter -l -c "/bin/bash --login -c xinit >/dev/null 2>&1"
...

I use the 2.6.32-ck kernel, i915 driver built into the kernel (early start kms) and xf86-video-intel-newest on my NC10 (it's the 945GME).

I've never had this problem with my work or home pcs, one has an ati card the other an nvidia. Perhaps this is an intel related problem?

Edit:spelling

Last edited by makimaki (2010-01-05 13:06:31)

makimaki · 2010-01-05 13:09:25

From vonkemp's link

I guess the problem lies when you try to redirect the output from the starting script, ie
/usr/bin/slim -d >/dev/null 2>&1
I suggest to modify your init scripts until we find some additional info / fix

That would explain my problem...

x:235:respawn:/bin/su peter -l -c "/bin/bash --login -c xinit >/dev/null 2>&1"

Last edited by makimaki (2010-01-05 13:14:44)

makimaki · 2010-01-05 13:20:53

And here is a patch for slim if anyone wants to try it

ulukai · 2010-01-20 10:08:11

makimaki wrote:

And here is a patch for slim if anyone wants to try it

Having the same issue here too, can someone explain me how I can test this patch? The whole patching thing is still new to me...
I hope it gets implemented in a future version.

jdarnold · 2010-01-20 13:53:11

Why not just use a different tty for now?

ulukai · 2010-01-20 19:43:12

jdarnold wrote:

Why not just use a different tty for now?

Sure, that's not a problem. But by building the patch and trying it out, we can provide feedback upstream and see whether or not it causes other problems.
It's a way to make sure everything works as to be expected and to get it faster in a new version. The problem is already more than a year old you know...

pirateofms · 2010-12-09 20:21:36

I tried the patch, ended up just breaking my slim. After just poking at it for a while, I came up with:

x:5:once:/usr/bin/slim -d

in my inittab. Seems to have fixed it for the time being.

Arch Linux

#1 2009-08-14 07:32:58

tty1 strange behavior

#2 2009-08-14 07:37:04

Re: tty1 strange behavior

#3 2009-08-14 12:28:32

Re: tty1 strange behavior

#4 2009-10-20 06:57:19

Re: tty1 strange behavior

#5 2009-12-01 02:40:09

Re: tty1 strange behavior

#6 2009-12-01 02:57:07

Re: tty1 strange behavior

#7 2009-12-20 21:07:03

Re: tty1 strange behavior

#8 2009-12-25 11:14:27

Re: tty1 strange behavior

#9 2009-12-25 11:42:31

Re: tty1 strange behavior

#10 2009-12-25 15:41:25

Re: tty1 strange behavior

#11 2010-01-05 08:44:25

Re: tty1 strange behavior

#12 2010-01-05 13:02:38

Re: tty1 strange behavior

#13 2010-01-05 13:09:25

Re: tty1 strange behavior

#14 2010-01-05 13:20:53

Re: tty1 strange behavior

#15 2010-01-20 10:08:11

Re: tty1 strange behavior

#16 2010-01-20 13:53:11

Re: tty1 strange behavior

#17 2010-01-20 19:43:12

Re: tty1 strange behavior

#18 2010-12-09 20:21:36

Re: tty1 strange behavior

Board footer