ubuntu-x-swat team mailing list archive

[Geir Ove Myhr <gomyhr@xxxxxxxxx>]

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-X,
which is subscribed to xserver-xorg-video-intel in ubuntu.