Le 2015-08-16 17:07, walt a écrit :
On Sun, 16 Aug 2015 21:48:04 +0200
Alan McKinnon <alan.mckin...@gmail.com> wrote:
On 16/08/2015 21:42, walt wrote:
On Sun, 16 Aug 2015 18:58:27 +0200
Alan McKinnon <alan.mckin...@gmail.com> wrote:
On 16/08/2015 18:45, walt wrote:
I've been seeing this keyboard problem for the past few weeks:
after running some command from a bash prompt (haven't tried zsh
yet) the keyboard stops working. Almost like somebody unplugged
the keyboard from its usb port (except that the LED on the
keyboard stays lit so I know the power is still on).
There are no error messages in journalctl or
in /var/log/Xorg.0.log
I don't know how to change to a console without using a
ctrl-alt-Fn keystroke from the keyboard (anyone know if it's
possible?).
When I unplug the keyboard from the usb port I can see the kernel
recognize the unplug event, which makes me think that it's not a
kernel/usb bug or a broken wire in the keyboard cable.
When I re-plug the keyboard into a usb port the keyboard
immediately starts working normally again until the next time I
happen to trigger the problem by running some black-magical
command from a command prompt. There is no particular command
that causes it--it can be any arbitrary command AFAICT.
Just one weird example: I can be typing a URL in a web browser
window when a bash command finishes running in a terminal window
and the keyboard stops working in the middle of my typing :(
Any debugging suggestions would be most welcome.
First step (more to half the problem space than anything else):
Does the same happen if you use another keyboard?
I agree with your assessment -- and I will buy another usb keyboard
tomorrow because I'm using the only one I have and this machine has
no ps/2 ports. Never thought I'd miss the ps/2 ports til now :)
I kind of assumed you'd have lots of spare keyboards lying around and
had already done the test :-)
I do have spares, all ps/2 :-(
I recall something similar happening to me,
perhaps a year ago or longer. I tried to debug it and gave up, then
one day it was no longer happening. I assumed it was a fixed kernel
bug then promptly forgot all about it.
While you are waiting on a new keyboard, do you have the same bug on
different kernels?
Affirmative, and thereby hangs yet another woeful tale. I've been
running the gentoo-sources-3.14.xx series forever because I wearied of
spending so many hours debugging unstable kernels.
This morning I decided to take a giant leap forward all the way to
3.18.19 (BTW 3.18.20 is already on kernel.org) because, surely, I
wouldn't need to debug a kernel as old as that, right?
Wrong. Linus and friends have been marking lots of existing kernel
symbols with the SYMBOL_EXPORT_GNU macro, which was designed to block
the loading of any kernel module not explicitly licensed as GNU
software. (see output of modinfo)
x11-drivers/ati-drivers installs a proprietary binary blob (as does
nvidia-drivers) so the linker refused even to link the kernel module
into a .ko file, nevermind the kernel actually loading the module at
runtime.
The remedy for ati-drivers is well-hidden in a comment in a gentoo bug
report that I found at oh-dark-hundred hours this morning. Only two
hours later I got the module installed and loaded :)
But yes, kernel 3.18.19 still has my same keyboard halting problem, so
I'm back to 3.14.50 until the ati-drivers package is patched. I'm sure
gentoo-sources-3.18.20 will be available almost immediately and I'm not
going through that hell again.
I am running Kernel 4.0.5 with no problem with the keyboards. I did encounter one issue, I purchased a French Canadian keyboard off ebay, turned out that the computer box had to be close to the mouse/keyboard otherwise I either lost signal or it was very
slow. It seemed that when I would connect and reconnect it would work correctly again. That mouse/keyboard combo was from HP.
Is your issue with Logitech remote mouse/keyboard? If so you may want to read
about my experience on the subject.
I had an issue with Debian on an Olimex A20 Arm board, no issue with ArchLinux on the same board with the same kernel. I found out that the difference was some special options for HID support for Logitech that were disabled by default. Archlinux noticed
but not debian, in the debian world they must think that nobody uses logitech devices.
This morning I downloaded the latest kernel from sunxi that supports the mali GPU (3.4.103) for my old Mele A2000G, I wanted to upgrade it to Gentoo from SuSE. Someone seemed to have backport the debian bug into it as my logitech keyboard didn't work.
After I enabled the HID special support for Logitech, both mouse and keyboard now work perfectly.
Michel
--
For Linux Software visit
http://home.comcast.net/~mcatudal
http://sourceforge.net/projects/suzielinux/
