Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Rytz]

Hi:

> Vector Linux Light 7.0 Minimal Install + JWM
> PS2 Keyboard and Mouse

I have been banging my head on this for a couple days now.  The keyboard works fine within the BIOS and LILO.

When the Linux kernel begins to load, the keyboard is always disabled up until a certain point in the boot process, where X or evdev or udev load it (correct me here).  The following is a snippet from my DMESG on a working boot:

[    5.354741] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    5.359760] serio: i8042 KBD port at 0x60,0x64 irq 1
[    5.364404] serio: i8042 AUX port at 0x60,0x64 irq 12
[    5.369211] mousedev: PS/2 mouse device common for all mice
[    5.373936] md: linear personality registered for level -1
[    5.378531] md: raid0 personality registered for level 0
[    5.383109] md: raid1 personality registered for level 1
[    5.387586] md: raid10 personality registered for level 10
[    5.392005] md: raid6 personality registered for level 6
[    5.396416] md: raid5 personality registered for level 5
[    5.400692] md: raid4 personality registered for level 4
[    5.404888] md: multipath personality registered for level -4
[    5.407461] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0

From Xorg.0 log:

[    19.816] (II) config/udev: Adding input device AT Translated Set 2 keyboard (/dev/input/event0)
[    19.816] (**) AT Translated Set 2 keyboard: Applying InputClass "evdev keyboard catchall"
[    19.816] (**) AT Translated Set 2 keyboard: Applying InputClass "keyboard-all"
[    19.816] (**) AT Translated Set 2 keyboard: Applying InputClass "keyboard-all"
[    19.816] (**) AT Translated Set 2 keyboard: always reports core events
[    19.816] (**) AT Translated Set 2 keyboard: Device: "/dev/input/event0"
[    19.817] (--) AT Translated Set 2 keyboard: Found keys
[    19.817] (II) AT Translated Set 2 keyboard: Configuring as keyboard
[    19.817] (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD)
[    19.817] (**) Option "xkb_rules" "evdev"
[    19.817] (**) Option "xkb_model" "pc104"
[    19.817] (**) Option "xkb_layout" "us"
[    19.817] (**) Option "xkb_options" "terminate:ctrl_alt_bksp"

(when diffing good and bad logs, both show about the same information with some variation in time and order)

Most times, the keyboard becomes usable again right about the time this happens in the boot process.  However, less often, the keyboard does not become usable again.  The keyboard stays disabled through the remainder of the boot process.  The only way I can get the keyboard working again is be reconnecting it physically (works without a reboot) or by forcing a shutdown via the power button and rebooting.

Things I have tried in order to fix the problem:
> Recompiling xserver and udev using both source compilation and slackware packages.
> Passing commands to the kernel to disable ACPI and APIC.
> Using a xorg.conf and not a xorg.conf
> Disable HAL via xorg settings.
> Complete reinstalls of VL Light Minimal.

As a side-note I have used a Vector Linux Light full install on this machine (xfce I think?) and never had this problem or any other problems with input devices (PS2 or USB).

I've attached both "working" and "bad" copies of DMESG and XORG logs for reference.

I appreciate any help or suggestions someone can offer.

Thanks!

[Rytz]

I just tried reinstalling evdev from package and source.  Didn't fix the problem either.

[Rytz]

Building and re-installing libX11-1.4.3 from source (link) seems to have fixed the problem.  I've rebooted about twenty times and haven't had the issue yet.  I tried the slackware binary package first but it didn't help.

I did remove the existing X11 package (libX11-1.4.3-i486-2) with removepkg before installing the source package.

I'll mark this resolved and re-open if I have the problem again.

[Rytz]

Turns out the fix requires a bit more than just "libX11".  I did a full re-install of VL Light 7.0 Minimal and needed to remove and rebuild/install all of the following libs from source to fix the keyboard issue:
> xinput
> xf86-input-evdev
> libX11

[Rytz]

This is still occurring but I don't have any further information as to why.  I have tried so many different fixes I lost track.

What I know so far:

> VLL "Full Install" on another drive works without any problems.
> Both the Keyboard & Mouse will randomly not work (together or separate).  I didn't know about the mouse at the time because I wasn't running the window manager (JWM).
> The keyboard will always show up in DMESG logging (even if it's not working) but when the mouse doesn't show up when it doesn't work.

The kernel in all versions of VL Light appear to be the same.  I would assume its the same build with same options when it was built?

What I have done for more elimination of possibilities is add "init=/bin/bash" to LILO so that I can get to the command-line ASAP without loading anything extra (on both drives).  I still have a random non-working keyboard on some boots, even with "init=/bin/bash".  Comparing Xorg.0.log and dmesg output between the working drive (with full installation) and the drive with minimal JWM install, I'm not seeing much difference or anything that stands out.  The diffs are almost identical, save for some monitor / video related entries.

What are the major differences between the VLL full and minimal installs?  Any kernel changes?  Boot changes?  I have diffed the list of installed packages between installations and the only somewhat relevant package seems to be the HAL package, which doesn't run on the working machine, so that rules out HAL.  Running processes appear to be the same (when going straight to text interface/command line).  lsmod diffs show the same modules, save for the full install (working) drive listing FUSE.

Any help appreciated.

Thanks.

[nightflier]

Hate to see you struggle and not knowing how to help. Yes, the kernel is the same in all 4 install choices. The differences are in the working environment. The two lighter ones do not install HAL or gvfs. If you look in the install CD you'll see three directories: option1, option2 and option3. These are the packages for Light, Medium and Full. Remember that Full includes Medium.

[Rytz]

Hate to see you struggle and not knowing how to help. Yes, the kernel is the same in all 4 install choices. The differences are in the working environment. The two lighter ones do not install HAL or gvfs. If you look in the install CD you'll see three directories: option1, option2 and option3. These are the packages for Light, Medium and Full. Remember that Full includes Medium.

Hi nightflier - thanks for confirming the kernel and installation info.  I guessed that the difference lied mainly in the packages and window manager.

After further testing and understanding, using "init=/bin/bash" in LILO has helped me to eliminate X11 from anything to do with this, since X is not even loaded yet.  My limited understanding of the boot process made me think X was still loading and generating log files but actually wasn't.

So now I am working mostly with DMESG.  Are there any other logging utils or boot logs I can check for startup information?

Also, can someone give me a quick rundown of the processing of inputs or added devices?  When booting directly into the system immediately with init=/bin/bash, is input processing: KERNEL > UDEV ? Or something other?

Another "variation" of statup on the install that is not working, the PS2 keyboard will not be loaded at all, and the mouse will be loaded onto input0.  When I hit a key, the keyboard is then added (I can see the dmesg from the system) to input1.  The normal order is keyboard is input0 and the mouse is input1.  This almost seems to be some time of timing or ordering issue that is causing the kb/mouse to not be loaded correctly in some cases.

Can I somehow force the KB and Mouse to be regenerated or reloaded on startup?  If I'm using init=/bin/bash with LILO, is the device creation done by the kernel directly or UDEV or something else?

Thanks.

[Rytz]

Tried a bunch more stuff with installing HAL and UPOWER packages and adding different configurations from diff'ed configurations in /etc.  Still experiencing the issue.

I am going to try installing VLL to a different hard drive (same box) and see if I still experience the issue.   I will report back when I do some testing.

[Rytz]

Just tried the minimal installation on a new 1TB sata drive - same problem.

[Rytz]

OK I was able to duplicate this on two separate SATA drives, one with VL Light Minimal and one with VL Light Full (fresh installs).

I'm not sure what else to do.  Can I can try to force the PS2 ports to refresh somehow?  Any suggestions out there?

[bigpaws]

This sounds like a kernel issue.

Now for the difficult part. The other thing you should be looking at are
lsmod. This will list the modules that are loaded. You could try to ssh
into the ox and get the results to see any differences.

You can check the kernel config file generally in /boot and grep for the mouse.
n example would be: cat /boot/config | grep CONFIG_MOUSE

You could compile a new
kernel and change the CONGIF_MOUSE options to y vs using m.

Udev is the suspected problem. PS/2 does not trigger events upon
plugging or unplugging. At least in my experience. 

HTH

Bigpaws

[Rytz]

With regards to the kernel config, "/boot/config-3.0.17" looks good for keyboard and mouse settings (attached).  Kernel options are the same for both Min and Full installs.

Since both minimal and full are failing randomly (I thought it was just minimal originally), lsmod might not help much, but when I did do the lsmod diff between the two installs, "fuse" was the only extra module loaded. (files attached).

I did try rebuilding UDEV from source, but I didn't try older versions.  Have there been any reported problems with VL Light UDEV with PS2 devices?

[Rytz]

The following kernel params seem to have fixed the problem after some lengthy reboot testing:

atkbd.reset=1 (forces a power reset on the PS/2 keyboard on kernel load)
i8042.noloop (fix PS/2 mouse not being detected sometimes)

With these params, I've noticed that the keyboard and mouse dmesg input messages are always next to each other now.  Previously the input messages were always close to each other but at slightly different times.

I'll post if I experience the issue again or mark the thread resolved after some more testing.

(https://www.kernel.org/doc/Documentation/kernel-parameters.txt)

[nightflier]

The normal order is keyboard is input0 and the mouse is input1.

They are not plugged in backwards, by any remote chance?

Looks like you're having one educational ride!

[Rytz]

The normal order is keyboard is input0 and the mouse is input1.

They are not plugged in backwards, by any remote chance?

Looks like you're having one educational ride!

Funny you mention the notion of plugging them in backwards - I must have re-checked like 10 times to make sure I wasn't crazy.  Keyboard/Mouse still working good so I'll mark this as solved for now.

I've learned a lot but it seems like these simple / small problems can be the most frustrating.

Thanks!