Hide Forgot
Description of problem: VESA drivers used in fallback mode How reproducible: Always Steps to Reproduce: Install HD 6870 card and boot Catalyst 11.6 (ATI) and 11.4 (RPMFusion) do not work (and not your issue). Would like to be included in development testing on this card if possible.
please attach dmesg + lspci -vv -x this gpu is definitly supported in f15
Created attachment 511408 [details] dmesg - no xorg.conf
Created attachment 511409 [details] lspci - no xorg.conf
Created attachment 511410 [details] dmesg - xorg.conf - fallback mode
Created attachment 511411 [details] lspci - fallback mode
The machine works fine in VESA mode ... MSI HD 6870. When the machine boots without a xorg.conf, the boot process stops just after the "smolt" console message. We can CTRL-ALT-F1 and get to a login to run tests .. but the graphical screen does not appear on DVI 1 or DVI 2 ... which were both connected. Do we need to create an manual xorg.conf for this card ?
Remove nomodeset from kernel boot we don't support this gpu without kms
Stupid question ... how did nomodeset get there to begin with ?
Did you install with basic videomode ?
xorg.conf -> xorg.conf.good grub.conf has nomodeset removed leaving rhgb quiet intact On boot, the screen goes black and NOTHING happens, the monitor goes to sleep. The card has two DVI slots, both gave same results. F15-beta worked FINE, we could not get F15 to install with HD6870 driver so we used basic video mode (xorg.conf is from that mode, I would suppose). Using grub screen, we put the nomodeset back in so we could get to a terminal and fix the system "permanently" ... this has me baffled ... Some place between F15-beta (fully updated) and F15 there must have been a regression ... What xorg driver is this thing using? Should the system auto-configure this card (manual xorg.conf)?
Attach dmesg when booting without nomodeset and with drm.debug=4
rem xorg.conf file rem nomodeset kernel param add drm.debug=4 kernel param machine will not boot to usable state ... the keyboard and screen go un-responsive just after the grub splash screen goes away, then the monitor reports a lost signal. The power button is non-responsive unless you hold it down for 5 seconds. When I do get the the machine back up (by using the 'nomodeset'), I have to add the xorg.conf for VESA mode to get back to any GUI at all. By this time the dmesg appears to be over written. If you have a clever way to preserve it, I will be glad to repeat the test. I attached the log files from today's date. To summarize: nomodeset + xorg.conf (vesa) - machine boots and runs with gui in fallback no nomodeset, no xorg.conf, screen goes black after grub splash and dies -------------------------- I suppose I could try no nomodeset, no xorg.conf and then boot with a run live after that and see if there is a dmesg .... ??? Your call.
Created attachment 511826 [details] log files
Then attach /var/log/messages Also try removing rhgb from kernel boot line. When nomodeset you see properly the boot splash ?
All of the LOG files from the last test are attached: dmesg (useless because reboot destroyed), xorg, messages, boot. The boot splash (with filling Fedora logo) is not present - ever. We get the three lines racing across the bottom of the screen using VESA or CATALYST drivers (not sure of kernel parms required for CATALYST). We have tried, to date: VESA (kernel: nomodeset rhgb quiet) 3 lines racing, no splash, WORKS. ati/mesa (kernel: rhgb quiet) locks up just after grub rpmfusion catalyst 11.4 (kernel: nomodeset rhgb quiet) boot stops at smolt message amd catalyst 11.6 (kernel: nomodeset rhgb quiet) boot stops at "smolt" message In both of the catalyst cases, ctrl-alt-F2 gets us to login and we can replace the xorg.conf (vesa driver) to get the machine back. I have not varied the kernel parameters for either catalyst case, as it is not properly supported by fedora, I really don't care to use them. Both CATALYST drivers have been uninstalled from system. ati/mesa is presently installed. Using xorg.conf to force VESA mode
Nothing we can do without log or hw access
Additional testing is: I have the machine booting into multi-user mode so I can "startx" manually. If I remove the nomodeset, the machine NEVER boots. Screen goes blank, monitor goes to sleep ... end of story. If I leave the nomodeset, X crashes if I remove the xorg.conf (vesa) file. It does try to startx with the radeon driver, but, "it can't find a screen" .. and crashes. IS THERE A WAY TO ENABLE KERNEL MODE SETTING AFTER BOOT? IS THERE A WAY TO REMOVE ALL THE GRAPHICAL BOOT COMPONENTS so that I can REMOVE the NOMODESET? Something during the boot process requires the NOMODESET ... but the RADEON drivers can't seem to survive this. There are quite a few reported, most say that INTEL and nVidia can hanlde this process, but RADEON can not. The F15 BETA RUN LIVE worked fine ... what happened ??
Radeon driver works fine with nomodeset i have it working with several cards (around 20 different radeon gpu) but it's not a supported way, nomodeset == vesa on new hw like your. To try to load radeon after boot start kernel with radeon.modeset=0 3 Then as root or with sudo through ssh do: rmmod radeon modprobe radeon modeset=1
The machine is being booted into multi-user mode. kernel is passed: rhgb nomodeset ... anything else and boot stops We have the multi-user symlink to log in CLI: as root we: modprobe -r -v drm radeon modprobe -v drm modprobe -v radeon modeset=1 system locks up. modprobe -r -v drm radeon modprobe -v drm modprobe -v radeon modeset=0 does not lock up system, but the radeon driver complains about the modeset, and startx fails. It seems like the graphical boot (nomodeset) is conflicting with the radeon driver (of course) ... but the system hangs if I remove the NOMODESET from the kernel parms, even going to multi-user. How can I get this system to go CLI and NOT USE ANY GRAPHICS AT ALL UNTIL I TYPE STARTX ????
Your gpu might be faulty. Here 6850 which is very close to 6870 (only clock and difference in 3d engine) works fine. Test it under another os or with proprietary driver. There is nothing we can do without being able to either get log or reproducing hw.
Nothing is wrong with the card ... it runs F15-BETA wonderfully. This is it ... last test ... and final solution. We loaded F15-Beta (third time) ... the card performed FLAWLESSLY. Booted, ran, shutdown ... FLAWLESSLY. We ran the updates (yum) ... rebooted ... system did not go graphical. Blank screen, no mouse cursor, no F-Key control (ALT-F2) ... NOTHING. THERE IS A REGRESSION BETWEEN F15-BETA and F15 FINAL. ==================================== Final Solution: Installed UBUNTU 11.4 ... system works fine with Gnome3 and Unity, user happy (but user WANTS Fedora which is installed on all other systems).
I'm getting what I think is the same problem as this. But with Fedora 16 and I can't even install. If I do regular install I see the filling Fedora logo but it never files. If I try the basic video option I get a white rectangle on the bottom left of the screen.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. 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 '15' 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 15 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