[Intel-gfx] S3 causing IRQ delivery mismatch - i915 hotplug storm

[Ben Guthro]

I'm trying to debug an issue on an older lapop (Toshiba Satellite A505) -
that has an i3 processor (M330) - and intel graphics.
This is running under Xen-unstable, and a 3.7-rc4 pvops kernel - but can
also be reproduced using kernels as old as 3.2.23 - and hypervisors as old
as 4.0.4

(I have cross posted here, because I am not yet sure if this is a Xen,
pvops, or i915 issue - and would appreciate opinions in sorting it out.)

The symptoms of the problem exhibit themselves by a lagging mouse in X11
after resume, when using the trackpad.

After digging in a bit, the problem seems a bit more insidious - the i915
kworker responsible for hotplug detection (i915_hotplug_work_func) seems to
be getting triggered for every PS2 IRQ - every trackpad mouse movement, and
keypress triggers tracing (with drm.debug=0x06) like the following:

Nov 6 21:41:58 rusting kernel: [ 263.924454] [drm:i915_hotplug_work_func],
running encoder hotplug functions
Nov 6 21:41:58 rusting kernel: [ 263.924468]
[drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf40018,
result 0
Nov 6 21:41:58 rusting kernel: [ 263.924472] [drm:intel_crt_detect], CRT
not detected via hotplug
Nov 6 21:41:58 rusting kernel: [ 263.924475] [drm:output_poll_execute],
[CONNECTOR:11:VGA-1] status updated from 2 to 2
Nov 6 21:41:58 rusting kernel: [ 263.926771] [drm:drm_do_probe_ddc_edid],
drm: skipping non-existent adapter i915 gmbus dpc
Nov 6 21:41:58 rusting kernel: [ 263.926775] [drm:output_poll_execute],
[CONNECTOR:14:HDMI-A-1] status updated from 2 to 2
Nov 6 21:41:58 rusting kernel: [ 263.927291] [drm:intel_dp_aux_ch],
dp_aux_ch timeout status 0x5145003e
Nov 6 21:41:58 rusting kernel: [ 263.944207] [drm:intel_dp_aux_ch],
dp_aux_ch timeout status 0x5145003e
Nov 6 21:41:58 rusting kernel: [ 263.964201] [drm:intel_dp_aux_ch],
dp_aux_ch timeout status 0x5145003e
Nov 6 21:41:58 rusting kernel: [ 263.983694] [drm:intel_dp_detect], DPCD:
0000000000000000
Nov 6 21:41:58 rusting kernel: [ 263.983704] [drm:output_poll_execute],
[CONNECTOR:17:DP-1] status updated from 2 to 2

Additionally, this same trace stack is printed out at a regular 10s
interval, after resume - where prior to resuming from S3 it is printed out
once at boot time.

This kworker consumes a significant portion of the cpu, and essentially
grinds Xorg to a halt, until the probing can catch up with the user moving
the cursor.


There seems to be a mismatch for these IRQ delivery - or at least exhibits
the behavior similar to such a problem.


Does anyone have any thoughts as to where in the software stack I should
start to dig in?
Any opinions on which component likely contains the issue is appreciated.


/btg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20121107/5224857b/attachment.html>