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.
