ystem Environment: -------------------------- Arch: x86_64 Platform: Ivybridge Kernel: (drm-intel-next-queued)d7697eea3eec74c561d12887d892c53ac4380c00 Bug detailed description: ------------------------- Run ./gem_wait_render_timeout, [drm:i915_hangcheck_elapsed] *ERROR* bsd ring: stuck on addr 0x144 appears in dmesg. It happens on only one IVB(Genuine Intel(R) CPU @ 2.20GHz) with drm-intel-next-queued kernel, It doesn't happen on drm-intel-fixes kernel. Bisect shows:05407ff889ceebe383aa5907219f86582ef96b72 is the first bad commit. commit 05407ff889ceebe383aa5907219f86582ef96b72 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> AuthorDate: Thu May 30 09:04:29 2013 +0300 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Mon Jun 3 10:58:21 2013 +0200 drm/i915: detect hang using per ring hangcheck_score Keep track of ring seqno progress and if there are no progress detected, declare hang. Use actual head (acthd) to distinguish between ring stuck and batchbuffer looping situation. Stuck ring will be kicked to trigger progress. This commit adds a hard limit for batchbuffer completion time. If batchbuffer completion time is more than 4.5 seconds, the gpu will be declared hung. Review comment from Ben which nicely clarifies the semantic change: "Maybe I'm just stating the functional changes of the patch, but in case they were unintended here is what I see as potential issues: 1. "If ring B is waiting on ring A via semaphore, and ring A is making progress, albeit slowly - the hangcheck will fire. The check will determine that A is moving, however ring B will appear hung because the ACTHD doesn't move. I honestly can't say if that's actually a realistic problem to hit it probably implies the timeout value is too low. 2. "There's also another corner case on the kick. If the seqno = 2 (though not stuck), and on the 3rd hangcheck, the ring is stuck, and we try to kick it... we don't actually try to find out if the kick helped" v2: use atchd to detect stuck ring from loop (Ben Widawsky) v3: Use acthd to check when ring needs kicking. Declare hang on third time in order to give time for kick_ring to take effect. v4: Update commit msg output: 32768 iters is enough work Finished with 179580100 time remaining signal handler called 1865 times dmesg: [ 166.346777] [drm:i915_driver_open], [ 166.346792] [drm:intel_crtc_set_config], [CRTC:3] [NOFB] [ 166.346797] [drm:intel_crtc_set_config], [CRTC:5] [NOFB] [ 166.346799] [drm:intel_crtc_set_config], [CRTC:7] [NOFB] [ 166.346804] [drm:i915_driver_open], [ 181.188260] [drm:i915_driver_open], [ 181.188277] [drm:i915_driver_open], [ 181.189097] [drm:i915_driver_open], [ 181.189107] [drm:i915_driver_open], [ 189.518017] [drm:i915_hangcheck_elapsed] *ERROR* bsd ring: stuck on addr 0x144 [ 189.518221] [drm:i915_error_work_func], resetting chip [ 189.518979] [drm:gm45_get_vblank_counter], trying to get vblank count for disabled pipe A [ 189.518983] [drm:gm45_get_vblank_counter], trying to get vblank count for disabled pipe B [ 189.518984] [drm:gm45_get_vblank_counter], trying to get vblank count for disabled pipe C [ 189.520119] [drm:intel_crtc_set_config], [CRTC:3] [NOFB] [ 189.520124] [drm:intel_crtc_set_config], [CRTC:5] [NOFB] [ 189.520126] [drm:intel_crtc_set_config], [CRTC:7] [NOFB] lspci: 00:00.0 Host bridge: Intel Corporation Ivy Bridge DRAM Controller (rev 04) 00:02.0 VGA compatible controller: Intel Corporation Device 0162 (rev 04) 00:14.0 USB Controller: Intel Corporation Panther Point USB xHCI Host Controller (rev 02) 00:16.0 Communication controller: Intel Corporation Panther Point MEI Controller #1 (rev 02) 00:16.3 Serial controller: Intel Corporation Panther Point KT Controller (rev 02) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 02) 00:1a.0 USB Controller: Intel Corporation Panther Point USB Enhanced Host Controller #2 (rev 02) 00:1b.0 Audio device: Intel Corporation Panther Point High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 1 (rev c2) 00:1c.6 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 7 (rev c2) 00:1c.7 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 8 (rev c2) 00:1d.0 USB Controller: Intel Corporation Panther Point USB Enhanced Host Controller #1 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a2) 00:1f.0 ISA bridge: Intel Corporation Panther Point LPC Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation Panther Point 6 port SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation Panther Point SMBus Controller (rev 02) 02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34) 03:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200A PCI Express-to-PCI Bridge (rev 03) 04:00.0 FireWire (IEEE 1394): Texas Instruments XIO2200A IEEE-1394a-2000 Controller (PHY/Link) (rev 01) Reproduce steps: ---------------- 1. ./gem_wait_render_timeout 2. dmesg -r | egrep "<[1-6]>" |grep drm
Mika, can you please take a look?
If it only occurs on pre-release silicon, should we even bother to diagnose this?
(In reply to comment #2) > If it only occurs on pre-release silicon, should we even bother to diagnose > this? Bug report says it happens on ivb ... sounds more like a dupe of bug #65394 to me.
*** This bug has been marked as a duplicate of bug 65394 ***
Verified.Fixed.
Closing old verified.
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.