FS#27555 - [linux] i8042: No controller found

Attached to Project: Arch Linux
Opened by Michael Rieder (wombat) - Tuesday, 13 December 2011, 18:22 GMT
Last edited by Dave Reisner (falconindy) - Thursday, 24 April 2014, 14:06 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



On machines without PS2 keyboard/mouse, user gets this kernel error

kernel: [ 1.058129] i8042: No controller found

As modern systems mostly use USB for these input devices, this should rather be a warning than an error (imho).
This task depends upon

Closed by  Dave Reisner (falconindy)
Thursday, 24 April 2014, 14:06 GMT
Reason for closing:  Fixed
Additional comments about closing:  i8042 is now modular
Comment by Jan de Groot (JGC) - Wednesday, 14 December 2011, 00:02 GMT
Well, I don't see the error in that message. It's a diagnostic message printed by the i8042 driver. Mine says this:
[ 0.990364] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
Comment by Michael Rieder (wombat) - Saturday, 31 December 2011, 18:14 GMT
  • Field changed: Percent Complete (100% → 0%)
i'm sorry i have to dig deeper here. my suggestion that the log level was wrong was not good.

however, i wonder if i8042 should not be compiled as a module (CONFIG_SERIO_I8042=m), as well as libps2 and serio
Comment by Tobias Powalowski (tpowa) - Thursday, 12 January 2012, 14:53 GMT
I think it is in the kernel due to have the possibility to have an keyboard on initrd.
Comment by Thomas Bächler (brain0) - Thursday, 12 January 2012, 15:38 GMT
No, i8042 is too common and important to make this change now. Sorry, but you'll have to live with that message.
Comment by Tom Gundersen (tomegun) - Thursday, 28 February 2013, 10:42 GMT
Any chance of reassessing this bug now that we have the new 'keyboard' hook in mkinitcpio? The new hook treats all keyboards the same, and will include whatever module is necessary in the initamfs.

I think PS/2 will be getting more and more obsolete, so I think it makes sense to not give it special treatment (if it really is necessary to have the keyboard driver compiled in, then we probably want to start compiling in more modules).

A post-upgrade message from the kernel package might be necessary to inform people that they need to add the 'keyboard' hook if they want a keyboard in their initrd, but apart from that building i8042 as a module should not have any adverse effects (and udev will anyway load the module eventually even if it is not included in the initramfs).
Comment by Tom Gundersen (tomegun) - Thursday, 28 February 2013, 10:54 GMT
Some data: https://www.archlinux.de/?page=ModuleStatistics

I don't know how many people would still use i8042 (as the data is only available for things built as modules), but it appears usbhid is currently used by more than two thirds of our users, so at least in principle they might not need i8042. In practice I suppose most people actually have both, at least for now.
Comment by Jan de Groot (JGC) - Thursday, 28 February 2013, 11:32 GMT
PS/2 keyboard with USB mouse still loads usbhid, so that's not really an indication of "no ps/2 keyboard".
Comment by Tom Gundersen (tomegun) - Thursday, 28 February 2013, 11:42 GMT
Yeah, I have no way of knowing how large percentage actually don't use PS/2 at all (only way to find out is to make it a module ;-) ).
Comment by Thomas Bächler (brain0) - Monday, 17 June 2013, 14:47 GMT
Tom, did you even try this? I can see no way to convince Kbuild to compile this as a module - it is selected by several options which you cannot even change on x86.
Comment by Tobias Powalowski (tpowa) - Monday, 17 June 2013, 14:50 GMT
Closing this one it is not possible on X86 to have it as module.
Comment by Tom Gundersen (tomegun) - Monday, 17 June 2013, 15:31 GMT
Reopening to answer the question:

Yes I tried this (of course). I have been running with this as a module since I first brought it up. I remember it being a bit tricky to convince Kconfig, but now I cannot reproduce the problem here. I have:

Symbol: SERIO_I8042 [=m]

Selected by: KEYBOARD_ATKBD [=m] && !UML && INPUT [=y] && INPUT_KEYBOARD [=y] && X86 [=y] ||
MOUSE_PS2 [=m] && !UML && INPUT [=y] && INPUT_MOUSE [=y] && X86 [=y]
Comment by Thomas Bächler (brain0) - Monday, 17 June 2013, 15:36 GMT
Okay, I found it now. Configuring the KEYBOARD_ATKBD option requires CONFIG_EXPERT=y, let me paste the help for that option:

menuconfig EXPERT
bool "Configure standard kernel features (expert users)"
# Unhide debug options, to make the on-by-default options visible
This option allows certain base kernel options and settings
to be disabled or tweaked. This is for specialized
environments which can tolerate a "non-standard" kernel.
Only use this if you really know what you are doing.

We are not in a "specialized environment" and I would really advise against enabling this option.
Comment by Michael Rieder (wombat) - Wednesday, 19 June 2013, 10:17 GMT
Seems to me this should be changed upstream. the CONFIG_EXPERT=y requirement probably goes back to the time when there existed no USB keyboards and no one bothered changing that since then.
Comment by Tom Gundersen (tomegun) - Wednesday, 19 June 2013, 11:15 GMT
I'll submit a patch upstream once I get my git send-email to work again. I'll ping this report again when/if it gets accepted.
Comment by Laszlo Papp (djszapi) - Monday, 08 July 2013, 18:10 GMT
What is up? I am still waiting for it to be fixed ...
Comment by Dave Reisner (falconindy) - Monday, 08 July 2013, 18:20 GMT
@djszapi: I encourage you to scratch your own itch if this is really bothering you to the point of whinging here. It really should be a trivial patch, as it doesn't even require writing any C.
Comment by Jelle van der Waa (jelly) - Friday, 15 November 2013, 13:40 GMT
Any update on the situation?
Comment by Tom Gundersen (tomegun) - Friday, 15 November 2013, 14:15 GMT
This will be fixed upstream for 3.13. I submitted one fix [0] and two trivial buildsys changes [1,2] that have been applied to the input tree for 3.13, but have not yet reached Linus.

[0]: http://www.spinics.net/lists/linux-input/msg27317.html
[1]: http://www.spinics.net/lists/linux-input/msg27298.html
[2]: http://www.spinics.net/lists/linux-input/msg27299.html
Comment by Tom Gundersen (tomegun) - Monday, 18 November 2013, 00:32 GMT
For those of you waiting with bated breath for this to move forward: my patches have now reached Linus' tree, so we'll get rid of this warning by 3.13... yay \o/
Comment by dx (dx) - Sunday, 20 April 2014, 06:28 GMT
Any reason this issue is still open? Sounds like it's fixed already