On 04/06/2012 11:31 PM, Jiri Slaby wrote:
On 03/30/2012 02:24 PM, Chris Wilson wrote:
On Fri, 30 Mar 2012 14:11:47 +0200, Jiri Slaby jslaby@suse.cz wrote:
On 03/30/2012 12:45 PM, Chris Wilson wrote:
On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby jslaby@suse.cz wrote:
I don't know what to dump more, because iir is obviously zero too. What other sources of interrupts are on the (G33) chip?
IIR is the master interrupt, with chained secondary interrupt statuses. If IIR is 0, the interrupt wasn't raised by the GPU.
This does not make sense, the handler does something different. Even if IIR is 0, it still takes a look at pipe stats.
That was introduced in 05eff845a28499762075d3a72e238a31f4d2407c to close a race where the pipestat triggered an interrupt after we processed the secondary registers and before reseting the primary.
But the basic premise that we should only enter the interrupt handler with IIR!=0 holds (presuming non-shared interrupt lines such as MSI).
Ok, this behavior is definitely new. I get several "nobody cared" about this interrupt a week. This never used to happen. And something weird emerges in /proc/interrupts when this happens: 42: 1003292 1212890 PCI-MSI-edge �s����:0000:00:02.0 instead of 42: 1006715 1218472 PCI-MSI-edge i915@pci:0000:00:02.0
See the difference of drm_device->devname:
Before: 20 34 32 3a 20 20 20 20 31 34 30 35 34 36 32 20 | 42: 1405462 | 20 20 20 31 37 32 38 33 30 32 20 20 20 50 43 49 | 1728302 PCI| 2d 4d 53 49 2d 65 64 67 65 20 20 20 20 20 20 69 |-MSI-edge i| 39 31 35 40 70 63 69 3a 30 30 30 30 3a 30 30 3a |915@pci:0000:00:| 30 32 2e 30 0a |02.0.|
After: 20 34 32 3a 20 20 20 20 31 30 30 33 32 39 32 20 | 42: 1003292 | 20 20 20 31 32 31 32 38 39 30 20 20 20 50 43 49 | 1212890 PCI| 2d 4d 53 49 2d 65 64 67 65 20 20 20 20 20 20 ef |-MSI-edge .| bf bd 73 ef bf bd ef bf bd ef bf bd ef bf bd 3a |..s............:| 30 30 30 30 3a 30 30 3a 30 32 2e 30 0a |0000:00:02.0.|
Any idea what "ef bf bd" pattern could be? And who *shifts* the "0000:00:02.0" string?
thanks,