3

Something weird is going on with my keyboard. The keyboard is a USB-connected Unicomp, which works absolutely flawlessly once the computer is up and running. However, GRUB 2 (specifically, 1.99-27+deb7u1 as shipped in Debian Wheezy) isn't quite so happy. The failure modes make this a little difficult to test, but here's what I've been able to deduce thus far:

  • The keyboard status LEDs flash during the POST, so the keyboard is detected (I also get a report "Detected: ... 1 Keyboard"); I've got maybe one "no keyboard detected" error from the POST, nowhere near enough to deduce any pattern to that, and I've been rebooting the system quite a few times in different ways lately
  • On a power on from a full power off with the front panel power button, everything seems to work great
  • On a reboot (either using reboot or Control+Alt+Delete in a booted system or in GRUB), the keyboard works in GRUB maybe every other time I try
  • If I hit the Reset button on the computer to reboot, the keyboard consistently does not work in GRUB when the boot loader comes back, and many times does not react to key presses during the POST either

What's even more weird is that I don't recall the computer acting like this before. I'm hoping it's unrelated, but it seems to have started acting up right around when I hooked up the UPS to some more things around my desk, instead of only having hooked it up to the computer and monitor. (No, the UPS is nowhere near overloaded; the load is reported as being in the range 7-20% depending on usage; around 15-16% of maximum load when the computer is up and running normally.)

I've Googled and found the suggestion to load the GRUB 2 modules uhci and usb_keyboard. I added a GRUB_PRELOAD_MODULES declaration specifying the two of them to /etc/default/grub and re-ran update-grub (there is now insmod uhci and insmod usb_keyboard in my /boot/grub/grub.cfg), but that does not seem to have changed anything.

I've moved the keyboard to another USB port, which does not appear to have helped. I would try an offboard USB controller if I had one handy.

BIOS/UEFI setup reports legacy USB support and legacy USB 3.0 support as enabled, and even if it didn't, I don't see why it would sometimes work and sometimes not, especially when many times the only difference between the two is which side of a warm reboot it's on.

The motherboard is an ASUS M5A97 Pro with UEFI version 1007 02/10/2012.

I can't think of any other configuration changes I've done that coincide with when the computer started acting up. The logs do mention an upgrade of linux-image on Aug 1, and that I reinstalled (it's noted as upgrade, but the from-version and to-version are identical) grub-pc on Aug 2, but both of those was a week before I even bought the UPS, and two weeks before I hooked it up to more than just the computer and monitor (I take care to not change too many things at once). uname -r reports 3.2.0-4-amd64.

I'm running out of ideas to try. How can I get my USB keyboard to work consistently in GRUB 2? What else can I check?

| improve this question | |
  • I've had related symptoms but on an unrelated setup (Win8+MS wireless usb kb). Either in grub or when coming back from "sleep", the mouse would work but not the kb. I haven't had the issue for a while now and what happened in between was that I reinstalled from scratch with format on the whole drive. I have no clue what did it but most of the time when it happened, unplugging then replugging the usb connection usually solved it. – user44370 Aug 23 '13 at 22:19
  • I think the answer to this may lie in a BIOS that's not resetting some critical control register on soft-boots. If a hard-boot (power cycle) makes things work fine, it is very likely code that runs before grub is ever loaded that's at issue. – msw Aug 24 '13 at 3:18
  • I can confirm my setup includes an older Asus board, with AMI bios. – user44370 Aug 24 '13 at 4:29
  • @msw Yes, I'm getting that feeling too (which is why I mentioned both the motherboard model and BIOS/UEFI version) but what puzzles me is that it seems to have started just recently, coinciding with a completely unrelated change and not being anywhere near any change which would seem relevant. If something wasn't getting reset properly I'd also expect using the reset button to work better, but from my experiments it seems to do worse. – a CVn Aug 24 '13 at 11:15
  • 1
    I just noticed on the ASUS web site for the M5A97 Pro that there have been half a dozen new BIOS versions, several of which are listed as "Enhance compatibility with some USB devices". They are now at 1604 whereas I'm at 1007. Going to give upgrading a try and see if that helps. – a CVn Aug 24 '13 at 11:27
1

Well, I kinda-sorta found out what's wrong. I still don't know what's the underlying problem, though.

Upgrading the UEFI/BIOS to the most recent version (currently 1604) did not help, despite the fact that a few interim releases were specifically advertised as "enhance compatibility with some USB devices" (which appears to have been my exact problem). In fact, if anything, it seemed to make matters worse, but in a good way: the system started consistently failing to be able to use the keyboard on a warm reboot. Consistent errors are always easier to debug and fix.

By applying the scientific method (form a hyphothesis, figure out a way to test it, test and refine), I was able to determine that the most likely culprit is my USB mouse or more generally having a USB pointing device of mine connected.

I started out by disconnecting everything USB-connected that wasn't absolutely necessary to test the failure case, so the only peripheral which was on the USB bus was the keyboard. That worked. So I added things back, one at a time, testing as thoroughly as I could between each change. Things started acting up by the time I added the desk hub, to which I had hooked up two devices: my mouse and drawing tablet. After some back-and-forth, I unplugged both of those but left the hub connected; still had the same issues. Plugging only either the hub, the mouse or the tablet directly into the USB ports on the motherboard got me back to where I started, which meant that one or more of those were causing my problems.

I can do without the tablet, but using the computer with no pointing device gets rather tiresome really fast, so I dug around in my spare computer cables box and found a USB to PS/2 adapter which I thought I'd give a try. Having plugged the mouse into the adapter and the adapter into the PS/2 mouse/keyboard port on the motherboard, things seem to be working. I did as full a test as I could think of and each time the system came back completely normally.

My current working hypothesis is that something has caused damage to the USB hub which may have propagated to the tablet and mouse, and that this damage is somehow causing my problems. (The only two non-host devices I've had connected to the hub is the mouse and tablet.) That doesn't fully explain why connecting the mouse through a USB-PS/2 adapter seems to work just fine, but a guess is that it might have something to do with how the BIOS handles the different devices (it does not seem to recognize a "PS/2" mouse as a mouse, but I can certainly live without the mouse in the UEFI setup).

I'll be able to test this hypothesis further next week, assuming I can borrow a USB mouse from work.

For now, disconnecting the hub and tablet and having moved the mouse to the PS/2 port appears to be good enough.

| improve this answer | |
  • IANAEE, but USB has always seemed to me to be unduly sensitive to trivial variation in signal levels sigh. On the other hand Science. It works. – msw Aug 24 '13 at 14:45
  • 1
    @msw Indeed it does. When all else fails, the scientific method is usually worth trying, even if (as in this case) it means crawling around on the floor for an hour and a half testing different combinations... – a CVn Aug 24 '13 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.