Bug 42868
| Summary: | [SNB] DP->DVI dongle causes high mouse pointer latency | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | kolAflash (kolAflash) |
| Component: | Video(DRI - Intel) | Assignee: | intel-gfx-bugs (intel-gfx-bugs) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | alan, chris, daniel, intel-gfx-bugs, jbarnes, przanoni |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.0.0 + 3.1.9 + 3.2.6 + 3.9.rc8 + | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg output before and after bug appeared
latencytop output |
||
|
Description
kolAflash
2012-03-05 09:42:48 UTC
Hi I do have an x220, and I couldn't reproduce the problem. I connected a DVI monitor to the DP port (through dp/dvi adapter) and the mouse seems as fast as before. I don't have the UMTS card. I remember other people are also complaining that the UMTS card makes x220 become unstable/buggy: - http://richardhartmann.de/blog/posts/2012/02/Lenovo-hardware-quality/ - http://richardhartmann.de/blog/posts/2012/03/11-Lenovo-software-quality/ Are you experiencing other stability problems after you connected the UMTS cart? Hi, sometimes the x220 doesn't wakes up correctly from hibernate to disk. But I didn't tested this with different distributions (openSUSE 12.1 only) and I'm not sure that it didn't happened without UMTS. Does your x220 has a SandyBridge cpu too? Maybe it has something to do with the adapter I use. I'll see if I can get another one for testing. (In reply to comment #2) > Does your x220 has a SandyBridge cpu too? Maybe it has something to do with > the > adapter I use. I'll see if I can get another one for testing. Yes: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz Please retest with the latest 3.3 kernel. Also can you run vmstat 1 while your mouse is slow and a few lines of the output (please pick a section where you have _not_ moved the mouse). Hi, today at first I was NOT able to reproduce the problem! Not with the openSUSE Kernel 3.1 of my everyday-system, not with 3.3 and even not with the openSUSE 12.1 LiveCD (Kernel 3.1 too) I already used for testing when reporting the bug. All that testing I did WITH ac power. A few hours later I tested WITHOUT ac power (just battery) and the problem reappeared (also with Kernel 3.3). A few times I reconnected ac and disconnected it again and rebooted the system. One time I did a full shutdown, not a reboot and no ac attached, but battery attached. After reattaching ac and starting the laptop the problem didn't appeared and everything was fine. But after disconnecting ac again the problem reappeared and I wasn't able to reproduce this trick. I also tried blacklisting the kernel modules "ac" and "battery" but this didn't solved the problem too. Conclusion: It seems it may has something to do with the power supply. When ac is detached, the problem will occur more likely. Attached you'll find the "vmstat 1" output, made while DisplayPort=>DVI adapter and screen were attached and mouse was slow (mouse was not moved in the time the vmstat output was made). One more bit of information: I wasn't able to test with another DisplayPort-DVI Adapter. The vendor of the adapter I use is "DELOCK". There isn't any exact product name. Thanks kolAflash procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 1 1 0 6458804 63656 708328 0 0 775 431 583 634 4 12 57 27 0 1 1 0 6462000 65020 702924 0 0 1372 772 2428 1603 1 23 54 22 0 7 1 0 6460732 66908 701272 0 0 1888 0 2600 1752 0 22 58 20 0 1 1 0 6451636 68244 709524 0 0 1336 0 2551 1747 1 23 55 21 0 1 2 0 6455744 69820 702332 0 0 2032 0 2705 1890 1 22 53 24 0 1 1 0 6450260 71084 703524 0 0 2040 4 2610 1815 1 23 55 22 0 1 1 0 6451804 72084 700796 0 0 992 1652 2211 1247 1 23 58 19 0 2 1 0 6450304 73424 701064 0 0 1328 40 2441 1453 0 23 56 22 0 1 1 0 6444032 77804 702652 0 0 4380 0 3503 3012 1 23 56 20 0 0 1 0 6442864 78952 702524 0 0 1148 0 2355 1303 0 23 54 23 0 1 1 0 6439356 81484 703628 0 0 2532 0 3117 2116 0 22 56 21 0 2 0 0 6436996 83324 703928 0 0 1840 0 2604 1768 0 23 55 21 0 1 1 0 6434136 85364 704272 0 0 2032 36 2821 1818 1 22 57 21 0 1 1 0 6432720 86700 704664 0 0 1336 0 2381 1389 0 22 56 22 0 1 1 0 6428420 89616 705408 0 0 2916 0 3204 2211 1 23 54 22 0 Funky; I still suspect our locking & output detection though. I guess latencytop will be the most useful here. Hm, we do have a fair amount of interrupts for and otherwise supposedly idle system in vmstat 1. And presuming it's a hpd irq storm causing the about 20-25% of system load (i.e. an entire thread on a presumably 4T/2C machine), that explains neatly why you can't move the mouse any more. Can you please add drm.debug=0xe to your kernel cmdline, reproduce the problem and attach the complete dmesg (if it scrolls past the beginning, please grab dmesg once after boot and once after you've reproduced the issue). Created attachment 82891 [details]
dmesg output before and after bug appeared
Didn't used DisplayPort for some time. But now I had time to boot with "drm.debug=0xe" and to reproduce the bug. Here comes the dmesg output.
Tested with another DisplayPort => DVI adapter from the office I'm right now. Looks like this one doesn't triggers the problems. But I'm not quite sure, because I just plugged in/out it a few times and as I said the problem does not always appear! This is written on the adapter from the office: BizLink ks N14939 BZL-K810009(B) ICES-003 CLASS B D31902 I also tested again with the DisplayPort => DVI adapter I normally use. I had a look at the CPU usage when the bug appears and it rises from about 8% (total over all cores/hyperthreads) to about 23%. Created attachment 82941 [details]
latencytop output
I never used latencytop until now (just heard of). Is this output OK?
If you need another latencytop output:
Do I have to set any options/do anything else? Should I select an other process then Xorg? How can I recognize if a value is bad?
Ok, this is another case where we need serious improvements in - finer-grained kms locking, see bug #41892 - hpd filtering/exponential delay until we reach the 10s polling interval to paper over noisy lines (this bugs here specifically). Bug update: - kms locking rework is merged into 3.9 - we are on track to get the hpd irq storm handling in for 3.10! Thanks for the feedback! I'm sorry I forgot a little about this bug report, because in the meantime I just bought another adapter and it's working as good as the one I tried in the office I'm working (which means no mouse-pointer lag and no change in cpu usage). Nevertheless I just did a test with my bad old adapter and the 3.9.rc8 Kernel I got precompiled from openSUSE: http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ kernel-default-3.9.rc8-1.1.x86_64.rpm 25-Apr-2013 09:18 Results: - No mouse pointer lag. - But cpu usage (2 physical, 4 logical core) raises from about 1% to about 24% (25% = 1 logical core at 100%) when adapter with monitor attached is being plugged it. This already happends before I do any changes to my screen setup (xrandr) to actually get a picture on the second monitor. And the cpu also stays at that high usage after I used xrandr to turn the second monitor on. Without a monitor attached to the adapter anything happens at all. I'll try to think on testing this again when 3.10 is out. If I forget, feel free to write me an email. Cool, the kms locking rework works as expected. Next, can you please test drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel to check whether the hpd irq storm mitigation also works? That should completely fix the constantly busy cpu core. I'm pretty sure we can close this as fixed, but I'd like to have confirmation first. Did a new test with these kernels: http://download.opensuse.org/repositories/Kernel:/HEAD/standard/x86_64/kernel-default-3.10.rc4-3.1.gfc06ef7.x86_64.rpm http://download.opensuse.org/repositories/Kernel:/vanilla/standard/x86_64/kernel-vanilla-3.10.rc4.214.g1612e11-1.1.x86_64.rpm http://download.opensuse.org/repositories/Kernel:/stable/standard/x86_64/kernel-desktop-3.9.4-1.1.g51bf0ff.x86_64.rpm All kernels don't show this bug anymore! Also kernel-desktop-3.9.4-1.1.g51bf0ff.x86_64.rpm The cpu usage stays at about 1% to 3% when I plug in the dongle and also when I actually switch on the external monitor. One problem: kernel-default-3.10.rc4-3.1.gfc06ef7.x86_64.rpm made my notebook become quite hot after a few minutes. But I couldn't see any significant cpu or gpu (using powertop) usage. But this probably hasn't something to do with this bug. Maybe it's just the patches openSUSE does on it's kernels. Thanks a lot for the help!!! Nice that it works now for you and thanks for reporting back. |