Hello I came from bug #33422 Whenever I close Armagetron on a SandyBrige machine, the screen gets black. Changing to VT1 and back to X doesn't fix anything. This is under IceWM (which I belive is not composited). Steps to reproduce: - start Armagetron on IceWM (or probably any other non-composited desktop) - select "exit game" (you don't need to play) - screen will get black. This bug happens with Xserver 1.9.4, ddx 2.14, drm 2.4.23, kernel 2.6.37, Mesa7.10. Today I also tested the same stack but with Mesa git (7.11) and kernel tarball downloaded from kernel.org (2.6.38-rc5). [pzanoni@mandriva ~]$ lspci -nn | grep VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:0116] (rev 09) [pzanoni@mandriva ~]$ cat /proc/cpuinfo | grep "model name" model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz Link to armagetron .spec file and sources: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/armagetron/current/ If you need me to do any debugging/printf/breakpoint/patching, just ask. Any debugging tips would be welcome.
dmesg, Xorg.log and /sys/kernel/debug/dri/0/i915_error_state?
(In reply to comment #1) > dmesg, Xorg.log and /sys/kernel/debug/dri/0/i915_error_state? Just after reproducing the "black screen" error: [root@mandriva 0]# cat /sys/kernel/debug/dri/0/i915_error_state no error state collected Other files will be attached.
Created attachment 43595 [details] dmesg Dmesg after reproducing the bug.
Created attachment 43596 [details] Xorg.0.log Xorg log after reproducing the bug.
Just an additional information: After I get the black screen, it seems that X is still working. If I ssh to the machine and do some command like "DISPLAY=:0 xdpyinfo", it still works. [pzanoni@mandriva ~]$ DISPLAY=:0 xrandr Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192 LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 309mm x 174mm 1366x768 60.0*+ 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) So I did: [pzanoni@mandriva ~]$ export DISPLAY=:0 [pzanoni@mandriva ~]$ xrandr --output LVDS1 --mode 1024x768 And now I *can* see my desktop! (although the different aspect ratio gives me 2 ugly black rectangles on the screen borders). But then I did: [pzanoni@mandriva ~]$ xrandr --output LVDS1 --mode 1366x768 And the screen is black again· Then I noticed there is new information in Xorg.0.log. Pasting here just the end of the file (since the beginning is already attached in previous comment): [ 639.351] (II) intel(0): EDID vendor "INL", prod id 20 [ 639.351] (II) intel(0): DDCModeFromDetailedTiming: 1366x768 Warning: We only handle separate sync. [ 639.351] (II) intel(0): Printing DDC gathered Modelines: [ 639.351] (II) intel(0): Modeline "1366x768"x0.0 71.00 1366 1414 1446 1498 768 769 773 790 -hsync -vsync (47.4 kHz) [ 679.006] (II) intel(0): EDID vendor "INL", prod id 20 [ 679.006] (II) intel(0): DDCModeFromDetailedTiming: 1366x768 Warning: We only handle separate sync. [ 679.006] (II) intel(0): Printing DDC gathered Modelines: [ 679.006] (II) intel(0): Modeline "1366x768"x0.0 71.00 1366 1414 1446 1498 768 769 773 790 -hsync -vsync (47.4 kHz) [ 679.017] (II) intel(0): Allocated new frame buffer 1024x768 stride 4096, tiled [ 701.377] (II) intel(0): EDID vendor "INL", prod id 20 [ 701.377] (II) intel(0): DDCModeFromDetailedTiming: 1366x768 Warning: We only handle separate sync. [ 701.377] (II) intel(0): Printing DDC gathered Modelines: [ 701.377] (II) intel(0): Modeline "1366x768"x0.0 71.00 1366 1414 1446 1498 768 769 773 790 -hsync -vsync (47.4 kHz) [ 701.385] (II) intel(0): Allocated new frame buffer 1408x768 stride 5632, tiled [root@mandriva pzanoni]# cat /sys/kernel/debug/dri/0/i915_error_state no error state collected [pzanoni@mandriva ~]$ dmesg | tail xt_time: kernel timezone is -0300 u32 classifier Actions configured composite sync not supported fuse init (API version 7.16) composite sync not supported composite sync not supported composite sync not supported composite sync not supported composite sync not supported
Created attachment 43599 [details] All files inside /sys/kernel/debug/dri/0 Generated with the following commands: [root@mandriva 0]# for i in *; do echo "== File $i:" >> /tmp/debugfiles.txt; cat $i >> /tmp/debugfiles.txt; done [root@mandriva 0]# cd /tmp/ [root@mandriva tmp]# tar cvjf debugfiles.tar.bz2 debugfiles.txt
For the record: - After the last comments I wrote, I decided to test today's mesa master branch (commit 2c6793fb6bc89df16c23f727bcb072a157ab8d10 is the latest), and the problem still happens.
So it appears to be a modesetting fail. After a fresh boot, can the problem be reproduced simply by: $ xrandr --output LVDS1 --mode 1024x768 $ xrandr --output LVDS1 --preferred If so, lets start with the basics and grab a intel_reg_dumper before and after that sequence.
(In reply to comment #8) > So it appears to be a modesetting fail. > > After a fresh boot, can the problem be reproduced simply by: > > $ xrandr --output LVDS1 --mode 1024x768 > $ xrandr --output LVDS1 --preferred > No =( Also tried 640x480. I reproduced the bug with "armagetron" and I'll attach the reg dumps.
Created attachment 43824 [details] dump before Regdump before reproducing the bug with armagetron. Before booting the machine I removed it from the power chord and also removed the battery (it's a laptop).
Created attachment 43825 [details] dump after Dump after starting armagetron and selecting "exit game" (i.e: I had a black screen)
Created attachment 43826 [details] diff between the 2 dump files Diff between the dump files
Paulo, does this still happen with a recent stack? A lot has changed since February.
(In reply to comment #13) > Paulo, does this still happen with a recent stack? A lot has changed since > February. I don't have that machine anymore, many many things have changed and I can't reproduce the bug using the current stack on my "current" SNB machine, so I guess we can close this... If anyone can reproduce the bug, feel free to reopen.
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.