Description of problem: graphics install does not work. The machine hangs - has to use text install Version-Release number of selected component (if applicable): FC12-Beta How reproducible: Always Additional info: this is a ASUS motherboard with ATI 785G chipset with integrated graphics HD4200 aka. RS880 > lspci -nn 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc Device [1002:9710]
I did installation with latest rawhide (20091030) using 'basic video driver'. after installation, it sets /etc/X11/xorg.conf with visa, which is not showing proper resolution on screen (gnome-display-properties showing unknown monitor). To get proper display, I need to remove that file. xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12.x86_64 anaconda-12.41-1.fc12.x86_64.rpm
after doing that, does X work okay in normal use? no hangs? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*I* did a text install, no removing of drivers. After upgrade (did not work - had to manually yum upgrade the sys) I used "nomodeset" kernel arg. And also at the same time (not very scientifically) install mesa-dri-drivers-experimental. I still have to use "nomodeset" though - that is a certain hang. Was that what you wanted?
thanks...can we get your 'lspci' output? also, can you try kernel -106 without 'nomodeset' and see if that helps? http://koji.fedoraproject.org/koji/buildinfo?buildID=139334 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
lspci - see bug description: > lspci -nn 00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] RS780 Host Bridge Alternate [1022:9601] 00:01.0 PCI bridge [0604]: ASUSTeK Computer Inc. Device [1043:9602] 00:0a.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 5) [1022:9609] 00:11.0 SATA controller [0106]: ATI Technologies Inc SB700/SB800 SATA Controller [IDE mode] [1002:4390] 00:12.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397] 00:12.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398] 00:12.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396] 00:13.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397] 00:13.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398] 00:13.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396] 00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller [1002:4385] (rev 3c) 00:14.1 IDE interface [0101]: ATI Technologies Inc SB700/SB800 IDE Controller [1002:439c] 00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383] 00:14.3 ISA bridge [0601]: ATI Technologies Inc SB700/SB800 LPC host controller [1002:439d] 00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge [1002:4384] 00:14.5 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI2 Controller [1002:4399] 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] HyperTransport Configuration [1022:1200] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Address Map [1022:1201] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Miscellaneous Control [1022:1203] 00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Link Control [1022:1204] 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc Device [1002:9710] 02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 03) 03:05.0 Ethernet controller [0200]: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 [8086:1229] (rev 0c) 03:06.0 SCSI storage controller [0100]: Adaptec AIC-7850 [9004:5078] (rev 01) Kernel -106 without 'nomodeset': hangs once X starts
Thanks. If it's not too much trouble, could you try to get the X log for us? To do this, boot to runlevel 3: add just the number '3' as a kernel parameter - NOT nomodeset. That should boot you to text mode. Then log in and run 'startx'. Presumably it'll hang again quite quickly. When it does, reboot *to runlevel 3 again*, log in, but DON'T startx. Take a copy of /var/log/Xorg.0.log into your home directory. Then you can reboot back to graphical boot with 'nomodeset' enabled, to get a working system, and attach the Xorg.0.log from the failure to this report. Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Tried it twice - both gave zero bytes of nothingness - sorry :-(
so it does hang when you do startx, but the X log is 0 byte? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
It does hang - and Xorg.0.log is zero bytes long - yes
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions). Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
You are kidding - this bug is filed against FC12-Beta!
Kim: sorry, it's an automated message Matej's doing so it catches reports for which it doesn't make much sense :( However, there have actually been a few changes even in the last few days, it'd be worth checking status with the current Rawhide if you didn't already. thanks... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
So, slightly more meaningful question (sorry, really, I was sending the same question as to this to 900+ bugs today, so certainly some of them these questions were kind of weird; sorry, about that): could you attach us to this bug /var/log/dmesg and /var/log/messages from your testing, please? Quite a part of the current Xorg drivers are actually part of kernel, and sometimes when the bug is in the kernel (not in the userland part of Xorg), then the system hangs up even before it can write anything to the log. Thank you
Created attachment 367884 [details] startx with kernel *without* nomodeset arg
Created attachment 367885 [details] /var/log/dmesg with kernel *with* nomodeset
Created attachment 367886 [details] /var/log/mesages with 2 boots - 1'th without nomodeset 2'nd with
All forgiven - It was just too absurd. Nothing exciting to report in favour of kernel-2.6.31.5-117.fc12.x86_64 Still hangs the machine :-( I had looked in /var/log/messages to see if it contained anything informative, but it does not look like that. Attached anyway.
Created attachment 368043 [details] Xorg.0.log from 2.6.31.5-122.fc12.x86_64 Yet another kernel - Still hangs :-(
Any more luck with -127 ? Can you also tell us the reference of your motherboard, thanks.
The motherboard is a ASUS M4A785D-M PRO - is that what you mean by "reference"? I will test newest kernel later today.
Kernel -127 did not work any better than the others (did not work either - hung the machine). This time I was not lucky and did not get any (zero bytes) Xorg.log
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
http://kojipkgs.fedoraproject.org/packages/kernel/2.6.31.6/134.fc12/ care to give this a spin? we got some rs880 fixes from AMD.
So i finally got close to the hw. I works! does not hang the machine any more. the first impressions seems like there are more graphical glitzes - but that can be because of the beta qt from redhat-kde
(In reply to comment #24) > So i finally got close to the hw. > > I works! does not hang the machine any more. > > the first impressions seems like there are more graphical glitzes - but that > can be because of the beta qt from redhat-kde So, does it mean, that this bug can be closed?
Fine by me to close it. Thanks!
Thank you for letting us know.