i915 lockup / extreme delay

i915 lockup / extreme delay

[Karl Vogel]

I have been experiencing a very sluggish X server right after starting 
my laptop. The effect goes away after a few minutes, so it was rather 
hard to track down.

Recently after updating WINE to a newer release, I've been able to 
trigger the effect by running a certain game under wine on a remote 
computer and using VirtualGL to transport the GL display to my laptop. 
As I first thought the issue was somewhere with wine/virtualgl, I posted 
the question to the virtualgl mailing list. The thread is here:

http://thread.gmane.org/gmane.comp.video.opengl.virtualgl.user/170

But after some further investigation, it seems the issue is with the 
i915 driver.

The 'effect' is that only the mouse pointer works in the X server. The 
cpu usage on the laptop during the sluggishness is minimal. When I 
suspend the game with winedbg, the X server slowly becomes responsive again.

The output from latencytop seems to point to i915 being the culprit:

Cause                                                Maximum     Percentage
[i915_gem_sw_finish_ioctl]                        3880.2 msec         51.0 %
Throttling GPU while waiting for commands         1337.6 msec         12.1 %
[i915_gem_set_domain_ioctl]                       739.6 msec         10.3 %
mmaping memory                                    275.0 msec          0.9 %
Scheduler: waiting for cpu                        106.1 msec          3.8 %
Executing raw SCSI command                        105.4 msec          0.8 %
fsync() on a file (type 'F' for details)           84.5 msec          0.5 %
[i915_gem_do_execbuffer]                           19.7 msec          0.4 %
[i915_gem_pwrite_ioctl]                            19.7 msec          0.4 %


--
Cause                                                Maximum     Percentage
[i915_gem_sw_finish_ioctl]                        4181.0 msec         57.5 %
[i915_gem_set_domain_ioctl]                       3395.2 msec         35.0 %
Throttling GPU while waiting for commands         742.0 msec          2.7 %
[i915_gem_create_ioctl]                            19.7 msec          0.1 %
[i915_gem_busy_ioctl]                              19.7 msec          0.4 %
[i915_gem_pwrite_ioctl]                            19.6 msec          0.3 %
[i915_gem_madvise_ioctl]                           19.6 msec          1.4 %
[i915_gem_do_execbuffer]                           19.4 msec          0.1 %
[i915_do_wait_request]                              5.0 msec          0.2 %

--
Cause                                                Maximum     Percentage
[i915_gem_set_domain_ioctl]                       4609.5 msec         32.8 %
[i915_gem_sw_finish_ioctl]                        3316.7 msec         52.0 %
[i915_gem_create_ioctl]                           744.1 msec          3.0 %
synchronous write                                 345.9 msec          1.3 %
Executing a program                               109.7 msec          0.4 %
fsync() on a file (type 'F' for details)           87.6 msec          1.0 %
Page fault                                         86.1 msec          0.8 %
Writing a page to disk                             20.1 msec          0.4 %
[i915_gem_madvise_ioctl]                           19.7 msec          3.4 %



These were taken on a Fedora 12 kernel v2.6.32.9-70
I also tried to reproduce it with the latest kernel v2.6.34-rc2, but 
it's much worse with that one, since it causes the laptop to completely 
lockup when I start the game!

I've tried to enable some extra kernel debug options and also setup 
netconsole to see if there is anything reported before the lockup, but 
unfortunately there's no output.

--
Some hardware details:


00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA 
controller])
	Subsystem: Dell Device 024f
	Flags: bus master, fast devsel, latency 0, IRQ 31
	Memory at f6c00000 (64-bit, non-prefetchable) [size=4M]
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at ef98 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: <access denied>
	Kernel driver in use: i915
	Kernel modules: i915

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 07)
	Subsystem: Dell Device 024f
	Flags: bus master, fast devsel, latency 0
	Memory at f6b00000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: <access denied>


X.Org X Server 1.7.5.902 (1.7.6 RC 2)
Release Date: 2010-03-12
X Protocol Version 11, Revision 0

(--) PCI:*(0:0:2:0) 8086:2a42:1028:024f Intel Corporation Mobile 4 
Series Chipset Integrated Graphics Controller rev 7, Mem @ 
0xf6c00000/4194304, 0xe0000000/268435456, I/O @ 0x0000ef98/8, BIOS @ 
0x????????/131072
(--) PCI: (0:0:2:1) 8086:2a43:1028:024f Intel Corporation Mobile 4 
Series Chipset Integrated Graphics Controller rev 7, Mem @ 
0xf6b00000/1048576, BIOS @ 0x????????/65536

(II) LoadModule: "intel"
(II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
(II) Module intel: vendor="X.Org Foundation"
         compiled for 1.7.0, module version = 2.9.1
         Module class: X.Org Video Driver
         ABI class: X.Org Video Driver, version 6.0
(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
         i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
         E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
         965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45,
         4 Series, G45/G43, Q45/Q43, G41, B43, Clarkdale, Arrandale
(II) Primary Device is: PCI 00@00:02:0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 9, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 9, (OK)
drmOpenByBusid: drmOpenMinor returns 9
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(**) intel(0): Depth 24, (--) framebuffer bpp 32
(==) intel(0): RGB weight 888
(==) intel(0): Default visual is TrueColor
(II) intel(0): Integrated Graphics Chipset: Intel(R) GM45
(--) intel(0): Chipset: "GM45"
(II) intel(0): Output LVDS1 has no monitor section
(II) intel(0): found backlight control interface 
/sys/class/backlight/acpi_video0
(II) intel(0): Output VGA1 has no monitor section
(II) intel(0): Output HDMI1 has no monitor section
(II) intel(0): Output DP1 has no monitor section
(II) intel(0): Output HDMI2 has no monitor section
(II) intel(0): Output DP2 has no monitor section
(II) intel(0): Output DP3 has no monitor section
(II) intel(0): Output TV1 has no monitor section
(II) intel(0): EDID for output LVDS1
(II) intel(0): Manufacturer: SEC  Model: 5443  Serial#: 0
(II) intel(0): Year: 2008  Week: 0
(II) intel(0): EDID Version: 1.3
(II) intel(0): Digital Display Input
(II) intel(0): Max Image Size [cm]: horiz.: 33  vert.: 21
(II) intel(0): Gamma: 2.20
(II) intel(0): No DPMS capabilities specified
(II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
(II) intel(0): First detailed timing is preferred mode
(II) intel(0): redX: 0.580 redY: 0.340   greenX: 0.310 greenY: 0.550
(II) intel(0): blueX: 0.155 blueY: 0.155   whiteX: 0.313 whiteY: 0.329
(II) intel(0): Manufacturer's mask: 0
(II) intel(0): Supported detailed timing:
(II) intel(0): clock: 164.2 MHz   Image Size:  331 x 207 mm
(II) intel(0): h_active: 1920  h_sync: 2020  h_sync_end 2052 h_blank_end 
2216 h_border: 0
(II) intel(0): v_active: 1200  v_sync: 1202  v_sync_end 1208 v_blanking: 
1235 v_border: 0
(II) intel(0): Supported detailed timing:
(II) intel(0): clock: 109.5 MHz   Image Size:  331 x 207 mm
(II) intel(0): h_active: 1920  h_sync: 2020  h_sync_end 2052 h_blank_end 
2216 h_border: 0
(II) intel(0): v_active: 1200  v_sync: 1202  v_sync_end 1208 v_blanking: 
1235 v_border: 0
(II) intel(0):  RX392<80>154CT
(II) intel(0):

Re: i915 lockup / extreme delay

[Rafael J. Wysocki]

[Adding CCs]

On Saturday 20 March 2010, Karl Vogel wrote:
> I have been experiencing a very sluggish X server right after starting 
> my laptop. The effect goes away after a few minutes, so it was rather 
> hard to track down.
> 
> Recently after updating WINE to a newer release, I've been able to 
> trigger the effect by running a certain game under wine on a remote 
> computer and using VirtualGL to transport the GL display to my laptop. 
> As I first thought the issue was somewhere with wine/virtualgl, I posted 
> the question to the virtualgl mailing list. The thread is here:
> 
> http://thread.gmane.org/gmane.comp.video.opengl.virtualgl.user/170
> 
> But after some further investigation, it seems the issue is with the 
> i915 driver.
> 
> The 'effect' is that only the mouse pointer works in the X server. The 
> cpu usage on the laptop during the sluggishness is minimal. When I 
> suspend the game with winedbg, the X server slowly becomes responsive again.
> 
> The output from latencytop seems to point to i915 being the culprit:
> 
> Cause                                                Maximum     Percentage
> [i915_gem_sw_finish_ioctl]                        3880.2 msec         51.0 %
> Throttling GPU while waiting for commands         1337.6 msec         12.1 %
> [i915_gem_set_domain_ioctl]                       739.6 msec         10.3 %
> mmaping memory                                    275.0 msec          0.9 %
> Scheduler: waiting for cpu                        106.1 msec          3.8 %
> Executing raw SCSI command                        105.4 msec          0.8 %
> fsync() on a file (type 'F' for details)           84.5 msec          0.5 %
> [i915_gem_do_execbuffer]                           19.7 msec          0.4 %
> [i915_gem_pwrite_ioctl]                            19.7 msec          0.4 %
> 
> 
> --
> Cause                                                Maximum     Percentage
> [i915_gem_sw_finish_ioctl]                        4181.0 msec         57.5 %
> [i915_gem_set_domain_ioctl]                       3395.2 msec         35.0 %
> Throttling GPU while waiting for commands         742.0 msec          2.7 %
> [i915_gem_create_ioctl]                            19.7 msec          0.1 %
> [i915_gem_busy_ioctl]                              19.7 msec          0.4 %
> [i915_gem_pwrite_ioctl]                            19.6 msec          0.3 %
> [i915_gem_madvise_ioctl]                           19.6 msec          1.4 %
> [i915_gem_do_execbuffer]                           19.4 msec          0.1 %
> [i915_do_wait_request]                              5.0 msec          0.2 %
> 
> --
> Cause                                                Maximum     Percentage
> [i915_gem_set_domain_ioctl]                       4609.5 msec         32.8 %
> [i915_gem_sw_finish_ioctl]                        3316.7 msec         52.0 %
> [i915_gem_create_ioctl]                           744.1 msec          3.0 %
> synchronous write                                 345.9 msec          1.3 %
> Executing a program                               109.7 msec          0.4 %
> fsync() on a file (type 'F' for details)           87.6 msec          1.0 %
> Page fault                                         86.1 msec          0.8 %
> Writing a page to disk                             20.1 msec          0.4 %
> [i915_gem_madvise_ioctl]                           19.7 msec          3.4 %
> 
> 
> 
> These were taken on a Fedora 12 kernel v2.6.32.9-70
> I also tried to reproduce it with the latest kernel v2.6.34-rc2, but 
> it's much worse with that one, since it causes the laptop to completely 
> lockup when I start the game!
> 
> I've tried to enable some extra kernel debug options and also setup 
> netconsole to see if there is anything reported before the lockup, but 
> unfortunately there's no output.
> 
> --
> Some hardware details:
> 
> 
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series 
> Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA 
> controller])
> 	Subsystem: Dell Device 024f
> 	Flags: bus master, fast devsel, latency 0, IRQ 31
> 	Memory at f6c00000 (64-bit, non-prefetchable) [size=4M]
> 	Memory at e0000000 (64-bit, prefetchable) [size=256M]
> 	I/O ports at ef98 [size=8]
> 	Expansion ROM at <unassigned> [disabled]
> 	Capabilities: <access denied>
> 	Kernel driver in use: i915
> 	Kernel modules: i915
> 
> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset 
> Integrated Graphics Controller (rev 07)
> 	Subsystem: Dell Device 024f
> 	Flags: bus master, fast devsel, latency 0
> 	Memory at f6b00000 (64-bit, non-prefetchable) [size=1M]
> 	Capabilities: <access denied>
> 
> 
> X.Org X Server 1.7.5.902 (1.7.6 RC 2)
> Release Date: 2010-03-12
> X Protocol Version 11, Revision 0
> 
> (--) PCI:*(0:0:2:0) 8086:2a42:1028:024f Intel Corporation Mobile 4 
> Series Chipset Integrated Graphics Controller rev 7, Mem @ 
> 0xf6c00000/4194304, 0xe0000000/268435456, I/O @ 0x0000ef98/8, BIOS @ 
> 0x????????/131072
> (--) PCI: (0:0:2:1) 8086:2a43:1028:024f Intel Corporation Mobile 4 
> Series Chipset Integrated Graphics Controller rev 7, Mem @ 
> 0xf6b00000/1048576, BIOS @ 0x????????/65536
> 
> (II) LoadModule: "intel"
> (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
> (II) Module intel: vendor="X.Org Foundation"
>          compiled for 1.7.0, module version = 2.9.1
>          Module class: X.Org Video Driver
>          ABI class: X.Org Video Driver, version 6.0
> (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
>          i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
>          E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
>          965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45,
>          4 Series, G45/G43, Q45/Q43, G41, B43, Clarkdale, Arrandale
> (II) Primary Device is: PCI 00@00:02:0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 9, (OK)
> drmOpenByBusid: Searching for BusID pci:0000:00:02.0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 9, (OK)
> drmOpenByBusid: drmOpenMinor returns 9
> drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
> (**) intel(0): Depth 24, (--) framebuffer bpp 32
> (==) intel(0): RGB weight 888
> (==) intel(0): Default visual is TrueColor
> (II) intel(0): Integrated Graphics Chipset: Intel(R) GM45
> (--) intel(0): Chipset: "GM45"
> (II) intel(0): Output LVDS1 has no monitor section
> (II) intel(0): found backlight control interface 
> /sys/class/backlight/acpi_video0
> (II) intel(0): Output VGA1 has no monitor section
> (II) intel(0): Output HDMI1 has no monitor section
> (II) intel(0): Output DP1 has no monitor section
> (II) intel(0): Output HDMI2 has no monitor section
> (II) intel(0): Output DP2 has no monitor section
> (II) intel(0): Output DP3 has no monitor section
> (II) intel(0): Output TV1 has no monitor section
> (II) intel(0): EDID for output LVDS1
> (II) intel(0): Manufacturer: SEC  Model: 5443  Serial#: 0
> (II) intel(0): Year: 2008  Week: 0
> (II) intel(0): EDID Version: 1.3
> (II) intel(0): Digital Display Input
> (II) intel(0): Max Image Size [cm]: horiz.: 33  vert.: 21
> (II) intel(0): Gamma: 2.20
> (II) intel(0): No DPMS capabilities specified
> (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
> (II) intel(0): First detailed timing is preferred mode
> (II) intel(0): redX: 0.580 redY: 0.340   greenX: 0.310 greenY: 0.550
> (II) intel(0): blueX: 0.155 blueY: 0.155   whiteX: 0.313 whiteY: 0.329
> (II) intel(0): Manufacturer's mask: 0
> (II) intel(0): Supported detailed timing:
> (II) intel(0): clock: 164.2 MHz   Image Size:  331 x 207 mm
> (II) intel(0): h_active: 1920  h_sync: 2020  h_sync_end 2052 h_blank_end 
> 2216 h_border: 0
> (II) intel(0): v_active: 1200  v_sync: 1202  v_sync_end 1208 v_blanking: 
> 1235 v_border: 0
> (II) intel(0): Supported detailed timing:
> (II) intel(0): clock: 109.5 MHz   Image Size:  331 x 207 mm
> (II) intel(0): h_active: 1920  h_sync: 2020  h_sync_end 2052 h_blank_end 
> 2216 h_border: 0
> (II) intel(0): v_active: 1200  v_sync: 1202  v_sync_end 1208 v_blanking: 
> 1235 v_border: 0
> (II) intel(0):  RX392<80>154CT
> (II) intel(0):

Re: i915 lockup / extreme delay

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

On Sat, 20 Mar 2010 14:41:41 +0100, Karl Vogel <karl.vogel@gmail.com> wrote:
> I have been experiencing a very sluggish X server right after starting 
> my laptop. The effect goes away after a few minutes, so it was rather 
> hard to track down.
> 
> Recently after updating WINE to a newer release, I've been able to 
> trigger the effect by running a certain game under wine on a remote 
> computer and using VirtualGL to transport the GL display to my laptop. 
> As I first thought the issue was somewhere with wine/virtualgl, I posted 
> the question to the virtualgl mailing list. The thread is here:
> 
> http://thread.gmane.org/gmane.comp.video.opengl.virtualgl.user/170
> 
> But after some further investigation, it seems the issue is with the 
> i915 driver.
> 
> The 'effect' is that only the mouse pointer works in the X server. The 
> cpu usage on the laptop during the sluggishness is minimal. When I 
> suspend the game with winedbg, the X server slowly becomes responsive again.
> 
> The output from latencytop seems to point to i915 being the culprit:

If there's some code doing glFlush()es, it's probably that code at
fault.  You don't need to do that unless you're doing frontbuffer
rendering, and if you're doing frontbuffer rendering you should really
be doing backbuffer rendering.  I don't see a kernel issue here.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: i915 lockup / extreme delay

[Karl Vogel]

On Mon, Mar 22, 2010 at 5:20 AM, Eric Anholt <eric@anholt.net> wrote:
> On Sat, 20 Mar 2010 14:41:41 +0100, Karl Vogel <karl.vogel@gmail.com> wrote:
>> The 'effect' is that only the mouse pointer works in the X server. The
>> cpu usage on the laptop during the sluggishness is minimal. When I
>> suspend the game with winedbg, the X server slowly becomes responsive again.
>>
>> The output from latencytop seems to point to i915 being the culprit:
>
> If there's some code doing glFlush()es, it's probably that code at
> fault.  You don't need to do that unless you're doing frontbuffer
> rendering, and if you're doing frontbuffer rendering you should really
> be doing backbuffer rendering.  I don't see a kernel issue here.

That doesnt explain why the box completely locks up on 2.6.34-rc2
though, where only a cold reboot works.

It also seems a bit odd that 1 opengl application is able to entirely
lockup user interaction of the X server, then again that might be more
of an X issue than a kernel one.. or is it expected behaviour?
(the only thing you can do is wiggle the pointer, nothing else.. no
window selection, no window dragging, not even start new apps that
open windows)

Re: i915 lockup / extreme delay

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

On Mon, 22 Mar 2010 09:11:06 +0100, Karl Vogel <karl.vogel@gmail.com> wrote:
> On Mon, Mar 22, 2010 at 5:20 AM, Eric Anholt <eric@anholt.net> wrote:
> > On Sat, 20 Mar 2010 14:41:41 +0100, Karl Vogel <karl.vogel@gmail.com> wrote:
> >> The 'effect' is that only the mouse pointer works in the X server. The
> >> cpu usage on the laptop during the sluggishness is minimal. When I
> >> suspend the game with winedbg, the X server slowly becomes responsive again.
> >>
> >> The output from latencytop seems to point to i915 being the culprit:
> >
> > If there's some code doing glFlush()es, it's probably that code at
> > fault.  You don't need to do that unless you're doing frontbuffer
> > rendering, and if you're doing frontbuffer rendering you should really
> > be doing backbuffer rendering.  I don't see a kernel issue here.
> 
> That doesnt explain why the box completely locks up on 2.6.34-rc2
> though, where only a cold reboot works.

Missed that part of the message.  If there's a regression, bisect
please.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: i915 lockup / extreme delay

[Karl Vogel]

On Mon, Mar 22, 2010 at 4:34 PM, Eric Anholt <eric@anholt.net> wrote:> On Mon, 22 Mar 2010 09:11:06 +0100, Karl Vogel <karl.vogel@gmail.com> wrote:>> On Mon, Mar 22, 2010 at 5:20 AM, Eric Anholt <eric@anholt.net> wrote:>> > On Sat, 20 Mar 2010 14:41:41 +0100, Karl Vogel <karl.vogel@gmail.com> wrote:>> >> The 'effect' is that only the mouse pointer works in the X server. The>> >> cpu usage on the laptop during the sluggishness is minimal. When I>> >> suspend the game with winedbg, the X server slowly becomes responsive again.>> >>>> >> The output from latencytop seems to point to i915 being the culprit:>> >>> > If there's some code doing glFlush()es, it's probably that code at>> > fault.  You don't need to do that unless you're doing frontbuffer>> > rendering, and if you're doing frontbuffer rendering you should really>> > be doing backbuffer rendering.  I don't see a kernel issue here.>>>> That doesnt explain why the box completely locks up on 2.6.34-rc2>> though, where only a cold reboot works.>> Missed that part of the message.  If there's a regression, bisect> please.
Apparently the crash was caused by a hardware bug in the intel chipsetwhich is 8086:2a40 rev 07. While doing the bisect I got an error:
DRHD: handling fault status reg 2DMAR:[DMA Write] Request device [00:02.0] fault addr dd69a000DMAR:[fault reason 05] PTE Write access is not set
After some googling around, I found this bugzilla entry which explains it:
https://bugzilla.redhat.com/show_bug.cgi?id=538163#c58
The issue appears that the graphics chip is corrupting memory:
"Unfortunately, this particular chipset sometimes reads from the GTT, does thetranslation, then writes the translated address back to the _original_ GTTinstead of to the shadow GTT. That's why you're seeing real physical addresseswhere you should have 'virtual DMA addresses', and you get the faults.   "
Adding "intel_iommu=igfx_off" to the kernel command line resolved the issue.The fedora kernel automatically disables this when it detects this particularchipset revision.
As for the freeze/slowdown right after booting, sysprof shows that more than 77%of the time is spent inside: drm_mode_getconnector
[/usr/bin/Xorg]                                                   0.00%  80.29% ioctl                                                           0.00%  78.47%   - - kernel - -                                                0.01%  78.47%     system_call_fastpath                                        0.00%  77.15%       sys_ioctl                                                 0.00%  77.15%         do_vfs_ioctl                                            0.01%  77.15%           vfs_ioctl                                             0.00%  77.14%             drm_ioctl                                           0.01%  77.14%               drm_mode_getconnector                             0.00%  77.02%                 drm_helper_probe_single_connector_modes         0.00%  77.02%                   intel_lvds_get_modes                          0.00%  62.46%                     intel_ddc_get_modes                         0.00%  62.46%                       drm_get_edid                              0.00%  62.45%                         drm_ddc_read_edid                       0.00%  62.45%                           drm_do_probe_ddc_edid                 0.00%  62.45%                             i2c_transfer                        0.00%  62.45%                               bit_xfer                          0.01%  62.44%                                 sclhi                           0.00%  25.76%                                   set_clock                     0.08%  12.86%                                   __udelay                      0.00%  12.78%                                   get_clock                     0.11%   0.11%                                   __const_udelay                0.01%   0.01%                                 set_clock                       0.12%  12.54%                                   __const_udelay                0.01%  12.42%                                   __delay                       0.00%   0.00%                                 __udelay                        0.00%  12.08%                                 acknak                          0.00%   7.68%                                 sdahi                           0.01%   2.30%                                 try_address                     0.00%   1.20%                                 i2c_outb                        0.00%   0.59%                                 get_data                        0.11%   0.11%                                 i2c_stop                        0.00%   0.09%                                 i2c_repstart                    0.00%   0.07%                                 i2c_start                       0.00%   0.01%                                 __const_udelay                  0.01%   0.01%                               __udelay                          0.01%   0.01%                       drm_add_edid_modes                        0.00%   0.00%                       drm_mode_connector_update_edid_property   0.00%   0.00%                   intel_hdmi_detect                             0.00%   8.01%                   intel_dp_detect                               0.00%   4.91%                   intel_tv_detect                               0.00%   1.23%                   intel_lvds_detect                             0.00%   0.38%                   intel_crt_detect                              0.00%   0.03%                   drm_get_connector_name                        0.00%   0.01%               i915_gem_execbuffer                               0.00%   0.06%               i915_gem_mmap_ioctl                               0.00%   0.01%               i915_gem_set_domain_ioctl                         0.00%   0.01%               drm_gem_close_ioctl                               0.00%   0.01%               drm_mode_object_find                              0.00%   0.00%               i915_gem_busy_ioctl                               0.00%   0.00%               lock_kernel                                       0.00%   0.00%               i915_gem_create_ioctl                             0.00%   0.00%               copy_to_user                                      0.00%   0.00%             copy_user_generic_string                            0.00%   0.00%ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: i915 lockup / extreme delay

[Andy Lutomirski]

Karl Vogel wrote:
> On Mon, Mar 22, 2010 at 4:34 PM, Eric Anholt <eric@anholt.net> wrote:
>> On Mon, 22 Mar 2010 09:11:06 +0100, Karl Vogel <karl.vogel@gmail.com> wrote:
>>> On Mon, Mar 22, 2010 at 5:20 AM, Eric Anholt <eric@anholt.net> wrote:
>>>> On Sat, 20 Mar 2010 14:41:41 +0100, Karl Vogel <karl.vogel@gmail.com> wrote:
>>>>> The 'effect' is that only the mouse pointer works in the X server. The
>>>>> cpu usage on the laptop during the sluggishness is minimal. When I
>>>>> suspend the game with winedbg, the X server slowly becomes responsive again.
>>>>>
>>>>> The output from latencytop seems to point to i915 being the culprit:
>>>> If there's some code doing glFlush()es, it's probably that code at
>>>> fault.  You don't need to do that unless you're doing frontbuffer
>>>> rendering, and if you're doing frontbuffer rendering you should really
>>>> be doing backbuffer rendering.  I don't see a kernel issue here.
>>> That doesnt explain why the box completely locks up on 2.6.34-rc2
>>> though, where only a cold reboot works.
>> Missed that part of the message.  If there's a regression, bisect
>> please.
> 
> Apparently the crash was caused by a hardware bug in the intel chipset
> which is 8086:2a40 rev 07. While doing the bisect I got an error:
> 
> DRHD: handling fault status reg 2
> DMAR:[DMA Write] Request device [00:02.0] fault addr dd69a000
> DMAR:[fault reason 05] PTE Write access is not set
> 
> After some googling around, I found this bugzilla entry which explains it:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=538163#c58
> 
> The issue appears that the graphics chip is corrupting memory:
> 
> "Unfortunately, this particular chipset sometimes reads from the GTT, does the
> translation, then writes the translated address back to the _original_ GTT
> instead of to the shadow GTT. That's why you're seeing real physical addresses
> where you should have 'virtual DMA addresses', and you get the faults.   "
> 
> Adding "intel_iommu=igfx_off" to the kernel command line resolved the issue.
> The fedora kernel automatically disables this when it detects this particular
> chipset revision.
> 
> As for the freeze/slowdown right after booting, sysprof shows that more than 77%
> of the time is spent inside: drm_mode_getconnector

http://lists.freedesktop.org/archives/intel-gfx/2010-February/005922.html

I'm waiting for the encoder/connector stuff to get merged before I 
either pester people about that bug again or try to fix it myself.

You can try the same hack I use (comment out the initialization of all 
digital outputs) if you don't use them -- that completely fixes it for me.

--Andy

Re: i915 lockup / extreme delay

[Karsten Wiese]

Am Donnerstag 01 April 2010 schrieb Andy Lutomirski:
> Karl Vogel wrote:
> > On Mon, Mar 22, 2010 at 4:34 PM, Eric Anholt <eric@anholt.net> wrote:
> >> On Mon, 22 Mar 2010 09:11:06 +0100, Karl Vogel <karl.vogel@gmail.com> wrote:
> >>> On Mon, Mar 22, 2010 at 5:20 AM, Eric Anholt <eric@anholt.net> wrote:
> >>>> On Sat, 20 Mar 2010 14:41:41 +0100, Karl Vogel <karl.vogel@gmail.com> wrote:
> >>>>> The 'effect' is that only the mouse pointer works in the X server. The
> >>>>> cpu usage on the laptop during the sluggishness is minimal. When I
> >>>>> suspend the game with winedbg, the X server slowly becomes responsive again.
> >>>>>
> >>>>> The output from latencytop seems to point to i915 being the culprit:
> >>>> If there's some code doing glFlush()es, it's probably that code at
> >>>> fault.  You don't need to do that unless you're doing frontbuffer
> >>>> rendering, and if you're doing frontbuffer rendering you should really
> >>>> be doing backbuffer rendering.  I don't see a kernel issue here.
> >>> That doesnt explain why the box completely locks up on 2.6.34-rc2
> >>> though, where only a cold reboot works.
> >> Missed that part of the message.  If there's a regression, bisect
> >> please.
> > 
> > Apparently the crash was caused by a hardware bug in the intel chipset
> > which is 8086:2a40 rev 07. While doing the bisect I got an error:
> > 
> > DRHD: handling fault status reg 2
> > DMAR:[DMA Write] Request device [00:02.0] fault addr dd69a000
> > DMAR:[fault reason 05] PTE Write access is not set
> > 
> > After some googling around, I found this bugzilla entry which explains it:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=538163#c58
> > 
> > The issue appears that the graphics chip is corrupting memory:
> > 
> > "Unfortunately, this particular chipset sometimes reads from the GTT, does the
> > translation, then writes the translated address back to the _original_ GTT
> > instead of to the shadow GTT. That's why you're seeing real physical addresses
> > where you should have 'virtual DMA addresses', and you get the faults.   "
> > 
> > Adding "intel_iommu=igfx_off" to the kernel command line resolved the issue.
> > The fedora kernel automatically disables this when it detects this particular
> > chipset revision.
> > 
> > As for the freeze/slowdown right after booting, sysprof shows that more than 77%
> > of the time is spent inside: drm_mode_getconnector
> 
> http://lists.freedesktop.org/archives/intel-gfx/2010-February/005922.html
> 
> I'm waiting for the encoder/connector stuff to get merged before I 
> either pester people about that bug again or try to fix it myself.
> 
> You can try the same hack I use (comment out the initialization of all 
> digital outputs) if you don't use them -- that completely fixes it for me.

Andy, please try this patch.
Eric, please review.

Thanks,
Karsten

[RFC PATCH] drm/i915: Don't touch PORT_HOTPLUG_EN in intel_dp_detect()
 Von: Karsten Wiese <fzuuzf@googlemail.com>
 An: linux-kernel@vger.kernel.org, Jesse Barnes <jbarnes@virtuousgeek.org>, Eric Anholt <eric@anholt.net>
 
PORT_HOTPLUG_EN has allready been setup in i915_driver_irq_postinstall(),
when intel_dp_detect() runs.

Delete the DP[BCD]_HOTPLUG_INT_EN defines, they are not referenced anymore.

I found this while searching for a fix for
        https://bugzilla.redhat.com/show_bug.cgi?id=528312

Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>
---
See also 
"drm/i915: only enable hotplug for detected outputs"
b01f2c3a4a37d09a47ad73ccbb46d554d21cfeb0

 drivers/gpu/drm/i915/i915_reg.h |    3 ---
 drivers/gpu/drm/i915/intel_dp.c |   10 ----------
 2 files changed, 0 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ab1bd2d..92f440d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -854,11 +854,8 @@
 /* Hotplug control (945+ only) */
 #define PORT_HOTPLUG_EN                0x61110
 #define   HDMIB_HOTPLUG_INT_EN                 (1 << 29)
-#define   DPB_HOTPLUG_INT_EN                   (1 << 29)
 #define   HDMIC_HOTPLUG_INT_EN                 (1 << 28)
-#define   DPC_HOTPLUG_INT_EN                   (1 << 28)
 #define   HDMID_HOTPLUG_INT_EN                 (1 << 27)
-#define   DPD_HOTPLUG_INT_EN                   (1 << 27)
 #define   SDVOB_HOTPLUG_INT_EN                 (1 << 26)
 #define   SDVOC_HOTPLUG_INT_EN                 (1 << 25)
 #define   TV_HOTPLUG_INT_EN                    (1 << 18)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 439506c..7a3b5c8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1179,16 +1179,6 @@ intel_dp_detect(struct drm_connector *connector)
        if (IS_IRONLAKE(dev))
                return ironlake_dp_detect(connector);

-       temp = I915_READ(PORT_HOTPLUG_EN);
-
-       I915_WRITE(PORT_HOTPLUG_EN,
-              temp |
-              DPB_HOTPLUG_INT_EN |
-              DPC_HOTPLUG_INT_EN |
-              DPD_HOTPLUG_INT_EN);
-
-       POSTING_READ(PORT_HOTPLUG_EN);
-
        switch (dp_priv->output_reg) {
        case DP_B:
                bit = DPB_HOTPLUG_INT_STATUS;
--