Touchpad stops working when wifi/3G connects

[David J. Lennon]

Tested this and have been able to replicate across two different machines, one with Intel i3945 Wireless and one with Realtek Wireless.

After initial 10.10 Install, when the Wireless adapter connects to a network for the first time, the laptop touchpad will stop working and it becomes impossible to move the cursor. This is rectified by either restarting the machine, or turning the touchpad on and off (if the laptop has such an on/off switch).

[Robbie Williamson (robbiew)]

are you able to CTRL-ALT-F1 to a terminal? If so, could you attach the output of running 'dmesg' after this event has occured?

[David J. Lennon (david-justsomeboy)]

Absolutely - Just replicated again on the Realtek machine - dmesg attached.

[David J. Lennon (david-justsomeboy)]

Also attaching video demonstration - This is a fresh install.

[Robbie Williamson (robbiew)]

Nothing in dmesg...could you attach your Xorg.0.log and Xorg.0.log.old? I'm also seeing if we can get some kernel eyes on this one.

[David J. Lennon (david-justsomeboy)]

Sure thing - Xorg log attached.

[David J. Lennon (david-justsomeboy)]

Xorg log (old)

[Henrik Rydberg (rydberg)]

From the Xorg log, it seems the trackpad is picked up by the synaptics driver (as it should). It would be great to see if this problem persists when running a different driver, like evdev. In order to do so, you would need to add something like this to /etc/X11/xorg.conf and restart:

Section "InputClass"
    MatchIsTouchpad "true"
    Identifier "Touchpad"
    Driver "evdev"
EndSection

[Chase Douglas (chasedouglas)]

David,

Are these log files from a session where you saw this issue? I'm not seeing anything useful in the logs.

In case it's not clear to you what we need, please reproduce the issue and then attach /var/log/Xorg.0.log without logging out or restarting.

I have a hunch on what's causing this issue, and hopefully it will be fixed in xserver-xorg-input-synaptics 1.2.2-2ubuntu4.

[David J. Lennon (david-justsomeboy)]

Thanks Henrik / Chase - I'll reinstall on the test machine, reproduce the issue and attach the new Xorg logs - I'll also try and reproduce with evdev running from clean install to see whether this change affects the issue.

Chase - I'll also try and reproduce with the new driver (from https://edge.launchpad.net/ubuntu/maverick/i386/xserver-xorg-input-synaptics/1.2.2-2ubuntu4)

[David J. Lennon (david-justsomeboy)]

Attaching replacement Xorg log

[David J. Lennon (david-justsomeboy)]

Bit of an odd one - I'm not able to test the new driver at the moment... If I connect to the internet via ethernet first, i'm unable to reproduce the bug using the Beta ISO when connecting to Wifi. Seems that having used some form of internet connection before activating Wifi for the first time stops the issue.

Is the updated driver present in the latest daily build?

[Francesco Ruvolo (ruvolof)]

It affects me too. But in my case turning off and the on the touchpad or restarting the machine hasn't any result. I'm testing in usb live mode.

Bye

[Sergio Zanchetta (primes2h)]

I face this bug when connecting via 3G Internet key.

So it seems to be a more general network-manager problem.
Adding the task.

[Sergio Zanchetta (primes2h)]

I noticed another thing.

After having this issue, I connect an usb mouse and after using the system for a while touchpad starts working again.

[Nicolas Delvaux (malizor)]

Same problem here, my touchpad stops working as soon as the "connected" notification appear.
However, if I press some random keys to go to a menu or into a directory, the touchpad then goes back to life after 5-10 seconds.

[Francesco Ruvolo (ruvolof)]

I upgraded to maverick. It doesn't happen on an installed system, only with a live one.

[Nicolas Delvaux (malizor)]

@Francesco: same thing for me

[Kate Stewart (kate.stewart)]

adding tags so this gets tracked for fixing in Natty as well.

[Andy Whitcroft (apw)]

Can someone who is affected by this issue confirm whether this appears in the Natty daily live CDs? There has been so much change in the kernel side of these drivers I would like to confirm whether the problem has been resolved there. Please report back here. Thanks.

[Mathieu Trudel-Lapierre (cyphermox)]

Andy, I can confirm this happens for *3g* with my 3g usb key on my system fully updated. However, I have absolutely never seen the same happen with pure wifi drivers. It however seemed to not only affect touchpad, but also my USB mouse.

I will test with today's daily image and try to turn on as much debugging info I can get from ModemManager/NetworkManager to figure out which calls cause the mouse to lock.

[Andy Whitcroft (apw)]

@Mathieu -- can you confirm whether this was visible on the latest daily images? Is the issue still present?

[Francesco Ruvolo (ruvolof)]

In natty alpha 2 it still does. But now it start to work again after few minutes.

[Mathieu Trudel-Lapierre (cyphermox)]

I can also confirm it hangs in a live session. I also managed to get strace output and roughly pinpoint the issues to a particular action.

When probing the serial devices MM tries to do the following with various interfaces exported by the modem. In this case, ttyUSB0 isn't the actual tty that will receive AT commands but is exported by the modem:

open("/dev/ttyUSB0", O_RDWR|O_EXCL|O_NOCTTY|O_NONBLOCK) = 24
ioctl(24, TIOCEXCL, 0) = 0
ioctl(24, TCFLSH, 0x2) = 0
ioctl(24, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(24, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(24, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(24, SNDCTL_TMR_START or TCSETS, [***] {B57600 -opost -isig -icanon -echo ...}) = 0

Note that NM is stopped at the time (I need to stop is to restart NM and trace it...), and nothing else was running.

What happens appears to be the following: if I'm just moving the mouse, nothing special. There doesn't seem to be any lockup, things go along fine until the modem is "ready".

At the point where MM gets to the open() call for ttyUSBx, in strace, before the closing parens is added for that call, and I press a key on my keyboard, the mouse stops moving and no characters are outputted to the screen. Things appear to be locked for a few seconds (5-6 seconds by my count).

Things unlock at the point where we get to the "ioctl(24, SNDCTL_TMR_START or TCSETS" line where I added the "[***]" marker. The characters I typed in (or at least some of them) appear on the screen and the mouse pointer starts moving again.

I'm attaching the "full" strace output I got for reproducing one or two occurrences of this issue.

From what I can tell this relates roughly to the "tcgetattr (priv->fd, &priv->old_t)" call at line 733 in src/mm-serial-port.c; but I'm nowhere close to knowing whether it's an issue in MM or some part of the serial stack (or even the devices). FWIW, the code I'm referencing is readable at http://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/mm-serial-port.c .

[Herton R. Krzesinski (herton)]

Perhaps we have something hung in-kernel when the pointer stops to move.

When it freezes, please enter this command on a terminal:
sudo echo w > /proc/sysrq-trigger

And after this create a dmesg output and attach here.

[Mathieu Trudel-Lapierre (cyphermox)]

I won't be able to run this command as the keyboard locks as well. I haven't tried using the key directly though, that just might work.

[Herton R. Krzesinski (herton)]

If keyboard is locked you can try also enable/install ssh server and login through it from another machine, and run the command.

[Mathieu Trudel-Lapierre (cyphermox)]

Ah, I finally just got around to try this, but SSH also appears to be locked up, or at least, I couldn't type within a screen session.

[Mathieu Trudel-Lapierre (cyphermox)]

Ok, I managed to get something if I hold a key on the affected laptop, and run the command from ssh on another machine as soon as the characters stop appearing on screen; I've attached a copy of /var/log/syslog which contains a couple of occurrences I tried to trap, to give the best chance of identifying what was going wrong.

I don't know too much about the kernel but if it hangs on the local keyboard and in the SSH session (as well as much everything else), and finally does show the characters I "typed" once it unlocks, wouldn't the sysrq results also be generated and outputted after the unlock, and thus not accurately represent the issue?

[Herton R. Krzesinski (herton)]

sudo sh -c "echo w > /proc/sysrq-trigger" should've been the command I said in comment #24, sorry about that. The output from the sysrq-w points to a deadlock in tty code, will check the code further.

[Herton R. Krzesinski (herton)]

After checking the log and the code, in fact there isn't a deadlock, just a big wait while holding tty lock.

There is a problem with the GSM modem. In the log we can see it keeps connecting and disconnecting from usb. Eventually, the modem stops to answer, and usb_control_msg called by option driver starts to timeout probably. The timeout is somewhat big (5s), and this timeout occurs while we have the "big tty lock" held, so everything which tries to access any tty related ends up waiting ~5 seconds until the function timeouts and returns to tty layer which releases the lock.

So the real issue is with the 3g modem. I see in the log some related failures to usb_modeswitch, perhaps it's confusing the modem sending a bad command, which leaves it in a bad state, making it disconnecting and reconnecting, and it stops to answer to usb_control_msg properly.

[Mathieu Trudel-Lapierre (cyphermox)]

I'm really not as convinced it's a device issue -- I could have sworn I've seen the same with other devices than this ZTE MF636, and the original reporter mentions wifi causing this issue, not 3g (and I can't find anything about 3G in the attached dmesg output).

Let's keep this Incomplete for now, and I'll see if I can put my hands on a different 3g modem to test with (like a huawei, which should end up using different enough code paths).

[Herton R. Krzesinski (herton)]

I don't mean it to be a device issue, can be still something with usb_modeswitch or something done by option driver, what I mean is that the root of the problem is realted to the modem. I think trying different usb_modeswitch configuration just to test can help in see what's causing the problem.

[Herton R. Krzesinski (herton)]

Something that I didn't noticed is that the timeouts seems to happen always on option_send_setup. There is another modem which have such a similar problem and a quirk was made to option not much time ago.

@Mathieu -- I applied the same solution to ZTE MF626. Please download and test the kernel I placed at http://people.canonical.com/~herton/lp636091/

For others in this ticket which have the same issue: please also test this kernel, if you still see the problems, then either the problem is different, or you have another modem with different id. On the latter case, please try provide same log for me to check, and/or just usb id of the modem (lsusb) (you must get it after usb_modeswitch "ejects" the device -- when /dev/ttyUSB* appear), so I can try to add quirks to more modem ids if necessary.

[Mathieu Trudel-Lapierre (cyphermox)]

Seems to work with my ZTE MF636, not long freezes anymore.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 2.6.38-7.35

---------------
linux (2.6.38-7.35) natty; urgency=low

  [ Andy Whitcroft ]

  * rebase to 2fbfac4e053861925fa3fffcdc327649b09af54c
  * rebase fixes bug #715330
  * [Config] disable CONFIG_SCSI_QLA_ISCSI for powerpc 32bit to fix FTBS
  * rebase to v2.6.38 final

  [ Herton Ronaldo Krzesinski ]

  * SAUCE: Apply OPTION_BLACKLIST_SENDSETUP also for ZTE MF626
    - LP: #636091

  [ Tim Gardner ]

  * [Confg] CONFIG_BOOT_PRINTK_DELAY=y

  [ Upstream Kernel Changes ]

  * Yama: use thread group leader when creating match
    - LP: #729839
  * (drop after 2.6.38) ahci: AHCI mode SATA patch for Intel Patsburg SATA
    RAID controller
    - LP: #735240
  * (drop after v2.6.38) x86, quirk: Fix SB600 revision check

  [ Major Kernel Changes ]

  * rebase from v2.6.38-rc8 to v2.6.38 final
    - LP: #715330
 -- Andy Whitcroft <email address hidden> Tue, 15 Mar 2011 19:04:19 +0000

[Matt Wilson (mw44118)]

I just installed natty narwhal on my dell 1420 and as soon as I punched my sudo password to unlock my key to get on the wireless, my touchpad stopped working.

[ullaspa (ullaspa)]

Upgraded yesterday from Maverick to Natty on my Dell Vostro 1510. The touchpad does not work at all. Earlier fixes through GRUB updates don't seem to work. External USB mouse works fine. Any solution will be greatly appreciated!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Thomas Hood (jdthood)]

@Matt, Ullaspa: Can you reproduce the problem under Ubuntu 12.04?

[ullaspa (ullaspa)]

@jdthood, I'm on 12.04, but on a different laptop. I have not encountered this issue on my current Samsung NP350U2B. I don't have access to the Dell Vostro 1510 anymore.

[Thomas Hood (jdthood)]

Can any contributor to this bug report reproduce the bug (touchpad or other input device stops working when 3G or Wi-Fi is configured) under Ubuntu 12.04?

[dino99 (9d9)]

closing as there is no answer