Bug #957298 “Mouse is very slow after starting a session on Prec...” : Bugs : linux package : Ubuntu

Revision history for this message

Marc Tardif (cr3) wrote on 2012-03-16:

#1

BootDmesg.txt Edit (65.3 KiB, text/plain; charset="utf-8")
BootLog.gz Edit (685 bytes, application/x-gzip)
CurrentDmesg.txt Edit (5.4 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (4.9 KiB, text/plain; charset="utf-8")
DpkgLog.txt Edit (1.4 MiB, text/plain; charset="utf-8")
GconfCompiz.txt Edit (28.0 KiB, text/plain; charset="utf-8")
LightdmLog.txt Edit (3.0 KiB, text/plain; charset="utf-8")
Lspci.txt Edit (14.4 KiB, text/plain; charset="utf-8")
Lsusb.txt Edit (561 bytes, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (1.5 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (96 bytes, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (1.9 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (2.2 KiB, text/plain; charset="utf-8")
UdevDb.txt Edit (116.3 KiB, text/plain; charset="utf-8")
UdevLog.txt Edit (261.5 KiB, text/plain; charset="utf-8")
UnitySupportTest.txt Edit (608 bytes, text/plain; charset="utf-8")
XorgLog.txt Edit (33.9 KiB, text/plain; charset="utf-8")
XorgLogOld.txt Edit (33.2 KiB, text/plain; charset="utf-8")
Xrandr.txt Edit (4.4 KiB, text/plain; charset="utf-8")
peripherals.txt Edit (732 bytes, text/plain; charset="utf-8")
xdpyinfo.txt Edit (9.7 KiB, text/plain; charset="utf-8")
xinput.txt Edit (834 bytes, text/plain; charset="utf-8")

Revision history for this message

Marc Tardif (cr3) wrote on 2012-03-16:

#2

Creating a basic xorg.conf file and adding these lines works around the problem:

Section "Monitor"
Identifier "HDMI1"
Option "Ignore" "True"
EndSection

Section "Monitor"
Identifier "HDMI2"
Option "Ignore" "True"
EndSection

Section "Monitor"
Identifier "DP1"
Option "Ignore" "True"
EndSection

Section "Monitor"
Identifier "DP2"
Option "Ignore" "True"
EndSection

Section "Monitor"
Identifier "DP3"
Option "Ignore" "True"
EndSection

Revision history for this message

Bryce Harrington (bryce) wrote on 2012-03-16:

#3

Marc, thanks. Can you do a bit more experimentation?

It's possible only one of the outputs are causing the problem, or else only the DP or only the HDMI. Can you test dropping those sections one by one to see which are actually required?

Also, you told me on irc that it doesn't have any displayport connectors wired up. Are there any HDMI ports?

Oh, and also sometimes laptops will have support for these so they can be used with a docking station. Any chance you have the docking station for this hardware? If so, what graphics ports does it have?

affects:	xorg (Ubuntu) → xserver-xorg-video-intel (Ubuntu)
Changed in xserver-xorg-video-intel (Ubuntu):
status:	New → Incomplete
importance:	Undecided → High
Changed in linux (Ubuntu):
importance:	Undecided → High
tags:	added: kernel-handoff-graphics

Revision history for this message

Bryce Harrington (bryce) wrote on 2012-03-16:

#4

@Kernel team - this will need a hardware quirk added to disable the phantom output(s).

Revision history for this message

Marc Tardif (cr3) wrote on 2012-03-16:

#5

I'll try removing the entries one by one to report the problematic one(s) later. For now, I can tell you that I only see a VGA port on the side of my laptop. The other ports are probably used by the docking station but I don't have one, nor do I know anyone with one.

Revision history for this message

Bryce Harrington (bryce) wrote on 2012-03-16:

#6

Thanks, I'll wait to ping kernel folks until you've had a chance to do that testing.

Hmm, referencing this on X200 docking stations:
http://forums.lenovo.com/t5/X-Series-ThinkPad-Laptops/Docking-Station-options-for-X200-X200s-X201-X201s-X201i-X201si/ta-p/400573

Ultrabase has 1 VGA, 1 DisplayPort

So, guessing we can safely disable all the HDMI ports, but need to leave at least one DP port on.

Changed in xserver-xorg-video-intel (Ubuntu):
status:	Incomplete → New
status:	New → Incomplete

Brad Figg (brad-figg) on 2012-03-16

Changed in linux (Ubuntu):
status:	New → Confirmed

Joseph Salisbury (jsalisbury) on 2012-03-16

tags:

added: kernel-da-key

Revision history for this message

Marc Tardif (cr3) wrote on 2012-03-20:

#7

I haven't had an opportunity to test all the permutations of disabling the various ports in xorg.conf, but I have noticed the same problem of the slow mouse even with all the ports disabled except for LVDS1 and VGA1. So, the problem seems to be difficult to reproduce consistently and might not even be related to disabling certain ports.

Bryce Harrington (bryce) on 2012-03-23

Changed in xserver-xorg-video-intel (Ubuntu):
status:	Incomplete → New

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012-04-03:

#8

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

Changed in xserver-xorg-video-intel (Ubuntu):
status:	New → Confirmed

Revision history for this message

Assaf Shachar (asaf60) wrote on 2012-04-03:

#9

I have had similar problems but the mouse is slow only on the login screen (e.g. similar to bug #947761).
After login its working fine. I have an ATI graphic card and HDMI connection on AMD x86_64.
Kernel driver in use: radeon.

Revision history for this message

Chris Cheney (ccheney) wrote on 2012-05-24:

#10

I tried adding the lines in #2 to a xorg.conf file but it didn't seem to help for my ThinkPad X200. The mouse is barely usable and I see high cpu usage for kworker in top. It happens every time I use my laptop, but usually not for the first few minutes, so if there is a good way to debug kworker issues I could probably help track down the problem.

Revision history for this message

Chris Cheney (ccheney) wrote on 2012-05-24:

#11

This seems to fix the problem:

http://souriguha.wordpress.com/2011/03/08/how-to-solve-problem-with-thinkpadkslowd-kworker-on-linux-kernel-2-35-2-36/

And yes this problem existed before 12.04, at least in 11.10 as well, but it didn't seem to happen nearly as often.

Revision history for this message

Endre Kollár (taxy443) wrote on 2012-12-11:

#12

I brought some duplication. Each VGA type is "Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42]" , but you should also check.

Revision history for this message

Endre Kollár (taxy443) wrote on 2012-12-11:

#13

Kernel started with drm.debug=0x02 parameter.

Hotplug events located in the attachment:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088017/+attachment/3454901/+files/kern.log.gz

Revision history for this message

Michael von Glasow (michael-vonglasow) wrote on 2013-01-19:

#15

Works for me too. I've tried

#echo N> /sys/module/drm_kms_helper/parameters/poll

manually every time I had the issue, and that would fix it. Now I've automated the step. Not sure if it has any side effects, though.

Revision history for this message

Endre Kollár (taxy443) wrote on 2013-01-19:

#16

Thanks Chris Cheney! The events hasn't come for a long time.

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9

"Polling for a VGA device on an old system can be quite expensive,
causing latencies on the order of 600ms. As we hold the mode mutex for
this time and also need the same mutex to move the cursor, we trigger a
user-visible stall."

Old system?

"The real solution would involve improving the granulatity of the
locking and so perhaps performing some of the probing not under the lock
or some other updates can be done under different locks. Also reducing the
cost of probing for a non-existent monitor would be worthwhile. However,
exposing a parameter to disable polling is a simple workaround in the
meantime."

Why not default at least?

"This is coupled to the user calling xrandr"(not automatically when polling is disapled) "since the information on the connection has just been updated."(from the newly connected screen)

Revision history for this message

Chris Wilson (ickle) wrote on 2013-02-11:

#17

Because disabling polling would cause a regression for systems that require probing for output hotplug detection. The finer grained locking rework has landed for 3.9... In the meantime the fixes are available through the stable updates.

Changed in linux (Ubuntu):
status:	Confirmed → Fix Released
Changed in xserver-xorg-video-intel (Ubuntu):
status:	Confirmed → Invalid

Revision history for this message

Chris Cheney (ccheney) wrote on 2013-04-18:

#18

This doesn't appear to actually be fixed and the workaround of running the below command no longer works on Ubuntu 13.04 with linux 3.8.0-18. Is there a way to get the fix from 3.9 into 13.04? My system is so unresponsive at times, and it happens fairly often, that I can't do anything with the mouse.

echo N> /sys/module/drm_kms_helper/parameters/poll

Chris

--

top - 09:59:42 up 22:10, 3 users, load average: 1.35, 1.28, 1.24
Tasks: 221 total, 2 running, 217 sleeping, 0 stopped, 2 zombie
%Cpu(s): 7.6 us, 3.6 sy, 0.0 ni, 87.4 id, 1.1 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem: 8066804 total, 4829292 used, 3237512 free, 193440 buffers
KiB Swap: 8388604 total, 0 used, 8388604 free, 1562576 cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12989 root 20 0 0 0 0 R 18.3 0.0 0:12.93 kworker/u:1
12950 root 20 0 0 0 0 S 12.2 0.0 0:20.25 kworker/0:0
13166 ccheney 20 0 20636 1404 1012 R 12.2 0.0 0:00.02 top
1083 root 20 0 361m 51m 37m S 6.1 0.7 4:34.74 Xorg
4791 ccheney 20 0 879m 176m 49m S 6.1 2.2 9:48.62 chromium-browse
12992 ccheney 20 0 648m 21m 13m S 6.1 0.3 0:00.41 gnome-terminal
    1 root 20 0 26940 2744 1424 S 0.0 0.0 0:01.54 init
    2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
    3 root 20 0 0 0 0 S 0.0 0.0 0:03.21 ksoftirqd/0
    5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
    7 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/u:0H
    8 root rt 0 0 0 0 S 0.0 0.0 0:04.47 migration/0
    9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
   10 root 20 0 0 0 0 S 0.0 0.0 0:05.33 rcu_sched
   11 root rt 0 0 0 0 S 0.0 0.0 0:02.92 watchdog/0
   12 root rt 0 0 0 0 S 0.0 0.0 0:02.28 watchdog/1
   13 root 20 0 0 0 0 S 0.0 0.0 0:02.42 ksoftirqd/1
ccheney@x200:~$

This doesn't appear to actually be fixed and the workaround of running the below command no longer works on Ubuntu 13.04 with linux 3.8.0-18. Is there a way to get the fix from 3.9 into 13.04? My system is so unresponsive at times, and it happens fairly often, that I can't do anything with the mouse.

echo N> /sys/module/drm_kms_helper/parameters/poll

Chris

--

top - 09:59:42 up 22:10,  3 users,  load average: 1.35, 1.28, 1.24
Tasks: 221 total,   2 running, 217 sleeping,   0 stopped,   2 zombie
%Cpu(s):  7.6 us,  3.6 sy,  0.0 ni, 87.4 id,  1.1 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem:   8066804 total,  4829292 used,  3237512 free,   193440 buffers
KiB Swap:  8388604 total,        0 used,  8388604 free,  1562576 cached

PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND           
12989 root      20   0     0    0    0 R  18.3  0.0   0:12.93 kworker/u:1       
12950 root      20   0     0    0    0 S  12.2  0.0   0:20.25 kworker/0:0       
13166 ccheney   20   0 20636 1404 1012 R  12.2  0.0   0:00.02 top               
 1083 root      20   0  361m  51m  37m S   6.1  0.7   4:34.74 Xorg              
 4791 ccheney   20   0  879m 176m  49m S   6.1  2.2   9:48.62 chromium-browse   
12992 ccheney   20   0  648m  21m  13m S   6.1  0.3   0:00.41 gnome-terminal    
    1 root      20   0 26940 2744 1424 S   0.0  0.0   0:01.54 init              
    2 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kthreadd          
    3 root      20   0     0    0    0 S   0.0  0.0   0:03.21 ksoftirqd/0       
    5 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/0:0H      
    7 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/u:0H      
    8 root      rt   0     0    0    0 S   0.0  0.0   0:04.47 migration/0       
    9 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcu_bh            
   10 root      20   0     0    0    0 S   0.0  0.0   0:05.33 rcu_sched         
   11 root      rt   0     0    0    0 S   0.0  0.0   0:02.92 watchdog/0        
   12 root      rt   0     0    0    0 S   0.0  0.0   0:02.28 watchdog/1        
   13 root      20   0     0    0    0 S   0.0  0.0   0:02.42 ksoftirqd/1       
ccheney@x200:~$

Revision history for this message

Michael Völker (volmi) wrote on 2013-04-18:

#19

I agree, the problem reappeared with Kernel 3.8 and there is no workaround. I don't use ubuntu anymore, but Debian Testing and the Liquorix Kernel 3.8-6.dmz.1.

Revision history for this message

Chris Cheney (ccheney) wrote on 2013-04-18:

#20

Brad Figg is having me test out linux 3.8.0-19.29 to see if that resolves the problem. I'll report back here after I have tested it for a bit.

Revision history for this message

Chris Cheney (ccheney) wrote on 2013-04-18:

#21

Download full text (4.9 KiB)

That doesn't appear to have fixed it.

Linux x200 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

top - 11:09:46 up 23 min, 2 users, load average: 1.44, 1.08, 0.78
Tasks: 213 total, 3 running, 210 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7.1 us, 4.1 sy, 0.1 ni, 84.6 id, 3.9 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem: 8066804 total, 3246492 used, 4820312 free, 80652 buffers
KiB Swap: 8388604 total, 0 used, 8388604 free, 979268 cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5746 root 20 0 0 0 0 R 18.5 0.0 0:27.30 kworker/u:67
    4 root 20 0 0 0 0 S 6.2 0.0 0:30.21 kworker/0:0
5215 ccheney 20 0 967m 116m 20m S 6.2 1.5 0:06.89 chromium-browse
6159 ccheney 20 0 20636 1436 1012 R 6.2 0.0 0:00.02 top
    1 root 20 0 26940 2716 1412 S 0.0 0.0 0:01.02 init
    2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
    3 root 20 0 0 0 0 S 0.0 0.0 0:00.33 ksoftirqd/0
    5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
    7 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/u:0H
    8 root rt 0 0 0 0 S 0.0 0.0 0:00.20 migration/0
    9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
   10 root 20 0 0 0 0 S 0.0 0.0 0:00.56 rcu_sched
   11 root rt 0 0 0 0 S 0.0 0.0 0:00.08 watchdog/0
   12 root rt 0 0 0 0 S 0.0 0.0 0:00.12 watchdog/1
   13 root 20 0 0 0 0 S 0.0 0.0 0:00.30 ksoftirqd/1
   16 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H
   17 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 cpuset
   18 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 khelper
   19 root ...

That doesn't appear to have fixed it.

Linux x200 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

top - 11:09:46 up 23 min,  2 users,  load average: 1.44, 1.08, 0.78
Tasks: 213 total,   3 running, 210 sleeping,   0 stopped,   0 zombie
%Cpu(s):  7.1 us,  4.1 sy,  0.1 ni, 84.6 id,  3.9 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem:   8066804 total,  3246492 used,  4820312 free,    80652 buffers
KiB Swap:  8388604 total,        0 used,  8388604 free,   979268 cached

PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                       
 5746 root      20   0     0    0    0 R  18.5  0.0   0:27.30 kworker/u:67                                                                  
    4 root      20   0     0    0    0 S   6.2  0.0   0:30.21 kworker/0:0                                                                   
 5215 ccheney   20   0  967m 116m  20m S   6.2  1.5   0:06.89 chromium-browse                                                               
 6159 ccheney   20   0 20636 1436 1012 R   6.2  0.0   0:00.02 top                                                                           
    1 root      20   0 26940 2716 1412 S   0.0  0.0   0:01.02 init                                                                          
    2 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kthreadd                                                                      
    3 root      20   0     0    0    0 S   0.0  0.0   0:00.33 ksoftirqd/0                                                                   
    5 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/0:0H                                                                  
    7 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/u:0H                                                                  
    8 root      rt   0     0    0    0 S   0.0  0.0   0:00.20 migration/0                                                                   
    9 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcu_bh                                                                        
   10 root      20   0     0    0    0 S   0.0  0.0   0:00.56 rcu_sched                                                                     
   11 root      rt   0     0    0    0 S   0.0  0.0   0:00.08 watchdog/0                                                                    
   12 root      rt   0     0    0    0 S   0.0  0.0   0:00.12 watchdog/1                                                                    
   13 root      20   0     0    0    0 S   0.0  0.0   0:00.30 ksoftirqd/1                                                                   
   16 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/1:0H                                                                  
   17 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 cpuset                                                                        
   18 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 khelper                                                                       
   19 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kdevtmpfs                                                                     
   20 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 netns                                                                         
   21 root      20   0     0    0    0 S   0.0  0.0   0:00.00 bdi-default                                                                   
   22 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kintegrityd                                                                   
   23 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kblockd                                                                       
   25 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 ata_sff                                                                       
   26 root      20   0     0    0    0 S   0.0  0.0   0:00.00 khubd                                                                         
   27 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 md                                                                            
   28 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 devfreq_wq                                                                    
   30 root      20   0     0    0    0 S   0.0  0.0   0:00.00 khungtaskd                                                                    
   31 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kswapd0                                                                       
   32 root      25   5     0    0    0 S   0.0  0.0   0:00.00 ksmd                                                                          
   33 root      39  19     0    0    0 S   0.0  0.0   0:00.00 khugepaged                                                                    
ccheney@x200:~$

Revision history for this message

Brad Figg (brad-figg) wrote on 2013-04-18:

#22

@chris wilson

Can you give me the upstream SHA1s that you think fix this issue? Chris Cheney has tested our latest kernel which has the 3.8.8 upstream stable fixes in it and is saying the issue still exists.

Revision history for this message

Chris Cheney (ccheney) wrote on 2013-04-18:

#23

I'm testing the latest mainline kernel at the moment from the following location:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-rc7-raring/

I'll report back later today with the outcome.

Revision history for this message

Chris Cheney (ccheney) wrote on 2013-04-18:

#24

So far it appears to be working with the 3.9rc7 mainline kernel without needing the workaround, or at least is taking much longer to trigger the issue. Howevre that kernel is not slated to go into 13.04 so this bug or one of its duplicates probably should be open still instead of 'Fix Released'. I am willing to test out any kernels to help get this issue fixed in 13.04.

Linux x200 3.9.0-030900rc7-generic #201304171402 SMP Wed Apr 17 18:04:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Revision history for this message

Chris Wilson (ickle) wrote on 2013-04-18:

#25

As poll=0 w/a no longer applied, that most likely means you had a different interrupt storm; sudo perf top.

Revision history for this message

Chris Cheney (ccheney) wrote on 2013-04-18:

#26

Thanks, I didn't know about perf top.

Here are the results once the mouse started slowing down:

22.81% [i915] 20.15% [kernel] 13.45% chromium-browser 11.47% [kernel] 3.22% [kernel] 1.95% [vdso] 1.48% perf_3.8.0-18 1.23% libc-2.17.so 0.70% [kernel] 0.70% intel_drv.so 0.64% [i2c_algo_bit] 0.63% Xorg 0.46% [kernel] 0.44% 0.38% libpthread-2.17.so 0.36% 0.34% [kernel] 0.28% [kernel] 0.28% [kernel] 0.24% 0.21% 0.21% libpthread-2.17.so 0.21% [kernel] 0.20% [kernel] 0.20% 0.20% [kernel] 0.17% [kernel] 0.16% perf-3515.map 0.16% 0.16% [i915] 0.16% [kernel] 0.15% [kernel] 0.15% [kernel] 0.14% [kernel] 0.14% [drm] 0.14% [kernel] [k] get_clock
[k] native_read_tsc
[.] 0x00000000014bf515
[k] delay_tsc
[k] read_hpet
[.] 0x0000000000000af7
[.] 0x000000000007c6ce
[.] 0x0000000000081285
[k] __ticket_spin_lock
[.] 0x0000000000060519
[k] sclhi
[.] 0x0000000000063af2
[k] acpi_os_read_port
libglib-2.0.so.0.3600.0 [.] 0x0000000000049168
[.] pthread_mutex_lock
libcairo.so.2.11200.14 [.] 0x0000000000065b9f
[k] fget_light
[k] __schedule
[k] menu_select
libvte2_90.so.9.3400.2 [.] 0x000000000001a438
libharfbuzz.so.0.913.0 [.] 0x0000000000028e44
[.] __pthread_mutex_unlock_usercnt
[k] hpet_legacy_next_event
[k] unix_poll
libglib-2.0.so.0.3600.0 [.] g_hash_table_lookup
[k] clear_page_c
[k] fput
[.] 0x000019dda03af6ec
libgobject-2.0.so.0.3600.0 [.] 0x000000000001b175
[k] i915_read32
[k] _raw_spin_unlock_irqrestore
[k] tg_load_down
[k] _raw_spin_lock_irqsave
[k] int_sqrt
[k] drm_clflush_page
[k] update_sd_lb_stats

Thanks, I didn't know about perf top.

Here are the results once the mouse started slowing down:

22.81%  [i915]                           [k] get_clock
 20.15%  [kernel]                         [k] native_read_tsc
 13.45%  chromium-browser                 [.] 0x00000000014bf515
 11.47%  [kernel]                         [k] delay_tsc
  3.22%  [kernel]                         [k] read_hpet
  1.95%  [vdso]                           [.] 0x0000000000000af7
  1.48%  perf_3.8.0-18                    [.] 0x000000000007c6ce
  1.23%  libc-2.17.so                     [.] 0x0000000000081285
  0.70%  [kernel]                         [k] __ticket_spin_lock
  0.70%  intel_drv.so                     [.] 0x0000000000060519
  0.64%  [i2c_algo_bit]                   [k] sclhi
  0.63%  Xorg                             [.] 0x0000000000063af2
  0.46%  [kernel]                         [k] acpi_os_read_port
  0.44%  libglib-2.0.so.0.3600.0          [.] 0x0000000000049168
  0.38%  libpthread-2.17.so               [.] pthread_mutex_lock
  0.36%  libcairo.so.2.11200.14           [.] 0x0000000000065b9f
  0.34%  [kernel]                         [k] fget_light
  0.28%  [kernel]                         [k] __schedule
  0.28%  [kernel]                         [k] menu_select
  0.24%  libvte2_90.so.9.3400.2           [.] 0x000000000001a438
  0.21%  libharfbuzz.so.0.913.0           [.] 0x0000000000028e44
  0.21%  libpthread-2.17.so               [.] __pthread_mutex_unlock_usercnt
  0.21%  [kernel]                         [k] hpet_legacy_next_event
  0.20%  [kernel]                         [k] unix_poll
  0.20%  libglib-2.0.so.0.3600.0          [.] g_hash_table_lookup
  0.20%  [kernel]                         [k] clear_page_c
  0.17%  [kernel]                         [k] fput
  0.16%  perf-3515.map                    [.] 0x000019dda03af6ec
  0.16%  libgobject-2.0.so.0.3600.0       [.] 0x000000000001b175
  0.16%  [i915]                           [k] i915_read32
  0.16%  [kernel]                         [k] _raw_spin_unlock_irqrestore
  0.15%  [kernel]                         [k] tg_load_down
  0.15%  [kernel]                         [k] _raw_spin_lock_irqsave
  0.14%  [kernel]                         [k] int_sqrt
  0.14%  [drm]                            [k] drm_clflush_page
  0.14%  [kernel]                         [k] update_sd_lb_stats

Revision history for this message

Chris Cheney (ccheney) wrote on 2013-04-18:

#27

I stopped using chromium for a while and then it showed this for the ones in red:

33.43% [i915] [k] get_clock
27.39% [kernel] [k] native_read_tsc
15.74% [kernel] [k] delay_tsc

Revision history for this message

Chris Cheney (ccheney) wrote on 2013-04-18:

#28

Not sure if this is useful but the annotation for get_clock() shows:

get_clock
       │
       │
       │ Disassembly of section .text:
       │
       │ 000000000004cc00 <get_clock>:
  1.85 │ → callq get_clock+0x5
33.32 │ mov 0x360(%rdi),%edx
       │ and $0x2020,%ecx
  0.13 │ mov %ecx,%esi
  0.13 │ or $0x1,%esi
  0.16 │ add 0x18(%rax),%rdx
       │ mov %esi,(%rdx)
  1.08 │ mov 0x360(%rdi),%edx
       │ add 0x18(%rax),%rdx
       │ mov %ecx,(%rdx)
12.09 │ mov 0x360(%rdi),%edx
       │ add 0x18(%rax),%rdx
       │ mov (%rdx),%eax
50.93 │ shr $0x4,%eax
  0.15 │ and $0x1,%eax
  0.16 │ pop %rbp
       │ ← retq
       │ nop
       │ mov $0x1,%esi
       │ xor %ecx,%ecx
       │ ↓ jmp 4cc16
       │ nop
       │ 4cc80: callq 4cc85 <i915_drm_freeze+0x4cc55>
       │ 4cc85: mov 0x3a8(%rdi),%rax
       │ 4cc8c: push %rbp
       │ 4cc8d: mov 0x360(%rdi),%edx
       │ 4cc93: mov %rsp,%rbp
       │ 4cc96: mov (%rax),%rcx
       │ 4cc99: mov 0x30c(%rcx),%ecx
       │ 4cc9f: cmp $0x2562,%ecx
       │ 4cca5: je 4ccf0 <i915_drm_freeze+0x4ccc0>

Revision history for this message

Chris Cheney (ccheney) wrote on 2013-04-19:

#29

I see lots of kworker cpu usage on 3.9rc7 today but my mouse isn't slowing down. I can't run perf top to see why on that version due to the following:

# perf top
perf_3.9.0-030900rc7 not found
You may need to install linux-tools-3.9.0-030900rc7

Which does not appear to be available.

--

top - 12:26:05 up 20:21, 3 users, load average: 0.92, 0.87, 0.86
Tasks: 247 total, 4 running, 242 sleeping, 0 stopped, 1 zombie
%Cpu(s): 2.1 us, 7.3 sy, 0.0 ni, 88.4 id, 1.8 wa, 0.0 hi, 0.4 si, 0.0 st
KiB Mem: 8066360 total, 5332144 used, 2734216 free, 246624 buffers
KiB Swap: 8388604 total, 0 used, 8388604 free, 1293252 cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10735 root 20 0 0 0 0 S 10.3 0.0 0:34.59 kworker/u:2
10802 root 20 0 0 0 0 R 7.0 0.0 0:11.06 kworker/u:3
  648 root 20 0 0 0 0 R 4.3 0.0 3:15.49 kworker/1:2
10615 root 20 0 0 0 0 S 3.6 0.0 0:51.88 kworker/0:2
2708 ccheney 20 0 881m 211m 48m S 1.7 2.7 17:13.53 chromium-browse
  689 root -51 0 0 0 0 S 1.0 0.0 3:36.76 irq/46-iwlwifi
2785 ccheney 20 0 1378m 426m 29m S 1.0 5.4 12:41.83 chromium-browse
7037 ccheney 20 0 606m 74m 28m R 1.0 0.9 8:04.97 chromium-browse
1151 root 20 0 291m 37m 26m S 0.7 0.5 4:11.79 Xorg
9946 ccheney 20 0 649m 21m 13m S 0.7 0.3 0:00.85 gnome-terminal
10951 root 20 0 20640 1608 1084 R 0.7 0.0 0:00.03 top
2488 ccheney 20 0 571m 19m 13m S 0.3 0.2 0:09.67 indicator-apple
2743 ccheney 20 0 933m 124m 15m S 0.3 1.6 3:04.22 chromium-browse
2854 ccheney 20 0 935m 74m 20m S 0.3 0.9 0:58.86 chromium-browse
3365 ccheney 20 0 977m 139m 21m S 0.3 1.8 1:31.61 chromium-browse
7483 ccheney 20 0 951m 77m 21m S 0.3 1.0 0:09.68 chromium-browse
10695 ccheney 20 0 949m 76m 20m S 0.3 1.0 0:05.38 chromium-browse

I see lots of kworker cpu usage on 3.9rc7 today but my mouse isn't slowing down. I can't run perf top to see why on that version due to the following:

# perf top
perf_3.9.0-030900rc7 not found
You may need to install linux-tools-3.9.0-030900rc7

Which does not appear to be available.

--

top - 12:26:05 up 20:21,  3 users,  load average: 0.92, 0.87, 0.86
Tasks: 247 total,   4 running, 242 sleeping,   0 stopped,   1 zombie
%Cpu(s):  2.1 us,  7.3 sy,  0.0 ni, 88.4 id,  1.8 wa,  0.0 hi,  0.4 si,  0.0 st
KiB Mem:   8066360 total,  5332144 used,  2734216 free,   246624 buffers
KiB Swap:  8388604 total,        0 used,  8388604 free,  1293252 cached

PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND           
10735 root      20   0     0    0    0 S  10.3  0.0   0:34.59 kworker/u:2       
10802 root      20   0     0    0    0 R   7.0  0.0   0:11.06 kworker/u:3       
  648 root      20   0     0    0    0 R   4.3  0.0   3:15.49 kworker/1:2       
10615 root      20   0     0    0    0 S   3.6  0.0   0:51.88 kworker/0:2       
 2708 ccheney   20   0  881m 211m  48m S   1.7  2.7  17:13.53 chromium-browse   
  689 root     -51   0     0    0    0 S   1.0  0.0   3:36.76 irq/46-iwlwifi    
 2785 ccheney   20   0 1378m 426m  29m S   1.0  5.4  12:41.83 chromium-browse   
 7037 ccheney   20   0  606m  74m  28m R   1.0  0.9   8:04.97 chromium-browse   
 1151 root      20   0  291m  37m  26m S   0.7  0.5   4:11.79 Xorg              
 9946 ccheney   20   0  649m  21m  13m S   0.7  0.3   0:00.85 gnome-terminal    
10951 root      20   0 20640 1608 1084 R   0.7  0.0   0:00.03 top               
 2488 ccheney   20   0  571m  19m  13m S   0.3  0.2   0:09.67 indicator-apple   
 2743 ccheney   20   0  933m 124m  15m S   0.3  1.6   3:04.22 chromium-browse   
 2854 ccheney   20   0  935m  74m  20m S   0.3  0.9   0:58.86 chromium-browse   
 3365 ccheney   20   0  977m 139m  21m S   0.3  1.8   1:31.61 chromium-browse   
 7483 ccheney   20   0  951m  77m  21m S   0.3  1.0   0:09.68 chromium-browse   
10695 ccheney   20   0  949m  76m  20m S   0.3  1.0   0:05.38 chromium-browse

Revision history for this message

Endre Kollár (taxy443) wrote on 2013-04-27:

#30

I tested the 13.04 iso. The mouse lagging bug is affact,when i turn the computer on cold. (weird)
New phenomenon: Unity frozen after a short time.

Revision history for this message

Endre Kollár (taxy443) wrote on 2013-04-27:

#31

Please remove the "Fix Released" status from "Ubuntu kernel" task.

Endre Kollár (taxy443) on 2013-04-27

tags:

added: kernel-bug-exists-upstream raring

Revision history for this message

Endre Kollár (taxy443) wrote on 2013-04-29:

#33

Can "drm.debug=0x02" output be interesting?
ccheney: Add to the kernel command line parameters this option . During the phenomenon produces a lines of dmesg(kern.log).

Revision history for this message

Jonatã Bolzan Loss (jbopen) wrote on 2013-07-03:

#34

It seems that a related bug in kernel was fixed (link above). Does installing the kernel 3.10 fix the problem?

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b543fb0464ddf30a5b554957fd212eb7a2acac65

To install it:
cd /tmp
wget http://ubuntued.info/kernels/kernel-3.10.0 -O kernel-3.10.0
chmod +x kernel-3.10.0
sudo sh kernel-3.10.0

Revision history for this message

Michael von Glasow (michael-vonglasow) wrote on 2013-07-14:

#35

I've installed the 3.10 kernel from

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-saucy/

(since I don't like testing on a productive system with non-deb installs that may be hard to uninstall cleanly). According to version number and file time, it should contain the fix (please correct me if I'm wrong). Currently testing, so far things look OK, I'll report results after a few days of testing.

Revision history for this message

Michael von Glasow (michael-vonglasow) wrote on 2013-07-16:

#36

Mouse responsiveness looks OK so far, but there seems to be a regression concerning WiFi/Bluetooth.

When the system comes up, both are disabled and cannot be enabled using the hardware switch (touch button above the keyboard on the HP 6930p). WiFi is reported "disabled by hardware switch" in Gnome Panel. I can enable Bluetooth from Gnome Panel and after that WiFi (also in Gnome Panel), and the LED will go from orange to blue. This started after I upgraded to the 3.10 kernel.

Really a secondary theater of war and I can't rule out that it might be because the kernel was actually built for a later Ubuntu release, but I'd like that to be sorted out before I upgrade my kernel.

I will keep testing until next weekend and then post final results on the mouse issue.

Revision history for this message

Michael von Glasow (michael-vonglasow) wrote on 2013-07-21:

#37

I've tested the 3.10 kernel from the Ubuntu kernel PPA for some more time, and haven't had any more issues with mouse responsiveness, so I guess that's resolved. There's just the issue that I have to manually re-enable Bluetooth and WiFi on every startup.

Revision history for this message

Michael von Glasow (michael-vonglasow) wrote on 2013-08-09:

#38

Any news yet on when there's going to be an official kernel for Precise that contains the fix?

Bug Watch Updater (bug-watch-updater) on 2017-07-25

Changed in linux:
importance:	Unknown → Medium
status:	Unknown → Invalid

Ubuntu
linux package

Mouse is very slow after starting a session on Precise

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

	Status	Importance	Assigned to
Linux	Invalid	Medium	freedesktop-bugs #29536
linux (Ubuntu)	Fix Released	High	Unassigned
xserver-xorg-video-intel (Ubuntu)	Invalid	High	Unassigned

Ubuntulinux package

Mouse is very slow after starting a session on Precise

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
linux package