Created attachment 74521 [details] Starting gdm3 getting to black screen with cursor Quick description: I recently started trying to get my Debian(squeeze) installation running on a new Ivy Bridge machine. I disabled the nvidia optimus gfx card in the bios, so the only active gfx card is the intel one. Using latest stable kernel, xf86-video-intel, libdrm gives, when starting gdm3 however, the screen blanks, and theres only a white cursor at the top left, leaving it for quite some while makes no difference. ----- Detailed: This is what I've done so far getting to this point. To start with, I compiled a new kernel, 3.7.6 and make sure to enable: CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y after reboot lsmod | grep i915 gives: i915 377949 2 drm_kms_helper 17932 1 i915 intel_agp 7845 1 i915 intel_gtt 11114 2 i915,intel_agp button 3371 1 i915 video 9277 1 i915 $ uname -a Linux box 3.7.6-intel #1 SMP Sat Feb 9 09:08:15 CET 2013 i686 GNU/Linux $ uname -r 3.7.6-intel Libdrm - 2.4.40 Compiled with ./configure --prefix=/usr; make; sudo make install xf86-video-intel - 2.20.12 Compiled with ./configure --prefix=/usr; make; make check; sudo make install I avoided the 3d drivers for now trying to keep it simple. :) Starting gdm3 after this point gives the log in Xorg.log_intel_drv. I also tried booting the kernel with i915.semaphores=1 and i915.nomodeset=1 since I read that might be useful, but it doesnt make any difference in this case. If I make uninstall the xf86-video-intel I can start gdm3 but I assume it then uses fbdev/vesa for the screen.
It's missing a symbol. Look at stderr.
As luck would have it, I spent some time verifying that xf86-video-intel.git still builds against stock squeeze. That may help you in your quest...
Ok, missing symbols, checking stderr doesnt work, since I can not do anything on the machine once it happens. Or is there some trick to do it? Or should it be possible to see already during compile? Sorry for a probably newbie question. :)
Ok, in a normal setup you would check /var/log/xdm.log (or /var/log/gdm/:0.log etc) which captures the stderr from X and I hope also captures the final failure message. There will be a warning whilst compiling, but it may not be obvious.
Created attachment 74712 [details] Xorg.0.log Added Xorg.0.log, it looks fine(as far as I can tell) up until glx is loaded, then there is a bunch binary stuff.
You're machine is channeling voices from beyond the grave. Whatever you do, don't look directly into the light... Did you find the xdm.log (or equivalent)? Can you just try launching X from a vt: # /usr/bin/Xorg
(In reply to comment #6) > You're machine is channeling voices from beyond the grave. Whatever you do, > don't look directly into the light... > > > Did you find the xdm.log (or equivalent)? Can you just try launching X from > a vt: > # /usr/bin/Xorg Launching X like that just gave a black screen and no response, no keyboard things worked at all. Very strange. I dont have the xdm.log for some reason, only a bunch of :0.log in /var/log/gdm3 but I cant find anything more in there. I'll give it some more time and see if I can provide more info. Thank you very much for your quick responses so far.
Hmm, the last line in /var/log/gdm/:0.log should be the real reason why it is dying. Have you also tried building from xf86-video-intel.git? That should behave better when building against squeeze.
If you are unsure whether anything contains relevant info, don't hesitate just attach it and we can shift through it.
(In reply to comment #8) > Hmm, the last line in /var/log/gdm/:0.log should be the real reason why it > is dying. Have you also tried building from xf86-video-intel.git? That > should behave better when building against squeeze. I tried the git repo and built from master, but theres no change. I think this problem I have does not relate to the intel driver, even if that is what triggers it. I did a debsums check on my system, but didnt find anything. I also ran strace on the start of the /etc/init.d/gdm3 but it didnt give me any further clues. To make it easier to test it out, I'll swap the diskdrive and reinstall a new debian squeeze so I know it is clean, and the test the drivers again and see if it works better.
(In reply to comment #10) > (In reply to comment #8) > > Hmm, the last line in /var/log/gdm/:0.log should be the real reason why it > > is dying. Have you also tried building from xf86-video-intel.git? That > > should behave better when building against squeeze. > > I tried the git repo and built from master, but theres no change. I think > this problem I have does not relate to the intel driver, even if that is > what triggers it. > I did a debsums check on my system, but didnt find anything. I also ran > strace on the start of the /etc/init.d/gdm3 but it didnt give me any further > clues. > > To make it easier to test it out, I'll swap the diskdrive and reinstall a > new debian squeeze so I know it is clean, and the test the drivers again > and see if it works better. A reinstall of squeeze, with no packages from backports, and xf86-video-intel from git repo made it a successful install, together with kernel 3.7.8. Thanks for your time!
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.