[Bug 1014460] Re: Touchpad sometimes not working upon system startup

[Launchpad Bug Tracker]

** Branch linked: lp:~ubuntu-core-dev/ubuntu/quantal/udev/ubuntu

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to udev in Ubuntu.
https://bugs.launchpad.net/bugs/1014460

Title:
  Touchpad sometimes not working upon system startup

Status in “udev” package in Ubuntu:
  Fix Committed

Bug description:
  This happens very infrequently. The symptom is touchpad not working
  after boot up unless a reboot is made, or a manual "modprobe psmouse"
  is performed on the command line. Movement or click activities on the
  touchpad during system startup will increase the chance of happening
  of this issue.

  The root cause is a race condition upon system startup, that the
  serio1 device (i.e. the AUX port) could be temporarily binded to the
  keyboard driver, and thus udev rule will ignore the event by not
  loading psmouse at all. A detailed explanation of the theory is as
  follows:

  1. serio ports (e.g. AUX port for touchpad) are different than other devices that:
     - the kernel is using a dedicated kernel thread kseriod to handle the events
     - interrupts on serio port will trigger connect attempt, as the OS has no idea when a keyboard/mouse could be plugged into the computer

  2. The AT keyboard driver atkbd.c is built-in to the kernel for speed
  up as there will be normally an AT keyboard present, however, as on a
  normal PC, the keyboard can be connected to either the keyboard PS/2
  port (i.e. KBD port), or the mouse PS/2 port (i.e. AUX port), the
  atkbd driver will be probed each time an interrupt is generated on the
  AUX port, in case there is a plug

  3. When doing the probing, the serio1 device will be temporarily
  binded with atkbd, and this is in the context of kseriod

  4. udev has the chance of being launched at the same time, the time
  that udev is launched, there will be a trigger to replay all uevents

  5. that trigger will request uevents to be generated from the kernel,
  and if serio1 happens to be in the middle of a probing (most likely
  with atkbd), the uevent generated will have DRIVER=atkbd with it

  6. psmouse is being built as a module, udev is following the rule
  below to load psmouse ondemand:

    /lib/udev/rules.d/80-drivers.rules:
    ...
    DRIVER!="?*", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -bv $env{MODALIAS}"

  7. So if uevent for serio1 happens to be with DRIVER entry, this rule
  will _not_ be performed as DRIVER!="?*" is _not_ matched, thus
  modprobe will not load psmouse on demand

  8. One simple fix is to add one additional rule to 80-drivers.rules,
  so that serio events are treated special that modprobe will anyway be
  performed, e.g.

    SUBSYSTEM=="serio", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -bv
  $env{MODALIAS}"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/1014460/+subscriptions