I have a problem very similar to this person's problem, from long ago: https://bbs.archlinux.org/viewtopic.php?id=48493
Randomly, every couple of boots or so, but sometimes several boots in a row, the keyboard and mouse won't work at all, not even the indicator LEDs on the caps lock and num lock keys. Actually, I can tell whether or not the keyboard and mouse are going to work after a given boot by trying to press the caps lock key during the boot and seeing if its LED changes. However, even when the keyboard doesn't work I can still change the screen's brightness using the FN-F2 key combo on the keyboard, and the power button still works (Linux starts the shutdown process when I press it). If I set it up to start X on boot, all the autostart programs load normally, so the system isn't freezing or anything like that, and I can confirm that the mouse doesn't work either.
I've tried it with Debian with Linux 3.2, Debian with 3.7, Arch with 3.6, and now Arch with 3.8-rc2, and I have the same problem with all of them. (Although, upgrading to 3.7+ let me change the screen's brightness, which is really nice!) This problem does not seem to happen with Windows 8, which is what the computer came with. Also, the keyboard always works in GRUB, before booting Linux.
The computer is a laptop, specifically a Toshiba Satellite C875D-S7345.
What other information can I provide to help troubleshoot the problem?
I have this problem from time to time as well... but have never experienced it with more than one boot at a time. Also, it *seems to only happen when I do a warm boot (reboot) and not when I do a cold boot.
Adam, welcome to the forums! I think it may help if you provided some relevant logs (and please don't just post an entire log without looking at it, expecting that someone else will want to scour over logs that you didn't want to). I think that you might start by looking in your xorg log and the journal.
*I say seems because I don't really keep track of these things. I have never really found it to be so much an issue as to investigate, as it is not incredibly frequent.
The problem is much worse on this computer. Now I realize that it's quite a bit more than 50% of the boots that are "bad" boots; I had to reboot more than five times just a little while ago before it worked. Also, it happens with cold boots, too.
I've been using journalctl to collect a bunch of logs for the good and bad boots, and I used sed/sort/comm to find the lines that were common to the logs of all of the bad boots and all of the good boots. The only real difference I've been able to find is that all of the good boots have this in their logs:
Jan 06 20:12:08 arch kernel: psmouse serio2: synaptics: Touchpad model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04733/0xa40000/0xa0000, board id: 3655, fw id: 582762 Jan 06 20:12:08 arch kernel: psmouse serio2: synaptics: Toshiba Satellite C875D detected, limiting rate to 40pps. Jan 06 20:12:08 arch kernel: input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio2/input/input7
and the bad boots don't, which doesn't really tell me much that I don't already know; on the good boots, Linux detects a mouse, and on the bad boots it doesn't.
Do you think it's safe to say that this is a kernel problem? Should I make a bug report for the Linux kernel? I have the same problem with Debian, so it's not distro specific.
Have you tried putting psmouse and whatever else in your initramfs, or getting specific in modules-load.d to try to ensure that these modules get loaded?
Just tried adding psmouse to my initramfs and to modules-load.d, but it didn't change anything.
However, I can plug in a USB mouse and that still works on the bad boots. Unfortunately, I don't have a USB keyboard, so even with that I can't really use the computer on the bad boots.
Yes, I was already aware that the hotplugging of usb devices worked on those bad boots (maybe I should ahve mentioned that... sorry), but it seems funky that it will not load the psmouse module even when explicitly specified. Or I guess at least not apply the psmouse module to the relevant hardware, as I have not tried to debug this at all.
It looks like it's the latter case, because psmouse is being loaded even on the bad boots on this computer. (I just put an lsmod in my .bash_profile to see if it was being loaded).
You realize that lsmod needs to be called as root? Did you go about giving the command appropriate permissions?
Are you sure? I've always been able to run lsmod without root access, on every Linux distribution I've used.
Sorry for some reason I read that as insmod (even though I then retyped it as lsmod)... sorry for the noise.
I have been doing horribly at reading things correctly lately...
I have exactly the same problem. The keyboard and mouse is PS/2. It happened to me one time that the keyboard did work, but the mouse didn't. Is there any solution??
Sorry kbs1, I gave up on looking for a solution a long time ago, so I don't have any suggestions =\. I've just been regularly updating my kernel in the hopes that it's some strange kernel issue that will get fixed one day.
Fortunately for me, it seems to have gotten less frequent since I originally posted. Before I would regularly have to reboot five times in a row or more before it would work, and now I usually only have to reboot once or twice every 2nd or 3rd time I use the computer or so. I kind of doubt that there's anything in particular I did that made it better, since the whole issue seems pretty random.
I had the same problem, from Xorg.0.log.old I've concluded that somehow keyboard is recognized as a power button My mouse works but keyboard (Logitech K350 via unified reciever) doesn't (every third/fourth boot). Since I reinstalled (gave KDE a spin, Xfce before that) it havent showed up not once. Problem started after compiling the first series of 3.10 kernel (bug was certainly introduced during the first two weeks / when the merge window for 3.10-series was open). I should have bisected it then, but haven't had the time and bug couldn't be triggered reliably so I gave up.
After searching a bit more:
Last edited by combuster (2013-07-23 21:06:05)
If what combuster asserts is the problem, The answer may be to create a custom xorg configuration for evdev. This will involve looking at the "contents" of /proc/bus/devices and /var/log/Xorg.0.log and figuring out which devices are being detected and how they are being mapped.
ewaller$@$odin /etc/X11/xorg.conf.d 1010 %cat /proc/bus/input/devices I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 S: Sysfs=/devices/platform/i8042/serio0/input/input0 U: Uniq= H: Handlers=sysrq kbd event0 rfkill B: PROP=0 B: EV=120013 B: KEY=20000 20 0 0 540f02100003 3803078f900d401 feffffdfffefffff fffffffffffffffe B: MSC=10 B: LED=7 I: Bus=0019 Vendor=0000 Product=0001 Version=0000 N: Name="Power Button" P: Phys=PNP0C0C/button/input0 S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input1 U: Uniq= H: Handlers=kbd event1 B: PROP=0 B: EV=3 B: KEY=10000000000000 0 I: Bus=0019 Vendor=0000 Product=0005 Version=0000 N: Name="Lid Switch" P: Phys=PNP0C0D/button/input0 S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input2 U: Uniq= H: Handlers=event2 B: PROP=0 B: EV=21 B: SW=1 I: Bus=0019 Vendor=0000 Product=0003 Version=0000 N: Name="Sleep Button" P: Phys=PNP0C0E/button/input0 S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input3 U: Uniq= H: Handlers=kbd event3 B: PROP=0 B: EV=3 B: KEY=4000 0 0 I: Bus=0019 Vendor=0000 Product=0001 Version=0000 N: Name="Power Button" P: Phys=LNXPWRBN/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4 U: Uniq= H: Handlers=kbd event4 B: PROP=0 B: EV=3 B: KEY=10000000000000 0 I: Bus=0019 Vendor=0000 Product=0000 Version=0000 N: Name="ST LIS3LV02DL Accelerometer" P: Phys=lis3lv02d/input0 S: Sysfs=/devices/platform/lis3lv02d/input/input5 U: Uniq= H: Handlers=event5 js0 B: PROP=0 B: EV=9 B: ABS=7 I: Bus=0001 Vendor=111d Product=76b2 Version=0001 N: Name="HDA Digital PCBeep" P: Phys=card0/codec#0/beep0 S: Sysfs=/devices/pci0000:00/0000:00:1b.0/input/input6 U: Uniq= H: Handlers=kbd event6 B: PROP=0 B: EV=40001 B: SND=6 I: Bus=0000 Vendor=0000 Product=0000 Version=0000 N: Name="ENE eHome Infrared Remote Receiver" P: Phys= S: Sysfs=/devices/virtual/rc/rc0/input7 U: Uniq= H: Handlers=kbd event7 B: PROP=0 B: EV=100013 B: KEY=fff 0 200108fc32e 237605100000000 0 700158000 419200004001 8e968000000000 10000000 B: MSC=10 I: Bus=0000 Vendor=0000 Product=0000 Version=0000 N: Name="HDA Intel HDMI/DP,pcm=3" P: Phys=ALSA S: Sysfs=/devices/pci0000:00/0000:00:1b.0/sound/card0/input8 U: Uniq= H: Handlers=event8 B: PROP=0 B: EV=21 B: SW=140 I: Bus=0000 Vendor=0000 Product=0000 Version=0000 N: Name="HDA Intel Front Headphone" P: Phys=ALSA S: Sysfs=/devices/pci0000:00/0000:00:1b.0/sound/card0/input9 U: Uniq= H: Handlers=event9 B: PROP=0 B: EV=21 B: SW=4 I: Bus=0000 Vendor=0000 Product=0000 Version=0000 N: Name="HDA Intel Mic" P: Phys=ALSA S: Sysfs=/devices/pci0000:00/0000:00:1b.0/sound/card0/input10 U: Uniq= H: Handlers=event10 B: PROP=0 B: EV=21 B: SW=10 I: Bus=0000 Vendor=0000 Product=0000 Version=0000 N: Name="HDA Intel Dock Mic" P: Phys=ALSA S: Sysfs=/devices/pci0000:00/0000:00:1b.0/sound/card0/input11 U: Uniq= H: Handlers=event11 B: PROP=0 B: EV=21 B: SW=10 I: Bus=0000 Vendor=0000 Product=0000 Version=0000 N: Name="MCE IR Keyboard/Mouse (ene_ir)" P: Phys=/input0 S: Sysfs=/devices/virtual/input/input12 U: Uniq= H: Handlers=sysrq kbd mouse0 event12 B: PROP=0 B: EV=100017 B: KEY=30000 7 ff87207ac14057ff febeffdfffefffff fffffffffffffffe B: REL=3 B: MSC=10 I: Bus=0010 Vendor=001f Product=0001 Version=0100 N: Name="PC Speaker" P: Phys=isa0061/input0 S: Sysfs=/devices/platform/pcspkr/input/input13 U: Uniq= H: Handlers=kbd event13 B: PROP=0 B: EV=40001 B: SND=6 I: Bus=0019 Vendor=0000 Product=0006 Version=0000 N: Name="Video Bus" P: Phys=LNXVIDEO/video/input0 S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input14 U: Uniq= H: Handlers=kbd event14 B: PROP=0 B: EV=3 B: KEY=3e000b00000000 0 0 0 I: Bus=0019 Vendor=0000 Product=0000 Version=0000 N: Name="HP WMI hotkeys" P: Phys=wmi/input0 S: Sysfs=/devices/virtual/input/input15 U: Uniq= H: Handlers=kbd event15 B: PROP=0 B: EV=33 B: KEY=4000000000 0 1000700000000 2100400 0 0 B: MSC=10 B: SW=22 I: Bus=0003 Vendor=064e Product=c107 Version=0100 N: Name="HP Webcam" P: Phys=usb-0000:00:1d.7-5/button S: Sysfs=/devices/pci0000:00/0000:00:1d.7/usb7/7-5/7-5:1.0/input/input16 U: Uniq= H: Handlers=kbd event16 B: PROP=0 B: EV=3 B: KEY=100000 0 0 0 I: Bus=0011 Vendor=0002 Product=0008 Version=0000 N: Name="PS/2 Mouse" P: Phys=isa0060/serio1/input1 S: Sysfs=/devices/platform/i8042/serio1/input/input17 U: Uniq= H: Handlers=mouse1 event17 B: PROP=0 B: EV=7 B: KEY=70000 0 0 0 0 B: REL=3 I: Bus=0011 Vendor=0002 Product=0008 Version=0200 N: Name="AlpsPS/2 ALPS GlidePoint" P: Phys=isa0060/serio1/input0 S: Sysfs=/devices/platform/i8042/serio1/input/input18 U: Uniq= H: Handlers=mouse2 event18 B: PROP=0 B: EV=b B: KEY=420 70000 0 0 0 0 B: ABS=1000003
Then, craft a configuration file. Mine does not do much, it just limits what is mapped:
ewaller$@$odin /etc/X11/xorg.conf.d 1011 %cat 10-evdev.conf # # Catch-all evdev loader for udev-based systems # We don't simply match on any device since that also adds accelerometers # and other devices that we don't really want to use. The list below # matches everything but joysticks. Section "InputClass" Identifier "evdev pointer catchall" MatchIsPointer "on" MatchDevicePath "/dev/input/event*" Driver "evdev" EndSection Section "InputClass" Identifier "evdev keyboard catchall" MatchIsKeyboard "on" MatchDevicePath "/dev/input/event*" Driver "evdev" EndSection Section "InputClass" Identifier "evdev touchpad catchall" MatchIsTouchpad "on" MatchDevicePath "/dev/input/event*" Driver "evdev" EndSection Section "InputClass" Identifier "evdev tablet catchall" MatchIsTablet "on" MatchDevicePath "/dev/input/event*" Driver "evdev" EndSection Section "InputClass" Identifier "evdev touchscreen catchall" MatchIsTouchscreen "on" MatchDevicePath "/dev/input/event*" Driver "evdev" EndSection ewaller$@$odin /etc/X11/xorg.conf.d 1012 %
If one needs to, you can force certain devices, by name if need be, to map to drivers of your choice. General purpose repros try to make rules that are generic and will work universally. It does not always work.
Edit: Having re-read the thread, it looks like this can happen outside of X, but it is not clear. If you boot to the console, have you the same problem? If so, is there anything of interest in the journal (assuming your journal is configured to be persistent across a reboot )
Last edited by ewaller (2013-07-23 21:34:07)
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
You assume people are rational and influenced by evidence. You must not work with the public much. -- Trilby
How to Ask Questions the Smart Way
Yup, the problem is definitely not limited to X. Instead of booting directly into X, I boot and reboot into the console until the keyboard works and then type "startx," because I feel bad when the poor computer goes through all of that hard work to start up X just to be rebooted anyway because the keyboard and mouse don't work.
I don't have the journal logs from when I was trying to fix the problem in the beginning anymore, but if you look at my second post, those three lines are the only consistent difference I could find between the good boots and bad boots. Then again, from what I remember my process for analyzing the logs was pretty hacky and probably inconsistent. Maybe there's a better way of analyzing it with the systemd journaling stuff, but I don't really know how to use the journal effectively.
Last edited by Adam Buechler (2013-07-23 23:37:24)
There has been some chatter on the systemd mailing list about USB devices and moving their udev rules to the faster, less resource intensive, hwdb. Now it shouldn't matter whether it is configured in either, but the reason I bring it up is because there was mention that unfortunately, logitech does not follow the basic standards for uniquely identifying particular devices. So they deemed it impossible to actually port the broken rules that exist over the hwdb.
So unfortunately, it sounds like using Logitech is just not recommended. Maybe you should reach out to the systemd mailing list (since they are udev now) and see if someone there can help you. Tom Gunderson is actually the one who has been doing the most work on porting this stuff to the new format. So maybe he can shed some light on your issues and why they are there in the first place.