The Xorg.0.log.old has a backtrace in the end, so this tells us that Xorg is crashing when you do a VT switch (gdm then detect that Xorg isn't running anymore and spawns a new session).
In order to analyze this crash further we would need a full backtrace of the crash. There is an (admittedly a little messy) explanation for how to do it at https://wiki.ubuntu.com/X/Backtracing . Looking forward, however, what we will be able to do with a full backtrace is to forward the bug upstream, and the fix may or may not get into another stable intel driver (2.7.x). What would be more useful would be if you could test the bleeding edge drivers from the xorg- edgers PPA. Even in this case, however, upstream may need a test case with a newer kernel. For ubuntu Karmic, the VT switches will be handled by new code (in the kernel instead of the X-driver). So what would be really useful would be if you could test a Karmic and check if the bug is still present there. See https://lists.ubuntu.com/archives/ubuntu-x/2009-June/000578.html for some more explanation about how this works in Karmic. PS: It is relatively safe to run apport-collect with respect to private data. For xorg-bugs it includes a number of logs and configuration files, but I have never seen anyone have anything private in there. The closest thing may be the serial number of your monitor, which may be included in the output of xrandr --verbose (and sometimes in Xorg.0.log) and possibly other hardware serial numbers. There may be privacy concerns when the core dumps of crashes are uploades, but those bugs are usually marked as private by default. -- [i965GM] PPA version 2:2.7.1-0ubuntu1~xup~1 doesn't let me suspend https://bugs.launchpad.net/bugs/385497 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
