You are not logged in.
I upgraded to kernel v2.6.32.2-2 and changed the grub startup line to contain nomodeset (from i915.modeset=1). When I rebooted, however, Xorg would start but leave me with an unresponsive blank screen. I checked Xorg.0.log, but found that it has not been written to since before I rebooted, so there were no errors or warnings.
I also tried to see if it would start with a new user, but it also resulted in a blank screen. Further more, the automatically created .xinitrc and .xsession files were binary files:
$ hexdump .xinitrc
0000000 000d 0000 0101 003d 3d01 0000 0000 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
*
00000b0 0000 0000 0000
00000b6
$# hexdump .xsession
0000000 000d 0000 0002 0034 4902 3400 0000 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
*
0000030 0000 0000 1284 4852 2100 0021 1d00 8145
0000040 0025 0404 0039 8245 004d 0000 0000 0000
0000050 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000
0000064
I'm sure this has to do with the kernel update, as I have rebooted successfully since the last xorg-server update. Can anyone give me pointers on how to fix Xorg?
Thanks
Last edited by justinnhli (2010-01-03 17:14:15)
Offline
Odd; as far as I know they should never be modified by X.
How are you starting X? (For now I'll assume you're using xinit / startx)
Could you try removing the existing .xinitrc and .xsession, recreating them with some minimal content, and preventing modification with:
chattr +i .xinitrc .xsessionAlso, what is the state of your system when X fails? Does it appear to be a kernel panic (e.g., can you toggle numlock)? If you are unable to access the tty which xinit / startx was invoked from, you might be able to get some details writing the output to disk:
xinit &> xorg-debug.txtEDIT:
I'm curious behind the reason for disabling modesetting. Does it make any difference to the problem if it is enabled?
Last edited by chpln (2010-01-03 04:08:23)
Offline
Thanks for looking into this.
I usually use startx, but xinit results in the same thing.
When the screen goes blank, nothing is responsive; there is no cursor, and pressing capslock or numslock doesn't turn the light on. That being the case, it's not surprising that redirecting output doesn't even create the file.
I deleted the .xinitrc and .xsession files, but X still gave the same blank screen. Having no .xsession and a simple .xinitrc doesn't help either:
$ cat .xinitrc
#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)
#
# exec gnome-session
# exec startkde
# exec startxfce4
# exec icewm
# exec openbox
# exec blackbox
exec fluxbox
# exec ratpoison
# exec dwm
# ... or any other WM of your choosing ...Interestingly, if I try to start X from my normal account, everything.log gets appended with junk. Starting X from a new account has no such problem.
I also tried re-installing X, but that didn't do anything.
The reason I disabled modesetting is that if I don't, my screen goes blank much early - when udev is loaded. It's similar to what is described here: http://bbs.archlinux.org/viewtopic.php?id=86357. Adding nomodeset gets me past udev into a login shell.
Offline
Thanks for the link. Your problem does indeed sound very similar. It might be worth keeping an eye on the bug report linked in that thread (http://bugzilla.kernel.org/show_bug.cgi?id=14957) and downgrading to 2.6.31 for the moment.
Offline
There are two different problems here. Comment 7 from the bug report (http://bugzilla.kernel.org/show_bug.cgi?id=14957) states:
Ah. I've figured out what the problem is (at least for me). The commit that
introduced the problem was b42d4c5c6a872815d711e5d51a600f5122c38eee ("drm/i915:
use ACPI LID status for LVDS ->detect hook"). As the commit message states, it
only works "assuming the lid device status is correct." In my case, it isn't.
Which results in a blank screen right after KMS loads video during boot.
The second problem (which I am struggling with) is that if KMS is enabled and loads properly, shortly after logging into X the computer freezes. I am attributing this to my old Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) which NEVER worked well with the new Intel driver.
To have X functionality, I had to disable KMS and load X with the vesa driver. Disabling KMS and trying to intel driver results in the computer freezing on a black screen during X startup.
I should also mention that previously everything worked fine with the i810 driver.
justinnhli, you wouldn't by any chance have this video card?
Offline
I think you hit it head on - I do have the Intel integrated graphics chipset.
How did you tell X to load with the vesa driver? I've been running Xorg for a while without xorg.conf, and looking at Xorg.0.log show that it uses vesa by default (before the kernel upgrade, of course):
(==) Using default built-in configuration (30 lines)
(==) --- Start of built-in configuration ---
Section "Device"
Identifier "Builtin Default intel Device 0"
Driver "intel"
EndSection
Section "Screen"
Identifier "Builtin Default intel Screen 0"
Device "Builtin Default intel Device 0"
EndSection
Section "Device"
Identifier "Builtin Default vesa Device 0"
Driver "vesa"
EndSection
Section "Screen"
Identifier "Builtin Default vesa Screen 0"
Device "Builtin Default vesa Device 0"
EndSection
Section "Device"
Identifier "Builtin Default fbdev Device 0"
Driver "fbdev"
EndSection
Section "Screen"
Identifier "Builtin Default fbdev Screen 0"
Device "Builtin Default fbdev Device 0"
EndSection
Section "ServerLayout"
Identifier "Builtin Default Layout"
Screen "Builtin Default intel Screen 0"
Screen "Builtin Default vesa Screen 0"
Screen "Builtin Default fbdev Screen 0"
EndSection
(==) --- End of built-in configuration ---I will save this as xorg.conf and see what happens.
Offline
Got it. I disabled modesetting:
kernel /boot/vmlinuz26 root=/dev/sda7 ro nomodesetand used the following for xorg.conf:
Section "Device"
Identifier "Builtin Default intel Device 0"
Driver "intel"
EndSection
Section "Screen"
Identifier "Builtin Default intel Screen 0"
Device "Builtin Default intel Device 0"
EndSection
Section "Device"
Identifier "Builtin Default vesa Device 0"
Driver "vesa"
EndSection
Section "Screen"
Identifier "Builtin Default vesa Screen 0"
Device "Builtin Default vesa Device 0"
EndSection
Section "Device"
Identifier "Builtin Default fbdev Device 0"
Driver "fbdev"
EndSection
Section "Screen"
Identifier "Builtin Default fbdev Screen 0"
Device "Builtin Default fbdev Device 0"
EndSection
Section "ServerLayout"
Identifier "Builtin Default Layout"
Screen "Builtin Default vesa Screen 0"
Screen "Builtin Default intel Screen 0"
Screen "Builtin Default fbdev Screen 0"
EndSectionThe fonts are a little out of whack, but that should be easier to fix.
Thanks for all your help!
Offline
justinnhli,
I'm glad you got it working. I will post back if I get my video card (Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)) working with the intel driver. If anyone has any suggestions please let me know!
Thanks
Offline
I found the relevant archlinux bug report: http://bugs.archlinux.org/task/16974
It appears that this issue might? be fixed in the next kernel upgrade. Below is a quote from the bug report.
Comment by Jan de Groot (JGC) - Sunday, 06 December 2009, 09:58 GMT-5
Try kernel 2.6.32 from testing, it should contain fixes for the Intel 855. Using it with KMS is recommended, but you'll lose the ability to use XV then. Intel will release new drivers later this month that should also fix that.
Offline