Bug 74002 - [NVE7] [un]plugging DP-3 on Lenovo W530 results in interrupt storm
Summary: [NVE7] [un]plugging DP-3 on Lenovo W530 results in interrupt storm
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-23 23:38 UTC by Jamin Collins
Modified: 2019-12-04 08:42 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
vbios (37.50 KB, text/plain)
2014-01-23 23:38 UTC, Jamin Collins
no flags Details
Generated interrupts (37.50 KB, text/plain)
2014-01-23 23:39 UTC, Jamin Collins
no flags Details
real vbios (88.50 KB, application/octet-stream)
2014-01-23 23:41 UTC, Jamin Collins
no flags Details
perf report (21.22 KB, text/plain)
2014-01-23 23:42 UTC, Jamin Collins
no flags Details
dmesg output (74.80 KB, text/plain)
2014-01-23 23:44 UTC, Jamin Collins
no flags Details
dmesg output with debugging enabled (794.60 KB, text/plain)
2014-01-24 03:44 UTC, Jamin Collins
no flags Details
Xorg log for normal connections (77.64 KB, text/plain)
2014-01-24 06:25 UTC, Jamin Collins
no flags Details
both sets of displays (141.06 KB, text/plain)
2014-01-24 20:42 UTC, Jamin Collins
no flags Details

Description Jamin Collins 2014-01-23 23:38:42 UTC
Created attachment 92699 [details]
vbios

Running a 3.13 kernel, built from upstream git repository (commit d8ec26d7f8287f5788a494f56e8814210f0e64be).

I'm able to consistently generate an ongoing interrupt storm by [un]docking my Lenovo W530 when using the nouveau driver.  This problem was first noticed under a 3.10 kernel and associated nouveau driver.  I then switched to the above 3.13 kernel for the MSI interrupt support and to see if the problem persisted.

The attached nouveau.interrupts is the output of read_interrupts, the source for which is here: http://www.darnok.org/xen/read_interrupts.c.  This file shows the interrupts generated during 5 second intervals.
Comment 1 Jamin Collins 2014-01-23 23:39:31 UTC
Created attachment 92700 [details]
Generated interrupts
Comment 2 Jamin Collins 2014-01-23 23:41:17 UTC
Created attachment 92701 [details]
real vbios

vbios of the card captured via:
sudo cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom
Comment 3 Jamin Collins 2014-01-23 23:42:47 UTC
Created attachment 92702 [details]
perf report

Linux perf tool report captured during the interrupt storm
Comment 4 Jamin Collins 2014-01-23 23:44:19 UTC
Created attachment 92703 [details]
dmesg output

Requested kernel log
Comment 5 Jamin Collins 2014-01-23 23:45:13 UTC
Comment on attachment 92699 [details]
vbios

Incorrectly labeled upload, sorry.
Comment 6 Jamin Collins 2014-01-24 00:06:36 UTC
Should also note that I attempted booting with the nouveau.config=NvI2C=1 kernel parameter.  However, with this parameter present, both the VT text and splash screen were corrupted (appeared interleaved), there was no display from X (though I could hear the startup sound indicating it had started), and the system was not reliably connected to the network (couldn't ping or ssh to it).
Comment 7 Jamin Collins 2014-01-24 03:44:14 UTC
Created attachment 92709 [details]
dmesg output with debugging enabled

Reproduced the storm with a few additional kernel command line options to increase logging verbosity.
Comment 8 Jamin Collins 2014-01-24 04:36:37 UTC
This xrandr output seems very strange, I don't recall seeing resolutions for disconnected displays before.  Nor, do I recall seeing output like the 6 lines below DP-3:

jcollins@odin:~$ xrandr
Screen 0: minimum 320 x 200, current 5280 x 1080, maximum 8192 x 8192
LVDS-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
   1920x1080      60.0*+   60.0     50.0  
   1680x1050      60.0  
   1400x1050      60.0  
   1280x1024      59.9  
   1280x960       59.9  
   1152x864       60.0  
   1024x768       59.9  
   800x600        59.9  
   640x480        59.4  
   720x400        59.6  
   640x400        60.0  
   640x350        59.8  
VGA-1 disconnected 1440x900+3840+0 (normal left inverted right x axis y axis) 0mm x 0mm
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected 1920x1080+1920+0 (normal left inverted right x axis y axis) 0mm x 0mm
DP-3 disconnected (normal left inverted right x axis y axis)
  1920x1080 (0x77)  148.5MHz
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   67.5KHz
        v: height 1080 start 1084 end 1089 total 1125           clock   60.0Hz
  1440x900 (0x82)  106.5MHz
        h: width  1440 start 1520 end 1672 total 1904 skew    0 clock   55.9KHz
        v: height  900 start  903 end  909 total  934           clock   59.9Hz
Comment 9 Jamin Collins 2014-01-24 04:49:33 UTC
It seems that undocking the laptop is not required to trigger the interrupt storm.  All that is necessary is disconnecting the display connected to DP-3.  As long as DP-3 is never connected, I can dock and undock the laptop repeatedly without triggering the storm.  Simply attaching a monitor to that port and disconnecting it triggers the storm.  Going to try a few other scenarios and report back.
Comment 10 Jamin Collins 2014-01-24 06:25:07 UTC
Created attachment 92716 [details]
Xorg log for normal connections

To further complicate matters, it appears to matter which monitor it is that is connected to DP-3.  If I change the order of the monitors and and place the monitor that is normally connected to DP-2 on DP-3 and the one that is normally connected to DP-3 on DP-2, this problem goes away at least here at home.

Monitor that is normally connected to DP-2:
Manufacturer: DEL  Model: a05c  Serial#: 843992405

Monitor that is normally connected to DP-3:
Manufacturer: GWY  Model: 777  Serial#: 16843009

However, at work the unit is normally connected to three 24" monitors which require the use of DP-3 and trigger this issue as well.  So, simply changing the connection order will only work around the issue at one location.
Comment 11 Jamin Collins 2014-01-24 20:42:00 UTC
Created attachment 92739 [details]
both sets of displays

I've confirmed I can replicate this problem with the displays at work as well.  Attaching an Xorg log containing information for both sets of displays.
Comment 12 Jamin Collins 2014-02-19 16:30:09 UTC
Any update?
Comment 13 patrick.clara 2014-04-05 08:38:00 UTC
Hello Jamin.

I have reported this bug https://bugs.freedesktop.org/show_bug.cgi?id=76732 a week ago. I though that it may be a small possibility that the two bugs are correlated.

You wrote you noticed the bug first in 3.10. Did you ever tested 3.8 (in specific 3.8 rc6) and 3.9? 
Just to understand if the bug appared in 3.10 of if you just noticed it in 3.10.

Thanks
Comment 14 Ilia Mirkin 2014-06-11 23:35:52 UTC
There is a substantial DP rework bound for 3.16. Can you give http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next a shot?
Comment 15 Martin Peres 2019-12-04 08:42:27 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/88.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.