Created attachment 33761 [details] intel_reg_dump run after boot before any X sessions chipset: Q965 arch: linux smp 2.6.33 / i686 First tried to use latest version with distribution 2.9.1, but then to be sure it's not Debian specific problem I compiled 2.9.1 (9acf10762b5f3d3b1b33ea07792a936a25e45010) from repository. libdrm with distribution: 2.4.17 Distribution: Debian squeeze / testing Machine or mobo model: Dell Optiplex 745 / lspci: 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02) Display connector: VGA Tried to reproduce several times with or without hard power reset. Everytime blank screen appears and box freezes when running startx. It does not respond ping neither cannot log into using ssh. Cannot give you anything after "working" case since it's not starting.
Created attachment 33762 [details] Xorg logfile take after boot (forced restart since box hang)
Created attachment 33763 [details] dmesg output of the box
There is actually same symptoms than in http://bugs.freedesktop.org/show_bug.cgi?id=15933. I have a very big feeling that it has never been fixed or this is new problem, but I'm not sure so I didn't make this a duplicate for it. I used that 2.2.1 version since now I updated the system (xorg xserver) and noticed that old well-known problem came back. Big thanks in advance, I'll provide more logs and info if needed. -J
> It does not respond > ping neither cannot log into using ssh. Cannot give you anything after > "working" case since it's not starting. Seems to be that there is still possibility to log in the box. However, screen is totally frozen and even changing the driver to vesa which normally works cannot bring it back. Since it's not completly frozen, is there any debug/logging parameters what can I provide to show the state after blanked startx?
(In reply to comment #4) > > It does not respond > > ping neither cannot log into using ssh. Cannot give you anything after > > "working" case since it's not starting. > Seems to be that there is still possibility to log in the box. However, screen > is totally frozen and even changing the driver to vesa which normally works > cannot bring it back. > Since it's not completly frozen, is there any debug/logging parameters what can > I provide to show the state after blanked startx? Can you try the 2.6.33 kernel and attach the output of dmesg ? Please boot the system with KMS enabled and add the boot option of "drm.debug=0x04". Thanks.
Created attachment 34078 [details] 2.6.33 / dmesg with drm debug 0x04
In addition to last attachment, Using 2.6.33 and KMS enabled (with i915 driver). Screen still leaves almost totally blank except small cursor in left upper corner is shown (not blinking). Input from keyboard is not received by the X so only way to reboot is to take a remote session from another box and run reboot. Even Vesa driver does not work if DRM-i915+KMS is enabled, but that seems to be normal anyway? Shall I try newer version from the driver repository or please tell me how to give you more debug information? -J
(In reply to comment #7) > In addition to last attachment, > Using 2.6.33 and KMS enabled (with i915 driver). Screen still leaves almost > totally blank except small cursor in left upper corner is shown (not blinking). > Input from keyboard is not received by the X so only way to reboot is to take a > remote session from another box and run reboot. Even Vesa driver does not work > if DRM-i915+KMS is enabled, but that seems to be normal anyway? It seems that the external monitor is connected throught DVI-D connector. Right? Is anything displayed on the external monitor if you enters the console mode? Do you have an opportunity to try another monitor and see whether it can work? Please also attach the output of vbios.dump on your box, which can be obtained by using the following command: 1. echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom 2. cat /sys/devices/pci0000:00/0000:00:02.0/rom >vbios.dump 3. echo 0 > /sys/devices/pci0000:00/0000:00:02.0/rom > Shall I try newer version from the driver repository or please tell me how to > give you more debug information? > -J
> It seems that the external monitor is connected throught DVI-D connector. > Right? This a desktop configuration so the there is DVI-D and VGA outputs both. I have tested both and picture seems to be black and drivers hangs in both scenarions. > Is anything displayed on the external monitor if you enters the console mode? No, it doesn't take any more inputs from the keyboard and it's not possible to change back to console. Same beheauviour appears if trying from VGA and from DVI-D. > Do you have an opportunity to try another monitor and see whether it can work? At the moment no, but if you need it I think I can try something. vbios.dump attached.
Created attachment 34209 [details] cat'd from /sys/devices/pci0000:00/0000:00:02.0/rom
(In reply to comment #9) > > It seems that the external monitor is connected throught DVI-D connector. > > Right? > > This a desktop configuration so the there is DVI-D and VGA outputs both. I have > tested both and picture seems to be black and drivers hangs in both scenarions. Do you mean that the issue of blank screen still exists even when using VGA connector? > > > Is anything displayed on the external monitor if you enters the console mode? > > No, it doesn't take any more inputs from the keyboard and it's not possible to > change back to console. Same beheauviour appears if trying from VGA and from > DVI-D. It is very interesting that there exists the following warning message related with SDVO when using DVI-D. > 2.962645] [drm:intel_sdvo_debug_write], SDVOB: W: 16 48 3F 40 30 62 B0 32 40 (SDVO_CMD_SET_OUTPUT_TIMINGS_PART1) >[ 2.992369] [drm:intel_sdvo_debug_response], SDVOB: (Not supported) It seems that the driver can't configure the SDVO output timing correctly. Thanks. > > > Do you have an opportunity to try another monitor and see whether it can work? > > At the moment no, but if you need it I think I can try something. > > vbios.dump attached.
Can you add the boot option of "video=DVI-D-1:1024x768@" and see whether the issue still exists? Thanks.
Created attachment 34812 [details] [review] try the debug patch that dumps the output pixel clock range of SDVO device From the dmesg log it seems that this SDVO device can't support the command of configuring the output timing. In such case we don't know whether the desired mode is beyond the range. Will you please try the debug patch and attach the output of dmesg? Thanks.
(In reply to comment #12) > Can you add the boot option of "video=DVI-D-1:1024x768@" and see whether the > issue still exists? Sorry for the typo. The boot option should be "video=DVI-D-1:1024x768@60". thanks. > Thanks.
Created attachment 34904 [details] [review] try the debug patch that disable memory self-refresh on 965 desktop platform Will you please try the attached debug patch and see whether the issue still exists? Thanks. yakui
> Will you please try the attached debug patch and see whether the issue still > exists? I applied both patchies. Here is the clip from the syslog: Apr 12 10:26:59 jcave kernel: [ 2.544025] [drm:intel_sdvo_init], SDVOB device VID/DID: 04:AA.03, clock range 25MHz - 165MHz, input 1: Y, input 2: N, output 1: Y, output 2: N So, to be more specific, problem occurs in both VGA and DVI-D. Behavior of the problem is same and it is not depend which connector is used. I have not noticed any differences using DVI-D or VGA connector. When booting the Linux (until login prompt), correct kms mode is chosen (1024x769), resolution changes to 1024x768, penguins and log output of the boot and you can login to virtual terminal. Everything is fine so far. But when running startx then the box screen is cleared, cursor is shown on left upper corner (not blinking anymore) and loading of X server hangs. You can log to the machine via network, but all input devices are dead (so you cannot even soft-boot the machine nor kill the X).
(In reply to comment #16) > > Will you please try the attached debug patch and see whether the issue still > > exists? > > I applied both patchies. Here is the clip from the syslog: > > Sorry for the late response. > > So, to be more specific, problem occurs in both VGA and DVI-D. Behavior of the > problem is same and it is not depend which connector is used. I have not > noticed any differences using DVI-D or VGA connector. Thanks for the confirmation that the issue still exists after using VGA connector. > > When booting the Linux (until login prompt), correct kms mode is chosen > (1024x769), resolution changes to 1024x768, penguins and log output of the boot > and you can login to virtual terminal. Everything is fine so far. But when > running startx then the box screen is cleared, cursor is shown on left upper > corner (not blinking anymore) and loading of X server hangs. You can log to the > machine via network, but all input devices are dead (so you cannot even > soft-boot the machine nor kill the X). It seems that the system can work under the low resolution. Will you please try the boot option of "video=1600x1200@60" and see whether the screen is normal under the console mode?
Yep, it works. Actually kernel automatically chooses that 1600x1200 resolution even without that video= parameter. It works with both VGA and DVI-D in console mode. Screen freezes out after running startx (screen clears, cursor moves into right upper corner, but nothing happens after that).
(In reply to comment #18) > Yep, it works. Actually kernel automatically chooses that 1600x1200 resolution > even without that video= parameter. It works with both VGA and DVI-D in console > mode. Screen freezes out after running startx (screen clears, cursor moves into > right upper corner, but nothing happens after that). Thanks for the confirmation. It seems that the system can work well under console mode. The correct mode is set. But after starting X, the screen will be blank. Will you please take picture of the screen when the issue happens? Thanks. Yakui
This doesn't look like a mode-setting issue. Jesse may have more ideas for the GPU hang...
> But after starting X, the screen will be blank. Will you please take picture > of the screen when the issue happens? I'll provide it later if neccessary, however it will be black screen :) Summasummarum: with kernel compiled with kms support, but using i915.modeset=0 after runnung startx screen goes totally black. If kernel is not compiled with kms support then it goes black except the cursor left in left-uppercorner. It seems to be possible to log in the computer after screen went to black so if you need any traces/dumps?
If you can ssh into the box you can start X from there and possibly collect some more debug output using "startx -- -verbose". Make sure you have the latest libdrm and xf86-video-intel.
(In reply to comment #22) > Make sure you have the > latest libdrm and xf86-video-intel. No I got kernel 2.6.33.2 (i915/kms), libdrm 2.4.20 and intel driver 2.11.0. Remote startx show new interesting dynamic linking error: ----clipclip---- .... 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 /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: drmCheckModesettingSupported giving up. xinit: Connection refused (errno 111): unable to connect to X server xinit: No such process (errno 3): Server error. ----clipclip---- That propably is the reason why starting fails and video is not cleaned propably when X givs up. I intel_drv.so has libdrm dependency from the library /lib/.. that does not really have that kind of symbol even that those sources should be linked with libdrm. Have to do more investigation for that.
Looked out too fast, it should exists: objdump -x /usr/lib/libdrm.so|grep Modesetti 00007030 g F .text 000001c9 drmCheckModesettingSupported
Did you figure this out? Seems like a build or configuration problem more than anything else...
Timed out on this one. It could be fixed by https://patchwork.kernel.org/patch/108937/
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.