keyboard sometimes doesn't respond at login

[diehard67]

I have tried diferant display managers (kdm nd lightdm) both are effected sometims whn my sister turns on her netbook she can't type in her password untill she puts th cmpute to sleep and wakes it up again, this seems to be randome, from what I have been able to fine from googling all over the place plymouth is to blame for this, seems to be if it is still running when whateverdm starts you will not bable to type.

on my own laptop I have had the same problem and was able to fix it by adding a sleep 2 before exec lightdm in /etc/init/lightdm.conf

my sisters netbook needed more then that, he delay got to 6 seconds long and still wasn't reliable, I had to modify /etc/default/grub to ass text after splash then put service lightdm restart in rc.local so she could login most of the time.

she has had the problem in 14.04 and now in 14.10, I have had it sense 13.04

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: xorg 1:7.7+7ubuntu2
ProcVersionSignature: Ubuntu 3.16.0-23.31-generic 3.16.4
Uname: Linux 3.16.0-23-generic i686
ApportVersion: 2.14.7-0ubuntu8
Architecture: i386
CurrentDesktop: KDE
Date: Fri Oct 24 01:43:10 2014
InstallationDate: Installed on 2014-04-30 (176 days ago)
InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release i386 (20140416.1)
SourcePackage: xorg
Symptom: display
UpgradeStatus: Upgraded to utopic on 2014-10-24 (0 days ago)

[Steve Langasek (vorlon)]

> from what I have been able to fine from googling all over the place
> plymouth is to blame for this, seems to be if it is still running when
> whateverdm starts you will not bable to type.

plymouth and the DM do not run at the same time. The upstart jobs are carefully structured to ensure that plymouth is always stopped before the DM is started. This bug is unreproducible for the vast majority of users, and I don't know what information to ask you for to try to debug this. Do you have any modified upstart jobs under /etc/init, or have you removed any job files from this system?

[diehard67 (diehard67)]

the only changes were to work around this, adding sleep 2 before exec lightdm in /etc/init/lightdm.conf

I know lightdm.conf calls plymouth quit before running lightdm itself but I suspect it is not done quitting when lightdm starts running.

like I said if I tell the kernel to give a text login and start lightdm later in the boot process in rc.local the keyboard works almost every time.

truth be told I have no idea what to look at or how to get more info, if there some way to get plymouth, lightdm, x and the kernel to give me detailed logs during boot?????

I should also mention my sisters netbook is not a particularly fast system
asus eeepc x101ch

1 gb of ram
intel atom n2600 at 1.6 ghz
dual core with hyperthreading

snipit of /etc/default/grub
GRUB_DEFAULT=4
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash text"
GRUB_CMDLINE_LINUX="i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.semaphores=1"

rc.local
#!/bin/sh
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

hdparm -W0 /dev/sd?

/etc/acpi/lid.sh

killall plymouthd

service lightdm restart

exit 0

the upgrade to 14.10 put lightdm.conf back the way it was

[Steve Langasek (vorlon)]

On Sat, Oct 25, 2014 at 01:01:17AM -0000, diehard67 wrote:
> the only changes were to work around this, adding sleep 2 before exec
> lightdm in /etc/init/lightdm.conf

> I know lightdm.conf calls plymouth quit before running lightdm itself

Except that it doesn't do that at all. It only calls 'plymouth quit'
explicitly when either 'text' has been passed on the kernel commandline (an
option that's used to suppress the graphical login and give users a text
login only), or if the target runlevel for the system is single user mode
(and I'm not sure why it does this at all, that may be a bug).

> but I suspect it is not done quitting when lightdm starts running.

And that's fine, because what lightdm does is call 'plymouth quit
--retain-splash' internally before it launches the X server. This should
work reliably unless there is something causing plymouth to be started only
/after/ lightdm gets to this point.

> truth be told I have no idea what to look at or how to get more info, if
> there some way to get plymouth, lightdm, x and the kernel to give me
> detailed logs during boot?????

You can get debugging logs out of plymouth by booting with
<plymouth:debug=file:/var/log/plymouth-debug.log>. X and lightdm logs are
already available under /var/log/lightdm, and the kernel log is at
/var/log/kern.log.

It would indeed be helpful if you could attach these logs corresponding to a
boot that exhibited the problem.

> I should also mention my sisters netbook is not a particularly fast system
> asus eeepc x101ch

Machine specifications should not matter here, except to the extent that a
slower machine will have a bigger window in which a race can happen.

> GRUB_CMDLINE_LINUX="i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.semaphores=1"

However, I wonder about this. This is an awful lot of module options
overriding the default behavior of the graphics card; I can certainly see
this triggering bugs in the plymouth/lightdm hand-off. Do you know why
these options are here? What happens when booting without these options?

> rc.local
> #!/bin/sh
[...]
> killall plymouthd

This certainly concerns me. Was this added *only* to work around the lack
of keyboard in the greeter? That's certainly not the expected way to shut
down plymouthd, and using 'killall' to end the process definitely *does*
have a race because signals are asynchronous. At minimum, you should be
using 'service plymouth stop' to ensure plymouth is actually stopped before
you then try to start lightdm...

[diehard67 (diehard67)]

I got logs from good and bad boots under different configurations.

I have a bad boot with all my hacks in place
a bad one with all my hacks disabled and debug logging for plymouth
the same after putting the computer to sleep and waking it up again.
and a good boot strangely this was under default debug configuration

and the i915 stuff is to tune the gpu for better performance and power efficiency, I don't think it had any effect as I still had the problem after removing them.

unfortunate I don't think those logs are gonna be much help, is there a way to get lightdm and x to be more detailed in there logs or to get log entries somewhere when process start and stop, that is when executives are run and when they die in order.

is there a way to get information on the input devices from a command line, I can ssh in after booting so if I could see the state of the keyboard from the system it might shed some light or maybe a way to work around it.

I know if I plug in an external keyboard it works but the internal one doesn't till the computer is put to sleep and woke back up again, I loged in with a usb keyboard once, thought the internal one might start working once the computer was loged in but nope, didn't work.

[Launchpad Janitor (janitor)]

[Expired for plymouth (Ubuntu) because there has been no activity for 60 days.]