Bug 746309 - [RV530] After yum update, subsequent startx invocation produces segfault in X.
Summary: [RV530] After yum update, subsequent startx invocation produces segfault in X.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 14
Hardware: i686
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jérôme Glisse
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: [cat:modesetting]
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-14 18:02 UTC by George R. Goffe
Modified: 2018-04-11 15:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 13:32:54 UTC
Type: ---


Attachments (Terms of Use)
tar.gz file of a directory containing core files and logs. (1.40 MB, application/x-gzip)
2011-10-16 20:36 UTC, George R. Goffe
no flags Details
/var/log/dmesg (86.25 KB, text/plain)
2011-10-17 10:13 UTC, George R. Goffe
no flags Details
/var/log/dmesg.old (86.42 KB, text/plain)
2011-10-17 10:14 UTC, George R. Goffe
no flags Details
uname-a.output from the archive (103 bytes, text/plain)
2011-10-18 12:04 UTC, Matěj Cepl
no flags Details
Xorg.0.log from the archive (71.46 KB, text/plain)
2011-10-18 12:04 UTC, Matěj Cepl
no flags Details
Xorg.0.log.old from the archive (71.41 KB, text/plain)
2011-10-18 12:04 UTC, Matěj Cepl
no flags Details
Xorg.9.log from the archive (50.29 KB, text/plain)
2011-10-18 12:04 UTC, Matěj Cepl
no flags Details
yum.log from the archive (335.35 KB, text/plain)
2011-10-18 12:05 UTC, Matěj Cepl
no flags Details

Description George R. Goffe 2011-10-14 18:02:49 UTC
Description of problem:

After running yum update command to get the latest FC14 updates to my system I rebooted my system. When I startx, I get a segfault in the x11 server. The system is unusable now so I'm having trouble getting debug information. I have several core files and several Xorg.0.log files.

Version-Release number of selected component (if applicable):

unknown at this time

How reproducible:

Happens every time, during startx.

Steps to Reproduce:
1.see description
2.
3.
  
Actual results:

see description

Expected results:

see description

Additional info:

Comment 1 George R. Goffe 2011-10-14 18:04:33 UTC
Hi,

I'm stuck in line mode now on xterms, is there an ftp site where I can send my debug information?

George...

Comment 2 Matěj Cepl 2011-10-15 22:04:27 UTC
(In reply to comment #1)
> Hi,
> 
> I'm stuck in line mode now on xterms, is there an ftp site where I can send my
> debug information?

what about saving the files to USB key?

Thanks for trying

Comment 3 George R. Goffe 2011-10-16 20:36:04 UTC
Created attachment 528415 [details]
tar.gz file of a directory containing core files and logs.

Contents of this file are:

-rw-------   1 root root 1798144 Oct 13 23:23 core.3549
-rw-------   1 root root 1798144 Oct 13 23:39 core.3616
-rw-------   1 root root 1798144 Oct 13 23:14 core.4035
-rw-------   1 root root 1798144 Oct 13 23:18 core.4115
-rw-r--r--   1 root root     103 Oct 13 23:22 uname-a.output
-rw-r--r--   1 root root   73177 Oct 13 23:18 Xorg.0.log
-rw-r--r--   1 root root   73125 Oct 13 23:14 Xorg.0.log.old
-rw-r--r--.  1 root root   51498 Apr  7  2011 Xorg.9.log
-rw-------   1 root root  343400 Oct 13 23:18 yum.log

Comment 4 Matěj Cepl 2011-10-17 07:45:35 UTC
Backtrace:
[    93.212] 0: /usr/bin/X (xorg_backtrace+0x3c) [0x80e835c]
[    93.212] 1: /usr/bin/X (0x8048000+0x5dec6) [0x80a5ec6]
[    93.212] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0x8fd40c]
[    93.212] Segmentation fault at address (nil)
[    93.212] 
Fatal server error:
[    93.212] Caught signal 11 (Segmentation fault). Server aborting

This kind of backtrace usually means that the crash is actually somewhere in the kernel-land. Would you be able to get us also output of the program dmesg, please?

dmesg >dmesg.out

and attach here (only) dmesg.out, please.

Thank you

Comment 5 George R. Goffe 2011-10-17 10:13:35 UTC
Created attachment 528509 [details]
/var/log/dmesg

I'm in the process of re-installing this system as fc14-x86_64 and have made backup tar files of all the "current" partitions. Here's /var/log/dmesg from those tar files.

Comment 6 George R. Goffe 2011-10-17 10:14:58 UTC
Created attachment 528510 [details]
/var/log/dmesg.old

Here's /var/log/dmesg.old from the same system, extracted from a tar backup of that systems /var partition.

Comment 7 Matěj Cepl 2011-10-18 12:04:27 UTC
Created attachment 528790 [details]
uname-a.output from the archive

Comment 8 Matěj Cepl 2011-10-18 12:04:36 UTC
Created attachment 528791 [details]
Xorg.0.log from the archive

Comment 9 Matěj Cepl 2011-10-18 12:04:43 UTC
Created attachment 528792 [details]
Xorg.0.log.old from the archive

Comment 10 Matěj Cepl 2011-10-18 12:04:51 UTC
Created attachment 528793 [details]
Xorg.9.log from the archive

Comment 11 Matěj Cepl 2011-10-18 12:05:00 UTC
Created attachment 528794 [details]
yum.log from the archive

Comment 12 Jérôme Glisse 2011-10-18 14:08:20 UTC
We don't support UMS, remove
vga=794 nomodeset drm.debug=0x04

From your kernel command line

Comment 13 George R. Goffe 2011-10-18 22:58:31 UTC
Jerome,

What is UMS?

I'm a little confused about what you don't support.

You don't support the vga= parameter any more either?

You don't support nomodeset?

You don't support drm.debug=0x04?

Thanks,

George...

Comment 14 Matěj Cepl 2011-10-24 12:23:59 UTC
(In reply to comment #13)
> Jerome,
> 
> What is UMS?
> 
> I'm a little confused about what you don't support.
> 
> You don't support the vga= parameter any more either?
> 
> You don't support nomodeset?
> 
> You don't support drm.debug=0x04?

We have never really supported vga= much, we really don't care much about nomodeset, you could leave drm.debug there. Please, post requested logs.

Thank you

Comment 15 Fedora End Of Life 2012-08-16 13:32:57 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


Note You need to log in before you can comment on or make changes to this bug.