Bug 40282 - [GM965/GL960] Intel driver 2.16.0 built with --enable-sna frequently crashes X11
Summary: [GM965/GL960] Intel driver 2.16.0 built with --enable-sna frequently crashes X11
Status: CLOSED DUPLICATE of bug 29046
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-22 02:20 UTC by Tassilo Horn
Modified: 2016-11-03 12:10 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg output (96.50 KB, text/plain)
2011-08-22 02:20 UTC, Tassilo Horn
no flags Details
/sys/kernel/debug/dri/0/i915_error_state (780.82 KB, text/plain)
2011-08-22 09:34 UTC, Tassilo Horn
no flags Details
i915_error_state output (761.69 KB, application/octet-stream)
2011-11-05 02:33 UTC, Steven Newbury
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tassilo Horn 2011-08-22 02:20:47 UTC
Created attachment 50444 [details]
dmesg output

When I build the xf86-video-intel-2.16.0 driver with the new SandyBridge New Acceleration code, my xorg-server-1.10.4 (also 1.10.3) frequently crashes.  But it seems the only application that is able to provoke the crash is Eclipse (3.7), which uses SWT.  Using that, I only need to open some java file and scrolling around a bit or switching to some other tab.  It seems that the crash will occur earlier if I scroll faster.

Often after the crash, I don't even get back to a console using Ctrl-Alt-F1, but I only have a blank screen, so that I have to reboot the system using SysRQ keys.

After a crash, my Xorg.0.log doesn't contain anything related to the crash (no backtrace or error messages, only the stuff written when X starts up).

After compiling the driver without SNA support seems to fix the issue, at least I didn't occur a crash since then.

Attached is the output of dmesg.

I'm happy to provide any additional information, you just have to tell me how to gather it.  I can also test-drive the git version if required.

System environment: 
-- chipset: Mobile GM965/GL960 Integrated Graphics Controller
-- system architecture: 64-bit
-- xf86-video-intel: 2.16.0
-- xserver: xorg-server-1.10.4
-- mesa: 7.11
-- libdrm: 2.4.26
-- kernel: 3.0.3
-- Linux distribution: Gentoo GNU/Linux
-- Machine or mobo model: Lenovo ThinkPad T61
Comment 1 Chris Wilson 2011-08-22 02:49:01 UTC
Is that a dmesg after the crash? Can you grab the stderr from Xorg (usually captured in something like gdm.log)? My suspicion is that you're having fun with a buffer leak related to rendering trapezoids...
Comment 2 Tassilo Horn 2011-08-22 03:45:01 UTC
(In reply to comment #1)
> Is that a dmesg after the crash?

No, that output was from running dmesg on my current system where the driver is compiled without --enable-sna.  If you need the dmesg output with --enable-sna after the crash occured, I can provide one this evening.

> Can you grab the stderr from Xorg (usually
> captured in something like gdm.log)? My suspicion is that you're having fun
> with a buffer leak related to rendering trapezoids...

Here's the output, and indeed it contains a backtrace:


X.Org X Server 1.10.4
Release Date: 2011-08-19
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.0.3-gentoo x86_64 Gentoo
Current Operating System: Linux tsdh 3.0.3-gentoo #3 SMP PREEMPT Mon Aug 22 11:29:51 CEST 2011 x86_64
Kernel command line: root=/dev/sda3 init=/bin/systemd quiet
Build Date: 21 August 2011  10:50:00AM
 
Current version of pixman: 0.22.2
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Aug 22 12:20:57 2011
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE) keyboard: No device specified.
(EE) PreInit returned 2 for "keyboard"
(EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device
(EE) PreInit returned 8 for "mouse"
(EE) SynPS/2 Synaptics TouchPad Unable to query/initialize Synaptics hardware.
(EE) PreInit returned 11 for "SynPS/2 Synaptics TouchPad"
(EE) Query no Synaptics: 6003C8
(EE) SynPS/2 Synaptics TouchPad Unable to query/initialize Synaptics hardware.
(EE) PreInit returned 11 for "SynPS/2 Synaptics TouchPad"
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x45fcb8]
1: /usr/bin/X (mieqEnqueue+0x1f3) [0x45a223]
2: /usr/bin/X (xf86PostMotionEventM+0x92) [0x47fc42]
3: /usr/bin/X (xf86PostMotionEventP+0x3c) [0x47fd3c]
4: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fd32d581000+0x48fa) [0x7fd32d5858fa]
5: /usr/bin/X (0x400000+0x6d567) [0x46d567]
6: /usr/bin/X (0x400000+0x11c029) [0x51c029]
7: /lib64/libpthread.so.0 (0x7fd3308ab000+0xf430) [0x7fd3308ba430]
8: /lib64/libc.so.6 (ioctl+0x7) [0x7fd32f8af0c7]
9: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x7fd32de52d88]
10: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fd32d998000+0x3eee9) [0x7fd32d9d6ee9]
11: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fd32d998000+0x3fc7b) [0x7fd32d9d7c7b]
12: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fd32d998000+0x54ee7) [0x7fd32d9ecee7]
13: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fd32d998000+0x40688) [0x7fd32d9d8688]
14: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fd32d998000+0x710e5) [0x7fd32da090e5]
15: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fd32d998000+0x71423) [0x7fd32da09423]
16: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fd32d998000+0x72533) [0x7fd32da0a533]
17: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fd32d998000+0x53c05) [0x7fd32d9ebc05]
18: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fd32d998000+0x547fa) [0x7fd32d9ec7fa]
19: /usr/bin/X (0x400000+0xdaa05) [0x4daa05]
20: /usr/bin/X (0x400000+0xd3e9c) [0x4d3e9c]
21: /usr/bin/X (0x400000+0x30b41) [0x430b41]
22: /usr/bin/X (0x400000+0x24aed) [0x424aed]
23: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7fd32f7fdf0d]
24: /usr/bin/X (0x400000+0x24699) [0x424699]
xinit: connection to X server lost

waiting for X server to shut down
Comment 3 Chris Wilson 2011-08-22 03:52:00 UTC
Can you please do a 
$ addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so 0x3eee9 0x3fc7b 0x54ee7 0x40688 0x710e5 0x71423 0x72533 0x53c05 0x547fa

You just need to be careful that the intel_drv.so matches the one at the time of the crash (and the debug symbols are available!).
Comment 4 Tassilo Horn 2011-08-22 06:13:08 UTC
(In reply to comment #3)
> Can you please do a 
> $ addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so 0x3eee9 0x3fc7b
> 0x54ee7 0x40688 0x710e5 0x71423 0x72533 0x53c05 0x547fa
> 
> You just need to be careful that the intel_drv.so matches the one at the time
> of the crash (and the debug symbols are available!).

Oh, it wasn't compiled with debugging symbols.  Now I've recompiled it again with --enable-sna, no stripping and these flags:

	CFLAGS="-mtune=native -O1 -pipe -g -ggdb"
	CXXFLAGS="${CFLAGS}"

The new backtrace I got after crashing X by scrolling in Eclipse was this one:


[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x45fcb8]
1: /usr/bin/X (mieqEnqueue+0x1f3) [0x45a223]
2: /usr/bin/X (xf86PostMotionEventM+0x92) [0x47fc42]
3: /usr/bin/X (xf86PostMotionEventP+0x3c) [0x47fd3c]
4: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f561634b000+0x48fa) [0x7f561634f8fa]
5: /usr/bin/X (0x400000+0x6d567) [0x46d567]
6: /usr/bin/X (0x400000+0x11c029) [0x51c029]
7: /lib64/libpthread.so.0 (0x7f561966a000+0xf430) [0x7f5619679430]
8: /lib64/libc.so.6 (ioctl+0x7) [0x7f561866e0c7]
9: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x7f5616c11d88]
10: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7f5616762000+0x3c1a0) [0x7f561679e1a0]
11: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7f5616762000+0x3caab) [0x7f561679eaab]
12: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7f5616762000+0x457f9) [0x7f56167a77f9]
13: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7f5616762000+0x4d5b4) [0x7f56167af5b4]
14: /usr/bin/X (WakeupHandler+0x7b) [0x434afb]
15: /usr/bin/X (WaitForSomething+0x1bc) [0x45d73c]
16: /usr/bin/X (0x400000+0x308d2) [0x4308d2]
17: /usr/bin/X (0x400000+0x24aed) [0x424aed]
18: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f56185bcf0d]
19: /usr/bin/X (0x400000+0x24699) [0x424699]
(EE) intel(0): Detected a hung GPU, disabling acceleration.
(EE) intel(0): When reporting this, please include i915_error_state from debugfs and the full dmesg.

Every time my X crashed, my complete display got dysfunctional (even no console) and the file I piped stderr to didn't contain a backtrace.  The backtrace above was from my 5th try, but since I had to console available, I was not able to run dmesg anymore or check that i915_error_state from debugfs. :-(

Anyway, after a reboot, I executed addr2line with addresses adapted to the current backtrace:

addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so 0x3c1a0 0x3caab 0x457f9 0x4d5b4
/var/tmp/portage/x11-drivers/xf86-video-intel-2.16.0/work/xf86-video-intel-2.16.0/src/sna/kgem.c:216
/var/tmp/portage/x11-drivers/xf86-video-intel-2.16.0/work/xf86-video-intel-2.16.0/src/sna/kgem.c:586
/var/tmp/portage/x11-drivers/xf86-video-intel-2.16.0/work/xf86-video-intel-2.16.0/src/sna/sna_accel.c:3136
/var/tmp/portage/x11-drivers/xf86-video-intel-2.16.0/work/xf86-video-intel-2.16.0/src/sna/sna_driver.c:585
Comment 5 Chris Wilson 2011-08-22 07:35:32 UTC
Ok, that's starting to make sense. We hung the GPU, waited for a long time for the hangcheck, and to cap it all the fallback didn't work. The stack trace is also from the point at which we check upon the GPU status -- it would be good if I can make that non-blocking!

As hinted, there should be a /sys/kernel/debug/dri/0/i915_error_state after the hang (but will be lost on rebooting). You will need both CONFIG_DEBUGFS compiled into the kernel and mount -tdebugfs debug /sys/kernel/debug to make that error state accessible. Thanks.
Comment 6 Tassilo Horn 2011-08-22 09:34:01 UTC
Created attachment 50456 [details]
/sys/kernel/debug/dri/0/i915_error_state
Comment 7 Tassilo Horn 2011-08-22 09:36:53 UTC
Ok, this time I was able to get to a console after the crash.  It seems, having no external monitor attached helps.

The backtrace was exactly the same as last time (same addresses), so the file/line numbers are the same.

The i915_error_state is attached.

After the crash, dmesg reports these additional line.

[  418.972052] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[  418.972058] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[  418.972899] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 27009 at 27004, next 27010)
Comment 8 Chris Wilson 2011-08-22 09:55:55 UTC
This is where it dies:

0x04c722fc:      0x79000002: 3DSTATE_DRAWING_RECTANGLE
0x04c72300:      0x00000000:    top left: 0,0
0x04c72304:      0x00000000:    bottom right: 0,0
0x04c72308:      0x00000000:    origin: 0,0
0x04c7230c:      0x7b003c04: 3DPRIMITIVE: rect list sequential
0x04c72310:      0x00000003:    vertex count
0x04c72314:      0x0000001e:    start vertex
0x04c72318:      0x00000001:    instance count
0x04c7231c:      0x00000000:    start instance
0x04c72320:      0x00000000:    index bias
0x04c72324:      0x02000004: MI_FLUSH

The 0x0 bottom-right looks slightly odd (a 1x1 surface) but should not be fatal.

However that batch exhibits large amounts of corruption thats look reminiscent of tiling i.e. the GPU has overwritten that batch. That is a bad, bad sign.

./configure --enable-sna --enable-debug=full may help and spot the error, but it will slow your system down immensely with the extremely verbose logging.
Comment 9 Tassilo Horn 2011-08-22 12:34:36 UTC
(In reply to comment #8)
> ./configure --enable-sna --enable-debug=full may help and spot the error, but
> it will slow your system down immensely with the extremely verbose logging.

With both --enable-debug=full or --enable-debug, X crashes directly at startup.

---------------------------------------------------------------------------------------
X.Org X Server 1.10.4
Release Date: 2011-08-19
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.0.3-gentoo x86_64 Gentoo
Current Operating System: Linux thinkpad 3.0.3-gentoo #5 SMP PREEMPT Mon Aug 22 15:14:58 CEST 2011 x86_64
Kernel command line: root=/dev/sda3 init=/bin/systemd quiet
Build Date: 21 August 2011  10:50:00AM
 
Current version of pixman: 0.22.2
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Aug 22 20:59:48 2011
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
sna_init_scrn
sna_pre_init
sna_open_drm_master
kgem_init: using vmap=0
kgem_init: has relaxed fencing=1
kgem_init: aperture low=134216704 [127], high=402650112 [383]
kgem_init: aperture mappable=268435456 [256]
kgem_init: max object size 134216704
kgem_init: max fences=14
sna_crtc_init: attached crtc[0] id=3, pipe=0
sna_crtc_init: attached crtc[1] id=4, pipe=1
sna_screen_init
sna_dri_open()
sna_dri_open: loading dri driver 'i965' [gen=40] for device '/dev/dri/card0'
uploaded 80128 bytes of static state
kgem_create_linear(80128)
kgem_create_linear: new handle=3
gem_write(handle=3, offset=0, len=80128)
sna_accel_init(backend=Broadwater, have_render=1)
sna_video_overlay_setup()
sna_video_overlay_update_attrs()
sna_uevent_init
sna_create_screen_resources(1920x1200@24)
sna_create_pixmap(1920, 1200, 24, usage=10)
kgem_can_create_2d(1920x1200, bpp=32, tiling=-1) = 1
sna_pixmap_force_to_gpu(pixmap=0x7fade5464010)
kgem_create_2d(1920x1200, bpp=32, tiling=1, exact=1, inactive=0)
searched 0 active, no match
  new pitch=7680, tiling=1, handle=4, id=1
sna_pixmap_force_to_gpu: created gpu bo
sna_pixmap_move_to_gpu()
sna_pixmap_move_to_gpu: CPU damage? 0
realize_glyph_caches
sna_create_pixmap(1024, 1024, 8, usage=1)
sna_pixmap_create_scratch(1024, 1024, 8, tiling=2)
kgem_choose_tiling: 1024x1024 -> 2
kgem_can_create_2d(1024x1024, bpp=8, tiling=2) = 1
kgem_create_2d(1024x1024, bpp=8, tiling=2, exact=0, inactive=0)
searched 0 active, no match
  new pitch=1024, tiling=2, handle=5, id=2
sna_create_pixmap(1024, 1024, 32, usage=1)
sna_pixmap_create_scratch(1024, 1024, 32, tiling=2)
kgem_choose_tiling: 1024x1024 -> 2
kgem_can_create_2d(1024x1024, bpp=32, tiling=2) = 1
kgem_create_2d(1024x1024, bpp=32, tiling=2, exact=0, inactive=0)
searched 0 active, no match
  new pitch=4096, tiling=2, handle=6, id=3
kgem_create_linear(4096)
kgem_create_linear: new handle=7
sna_create_pixmap(0, 0, 24, usage=0)
kgem_create_for_name(name=1)
kgem_create_for_name: new handle=9
sna_blt_copy_boxes src=(0, 0) -> (320, 200) x 1, tiling=(0, 1), pitch=(5120, 7680)
  sna_blt_copy_boxes: box=(0, 0)x(1280, 800)
_sna_damage_add_box(None + [(0, 0), (1280, 800)])
  = [[(0, 0), (1280, 800)]:  [(0, 0), (1280, 800)] + [0 : ...]]
sna_enter_vt
sna_crtc_set_mode_major(rotation=1, x=0, y=0, mode=1280x800@71000)
sna_crtc_set_mode_major: current fb pixmap = 0, front is 1
sna_mode_remove_fb: deleting fb id 0 for pixmap serial 0
sna_pixmap_force_to_gpu(pixmap=0x7fade5464010)
sna_pixmap_move_to_gpu()
sna_pixmap_move_to_gpu: CPU damage? 0
sna_crtc_set_mode_major: create fb 1920x1200@24/32
sna_crtc_set_mode_major: handle 4 attached to fb 18
batch[3/0]: 10 10 4096, nreloc=2, nexec=2, nfence=0, aperture=9216000
0x00000000: 0x54f00806: XY_SRC_COPY_BLT (rgb enabled, alpha enabled, src tile 0, dst tile 1)
0x00000004: 0x03cc0780:    format 8888, dst pitch 1920, clipping disabled
0x00000008: 0x00c80140:    dst (320,200)
0x0000000c: 0x03e80640:    dst (1600,1000)
0x00000010: 0x00000000:    dst offset 0x00000000 [handle=4, delta=0, read=2, write=2, (fenced? 0, tiling? 1)]
0x00000014: 0x00000000:    src (0,0)
0x00000018: 0x00001400:    src pitch 5120
0x0000001c: 0x00000000:    src offset 0x00000000 [handle=9, delta=0, read=2, write=0 (fenced? 0, tiling? 0)]
0x00000020: 0x05000000: MI_BATCH_BUFFER_END
0x00000024: 0x00000000: MI_NOOP
kgem_create_linear(40)
kgem_create_linear: new handle=10
gem_write(handle=10, offset=0, len=40)
sna_crtc_apply: applying crtc [4] mode=1280x800@71000, fb=18 update to 1 outputs
sna_crtc_dpms(pipe 0, dpms mode -> 3):= active=0
sna_crtc_resize (1920, 1200) -> (1280, 800)

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x45fcb8]
1: /usr/bin/X (0x400000+0x64299) [0x464299]
2: /lib64/libpthread.so.0 (0x7fade9fa9000+0xf430) [0x7fade9fb8430]
3: /usr/lib64/xorg/modules/libfb.so (_fbGetWindowPixmap+0x2f) [0x7fade683945f]
4: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fade7068000+0x59030) [0x7fade70c1030]
5: /usr/bin/X (0x400000+0x92c60) [0x492c60]
6: /usr/bin/X (xf86RandR12CreateScreenResources+0x1f7) [0x493987]
7: /usr/bin/X (0x400000+0x88db0) [0x488db0]
8: /usr/bin/X (0x400000+0x24994) [0x424994]
9: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7fade8efbf0d]
10: /usr/bin/X (0x400000+0x24699) [0x424699]
Segmentation fault at address 0x20

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting


Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

sna_leave_vt
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: unexpected signal 2
---------------------------------------------------------------------------------------

addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so 0x59030
/var/tmp/portage/x11-drivers/xf86-video-intel-2.16.0/work/xf86-video-intel-2.16.0/src/sna/sna_display.c:1606
Comment 11 Steven Newbury 2011-11-05 02:33:45 UTC
Created attachment 53178 [details]
i915_error_state output

I've been unable to use SNA on the same hardware for some months now, since it's been in heavy development I've been waiting to see if it stablises, but given this bug's here I've attached the error_state for my GPU lockup, hopefully it will help track down the problem.
Comment 12 Chris Wilson 2011-11-05 03:02:48 UTC
More garbage in the batch buffer.
Comment 13 Chris Wilson 2012-03-26 01:44:52 UTC
I believe these are all related to the underlying bug:

commit c501ae7f332cdaf42e31af30b72b4b66cbbb1604
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Dec 14 13:57:23 2011 +0100

    drm/i915: Only clear the GPU domains upon a successful finish
    
    By clearing the GPU read domains before waiting upon the buffer, we run
    the risk of the wait being interrupted and the domains prematurely
    cleared. The next time we attempt to wait upon the buffer (after
    userspace handles the signal), we believe that the buffer is idle and so
    skip the wait.
    
    There are a number of bugs across all generations which show signs of an
    overly haste reuse of active buffers.
    
    Such as:
    
      https://bugs.freedesktop.org/show_bug.cgi?id=29046
      https://bugs.freedesktop.org/show_bug.cgi?id=35863
      https://bugs.freedesktop.org/show_bug.cgi?id=38952
      https://bugs.freedesktop.org/show_bug.cgi?id=40282
      https://bugs.freedesktop.org/show_bug.cgi?id=41098
      https://bugs.freedesktop.org/show_bug.cgi?id=41102
      https://bugs.freedesktop.org/show_bug.cgi?id=41284
      https://bugs.freedesktop.org/show_bug.cgi?id=42141
    
    A couple of those pre-date i915_gem_object_finish_gpu(), so may be
    unrelated (such as a wild write from a userspace command buffer), but
    this does look like a convincing cause for most of those bugs.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: stable@kernel.org
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 14 Gordon Jin 2012-04-01 01:55:26 UTC
to mark dup
Comment 15 Gordon Jin 2012-04-01 01:56:06 UTC

*** This bug has been marked as a duplicate of bug 29046 ***
Comment 16 Jari Tahvanainen 2016-11-03 12:10:55 UTC
Closing resolved+duplicate as duplicate of closed+fixed.


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.