Created attachment 55045 [details] relevant part of syslog
Debian bug no. 654217
As I mentioned to Cyril, your Xorg.log indicates that you have a lot of known bugs on your system and that the /sys/kernel/debug/dri/0/i915_error_state is my best bet for determining whether you have hit a novel bug.
Created attachment 55071 [details] Error log from /sys
Created attachment 55072 [details] The crashed one Thanks to Cyril for his suggestions with sleep to get the error log.
Ok, this looks like the finish-gpu kernel bug, as the source texture has been reused prior to the execution of the batch -- leaving the fence registers in a conflicting state with the tiling parameters.
As I guess you are compiling your own kernels, you might like to try Daniel's tree as it contains most of the known fixes at this point: http://cgit.freedesktop.org/~danvet/drm/ #my-next
No change with the new kernel with Daniels patches. On the contrary, after boot the linux console is black. Logging in and starting X is possible and the monitor is usable again. Switching to console is also possible, the monitor is no longer black.
> --- Comment #8 from Reinhard Karcher <reinhard.karcher@gmx.net> 2012-01-03 06:45:56 PST --- > No change with the new kernel with Daniels patches. > On the contrary, after boot the linux console is black. > Logging in and starting X is possible and the monitor is usable again. > Switching to console is also possible, the monitor is no longer black. > sounds like you don't have fbcon builtin.
I managed to compile a broken kernel, after a 'make distclean' and compiling a new kernel, the issue with the black console is gone, but the main issue, the crashing of the kernel doesn't change. Reinhard
Verify that you did build using Daniel's my-next branch and attach the i915-error-state.
Created attachment 55109 [details] linux from git with Daniels patches Daniels branch was fetched with the following command: git clone --reference ../linux --branch my-next git://people.freedesktop.org/~danvet/drm The directory ../linux contains the newest linux from git, command was executed at 12:42 UTC on Jan 3rd. That kernel was running was the kernel crashed. Reinhard
Created attachment 55110 [details] The interesting part from the actual syslog
Created attachment 55621 [details] New Xorg-driver with some more information I tried the new interl-xorg driver from Debian unstable with some more error information. Attached is the Xorg log file. I could login to the laptop via ssh, after I realized that the DHCP server suddenly decided to change the IP address of the laptop. I will attach the copy of the linux console, on which I start X, part of syslog and the error log from debugfs. Reinhard
Created attachment 55622 [details] Created with: cp /dev/tty2 terminal.log
Created attachment 55623 [details] part from syslog
Created attachment 55624 [details] actual copy from debugfs
It dies on the second operation which happens to completely overwrite the first. Both are copying from the same GTT upload, 36x54 untiled pixmaps, sequential. I see no reason for it to die! 0x0a874084: 0x79000002: 3DSTATE_DRAWING_RECTANGLE 0x0a874088: 0x00000000: top left: 0,0 0x0a87408c: 0x00350023: bottom right: 35,53 0x0a874090: 0x00000000: origin: 0,0 0x0a874094: 0x78080003: 3DSTATE_VERTEX_BUFFERS 0x0a874098: 0x0800000c: buffer 1: sequential, pitch 12b 0x0a87409c: 0x0a874198: buffer address 0x0a8740a0: 0x00000000: max index 0x0a8740a4: 0x00000000: mbz 0x0a8740a8: 0x7b003c04: 3DPRIMITIVE: rect list sequential 0x0a8740ac: 0x00000003: vertex count 0x0a8740b0: 0x00000000: start vertex 0x0a8740b4: 0x00000001: instance count 0x0a8740b8: 0x00000000: start instance 0x0a8740bc: 0x00000000: index bias 0x0a8740c0: 0x02000004: MI_FLUSH 0x0a8740c4: 0x78010004: 3DSTATE_BINDING_TABLE_POINTERS 0x0a8740c8: 0x00000000: VS binding table 0x0a8740cc: 0x00000000: GS binding table 0x0a8740d0: 0x00000000: Clip binding table 0x0a8740d4: 0x00000000: SF binding table 0x0a8740d8: 0x00003f80: WM binding table 0x0a8740dc: 0x7b003c04: 3DPRIMITIVE: rect list sequential 0x0a8740e0: 0x00000003: vertex count 0x0a8740e4: 0x00000003: start vertex 0x0a8740e8: 0x00000001: instance count 0x0a8740ec: 0x00000000: start instance 0x0a8740f0: 0x00000000: index bias 0x0a8740f4: 0x02000004: MI_FLUSH 0x0a8740f8: HEAD 0x78010004: 3DSTATE_BINDING_TABLE_POINTERS
I just tested the xorg-driver from newest git and it didn't crash any longer. (intel(0): SNA compiled from 2.17.0-458-gbbd6c81) I tried the newest linux kernel from git and the Debian kernel 3.2.0-rc7. The slightly older debian xorg-driver: SNA compiled: xserver-xorg-video-intel 2:2.17.0+git20120115-1 (Cyril Brulebois <kibi@debian.org>) had a soft crash: The kde window manager died, the keyboard stopped working, but using the mouse, I could stop all applications and leave X. I have copied the i915_error_state, X server log file and the error lines from syslog. Do you want to see any of that files? Starting X again, it complained about the gpu: (WW) intel(0): cannot enable XVideo whilst the GPU is wedged (WW) intel(0): cannot enable DRI2 whilst the GPU is wedged. and enabled software rendering: (II) AIGLX: Screen 0 is not DRI2 capable (II) AIGLX: Screen 0 is not DRI capable (II) AIGLX: Loaded and initialized swrast (II) GLX: Initialized DRISWRAST GL provider for screen 0 Reinhard
Yes, if you still have the i915_error_state can you attach it here as well. I imagine that it will be another unsolvable mystery, but it might also be the key to understanding what went wrong. Please keep me posted as to whether the bug stays hidden. Otherwise we will just mark it as being likely fixed by recent updates. Thanks.
Created attachment 55727 [details] Copy from debugfs
Reinhard mentioned that he hasn't seen a crash in the last week, so I'm presuming that I broke the bo being sampled by the batch.
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.