|Summary:||install hangs at graphics: pci 8086:27A2 Intel 945 Apple Macintosh mini|
|Product:||[Fedora] Fedora||Reporter:||John Reiser <jreiser>|
|Component:||xorg-x11-drv-intel||Assignee:||Adam Jackson <ajax>|
|Status:||CLOSED NEXTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||11||CC:||ajax, august, awilliam, fabian.deutsch, jmorris, kai.willadsen, karl, lyonel, mail, mattr, mcepl, mcepl, mildred-bug.redhat, misc, mlists, pjones, psj, rmaximo, vanmeeuwen+fedora, xgl-maint|
|Target Milestone:||---||Keywords:||CommonBugs, Patch|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-11-08 23:27:24 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description John Reiser 2009-04-06 17:04:18 UTC
Description of problem: Attempted install hangs at the transition to graphical mode using Fedora 11 Beta i386 DVD on Apple Macintosh mini (Intel Core Duo [not Core 2 Duo]) with pci 8086:27A2 Intel 945GM/GMS VGA controller. Version-Release number of selected component (if applicable): anaconda-184.108.40.206 (Fedora 11 Beta i386 DVD) How reproducible: always Steps to Reproduce: 1. attempt fresh install in default graphics mode using Fedora 11 Beta i386 DVD on Apple Macintosh mini Intel Core Duo i686 with pci 8086:27A2 Intel 945 VGA controller 2. 3. Actual results: hang at transition to graphical mode, no response to keyboard. Screen flashes briefly to a few overlapping copies of decimated graphical splash screen in the top 2/3 of the physical screen, but then changes to all white with 4 rows of dark grey dots in a triangular configuration. The rows are about 5 mm apart vertically, and the dots are about 2x2 pixels. The first row has 1 dot, the others have 5, 7, and 9 dots in configurations 2 over 3, 3 over 4, 4 over 5. So it looks like a graphical representation of the triangular number 10 was compressed horizontally until the dots (on the lines with more than one dot) touch each other. Expected results: normal graphical install, beginning with graphical splash screen Additional info: Installing with basic video mode (xdriver=vesa) apparently works (except for an error ejecting the DVD at the end: bug # 492459.)
Comment 1 Matěj Cepl 2009-04-06 23:16:24 UTC
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. When the anaconda crashes, please, switch to the console (Ctrl+Alt+F2) and cp /tmp/X* to some other place -- USB stick, some other computer via network, some on the Internet, and please attach it to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Comment 2 John Reiser 2009-04-06 23:40:49 UTC
As I mentioned in the original Description, the crash is hard enough that there is "no response to keyboard", including no response to Ctrl+Alt+F2. I have re-verified that this is the case by booting once again from Fedora 11 Beta i686 DVD, and observing the crash with the flash of decimated splash screen, then all-white with squished triangular pattern of dark gray dots, and no response to any keystrokes or keystroke combination. The only response I was able to get was power-off, by holding the power button down for about 8 to 10 seconds.
Comment 3 John Reiser 2009-04-07 03:53:33 UTC
I considered attaching /tmp/Xorg.0.log from a boot of graphical install with xdriver=vesa. Perhaps that log might provide some clues, even though it is the "wrong" driver. However, as reported in bug #494394 "bad video on alternate consoles during xdriver=vesa install", all of the other VTn consoles (each of VT1 through VT5) have an out-of-range video signal when VT6 has the graphics that are provided by xdriver=xvesa. Therefore I can think of no way to get at /tmp/Xorg.0.log.
Comment 4 Matěj Cepl 2009-04-07 16:29:05 UTC
(In reply to comment #3) > Therefore I can think of no way to get at /tmp/Xorg.0.log. OK, give us at least vesa's log. It should give us details about the hardware.
Comment 5 John Reiser 2009-04-07 18:16:56 UTC
I'm unsure what is meant by "vesa's log". The install using xdriver=vesa seems to get close to the end, but as in bug #444490 ("missing operating system" at boot ...) the result cannot be booted. Anything that was not written to the filesystem on disk, is not available because VT2 cannot be used to capture it. However, Rescue mode (text console) works after the install. Using Rescue mode, and looking in directory "/root" (the home directory of superuser), I see the anaconda logs, but nothing for X11. I will attach the lspci info obtained using Rescue mode.
Comment 6 John Reiser 2009-04-07 18:17:31 UTC
Created attachment 338561 [details] lspci; lspci -n; lspci -v
Comment 7 Matěj Cepl 2009-04-10 15:17:49 UTC
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Comment 8 John Reiser 2009-04-10 17:33:15 UTC
READ THE FINE DESCRIPTION, AND COMMENT #3, AND COMMENT #5. The software is SO BAD that there is [apparently] NOTHING that can be sent. There is no xorg.conf [at all, ever]; that's the way the software is trying to work, on purpose. Attempting a default graphical install hangs hard at the transition to graphics, with no response to keyboard; so there is no way to get /tmp/Xorg*.log. Attempting an install with xdriver=vesa gets close to the end, but the result does not boot, and anaconda does not save /tmp/Xorg*.log on the installed root filesystem. So Rescue mode (after the boot fails) cannot find Xorg*.log. During the install, the alternate console VT2 is not available because Ctrl-Alt-F2 does not work. So, again, there is apparently no way to get the X server log. If you describe a way to capture Xorg*.log that actually works, then I will do that. All the ways that I can think of (enumerated above) DO NOT WORK. Please READ AND THINK before responding with form-letter requests.
Comment 9 John Reiser 2009-04-12 12:36:28 UTC
Created attachment 339230 [details] /var/log/anaconda.xlog I found this /var/log/anaconda.xlog using Rescue mode. It looks amazingly similar to Xorg*.log. However, the contents near the end of the file appear uninteresting.
Comment 10 John Reiser 2009-04-12 12:38:08 UTC
Created attachment 339231 [details] /var/log/anaconda.syslog Another apparent logfile from installation.
Comment 11 John Reiser 2009-04-12 12:38:54 UTC
Created attachment 339232 [details] /var/log/anaconda.log Another apparent log file from installation.
Comment 12 John Reiser 2009-04-12 12:39:49 UTC
Created attachment 339233 [details] output from 'dmesg' in Rescue mode
Comment 13 John Reiser 2009-04-12 12:49:18 UTC
Created attachment 339239 [details] /var/log/Xorg.0.log from 'startx' in Rescue mode Booting into Rescue mode with additional kernel parameter " xdriver=vesa", and upon chroot to the installed Fedora 11 Beta i386 root partition, then 'startx' hangs hard: blank display, video out of range [message from LCD monitor hardware], no response. Here's /var/log/Xorg.0.log upon rebooting. One interesting part at the end of the file is a traceback from SIGSEGV: ----- [snip] (II) AIGLX: Screen 0 is not DRI2 capable (II) AIGLX: Screen 0 is not DRI capable (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 Backtrace: 0: /usr/bin/X(xorg_backtrace+0x3b) [0x812e12b] 1: /usr/bin/X(xf86SigHandler+0x9e) [0x80c0dbe] 2: [0x2a1400] 3: /usr/bin/X(DamageUnregister+0x3a) [0x81771ba] 4: /usr/lib/xorg/modules//libshadow.so(shadowRemove+0x4e) [0xeeae1e] 5: /usr/lib/xorg/modules//libshadow.so [0xeeb2d4] 6: /usr/bin/X [0x80bfb8e] 7: /usr/bin/X [0x810bc9c] 8: /usr/bin/X [0x8117fec] 9: /usr/bin/X [0x811e53c] 10: /usr/bin/X [0x80c86ee] 11: /usr/lib/xorg/modules/drivers//vesa_drv.so [0xab1918] 12: /usr/bin/X [0x80c087c] 13: /usr/bin/X [0x8159fde] 14: /usr/bin/X [0x80da995] 15: /usr/bin/X [0x80c5152] 16: /usr/bin/X [0x8144950] 17: /usr/bin/X [0x8174c79] 18: /usr/bin/X [0x813e5c6] 19: /usr/lib/xorg/modules/extensions//libglx.so [0x5af50a] 20: /usr/bin/X(main+0x440) [0x806bb70] 21: /lib/libc.so.6(__libc_start_main+0xe6) [0xb20736] 22: /usr/bin/X [0x806af71] Fatal server error: Caught signal 11. Server aborting -----
Comment 14 Adam Williamson 2009-04-16 22:26:07 UTC
As this is a 'common' hardware configuration - any Mac Mini, it looks like - and a fatal problem, it's fairly important: I'm adding it to F11Target at least, may be a candidate for F11Blocker. I'd be rather interested in what happens if you try to boot a recent F11 live CD image, actually. Can you try that? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 15 Adam Williamson 2009-04-16 22:30:34 UTC
Can you test with KMS disabled - add 'nomodeset' as a kernel parameter for the installer, and don't use vesa - and see if that changes anything? Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 16 John Reiser 2009-04-17 03:04:50 UTC
(In reply to comment #15) > Can you test with KMS disabled - add 'nomodeset' as a kernel parameter for the > installer, and don't use vesa ... Not much change. At the transition from character cell VGA to graphics: the screen goes blank, then an underline cursor appears for about one second in the top left corner, then the screen flashes very briefly and goes blank, and the machine hangs hard with no response to keyboard. The backlight is on, but the raster is all black. I booted today's 2009-04-16 (Thurs.) i386 boot.iso (md5sum dfd9dbf3e4d6d53c3cd8a74d4f47dcac), chose the EFI boot option, interrupted the GRUB countdown before autoboot, added " nomodeset" to the kernel command line, and activated GRUB boot with 'b'. About 16 seconds later, the VGA console showed two Tasmanian devils and began scrolling the kernel console drivel. From the beginning: the 640x480 GRUB screen was not centered in the 1280x1024 display; the GRUB screen was shifted a couple centimeters up and to the right. Then the anaconda character cell graphics (Disk Found: want to test the media?) left the bottom 1/6 of the display blank: the blue background was only on the top 1280x860 or so, instead of covering the whole 1280x1024. Anaconda announced itself as 220.127.116.11, then tried to enter graphics mode, and hung.
Comment 17 John Reiser 2009-04-17 03:11:27 UTC
(In reply to comment #14) > As this is a 'common' hardware configuration - any Mac Mini, it looks like - I know of 4 different hardwares that are called Apple Mac mini. The earliest is a 32-bit PowerPC CPU uniprocessor with ATI Radeon 9200 graphics; see bug #494642. Then there was the machine for this bug report: a 32-bit Intel Core Duo (32-bit i686 only) with Intel 945 GM graphics. Subsequently Apple changed the CPU to Intel Core 2 Duo (x86_64), and the graphics to nVidia GEforce 9400M on the high end, or Intel 950 on the low end.
Comment 18 John Reiser 2009-04-17 03:24:02 UTC
(In reply to comment #14) > I'd be rather interested in what happens if you try to boot a recent F11 live > CD image, actually. All i386 Snap 1 images (last Friday Apr.10: DVD, CD, boot.iso, netinst.iso, PXE, Live) crashed early, before graphics, because of bug #495261 (libaudit.so.0 not found.) That bug has been fixed, but there have been no new Live images yet.
Comment 19 Adam Williamson 2009-04-17 16:44:10 UTC
Yeah, you're right there've been different Mac Mini generations...I just meant it's a chip that quite a lot of people will own because quite a lot of people went out and bought Mac Minis, it's not just one obscure motherboard or something. For the live CD...yeah, we haven't built a Test Day one since April 2nd, so testing that probably wouldn't accomplish much :\. At least we know this isn't a KMS issue, now. Thanks for the info. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 20 Adam Williamson 2009-04-17 16:49:34 UTC
*** Bug 490496 has been marked as a duplicate of this bug. ***
Comment 21 Adam Williamson 2009-04-17 16:50:12 UTC
Note that 490496 is what appears to be the same bug, in a different Mac system with the exact same Intel adapter (going by PCI ID). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 22 John Reiser 2009-04-19 18:34:06 UTC
Created attachment 340250 [details] /tmp/X.log from failed start by anaconda I see progress with today's i386 boot.iso (2009-04-19 Sunday). Rawhide report claims: kernel-18.104.22.168-100.fc11 xorg-x11-drv-intel-2.7.0-1.fc11 xorg-x11-server-1.6.1-6.fc11 X11 fails to start, but anaconda recognizes this, recovers, and enters text mode. Later anaconda crashes (bug 496503; includes hardware details and kernel logs) but meanwhile I grabbed /tmp/X.log. Ultimately the xserver cannot find a usable screen configuration, but there are various preceding oddities: ----- (WW) intel(0): libpciaccess failed to read 128kB video BIOS: Unknown error 4294967291 (WW) intel(0): VBIOS initialization failed. [snip] (II) intel(0): EDID for output VGA1 (II) intel(0): Output VGA1 disconnected (WW) intel(0): No outputs definitely connected, trying again... (II) intel(0): Output VGA1 disconnected (WW) intel(0): Unable to find initial modes ----- It's probably best to look at the complete attachment.
Comment 23 Karl Lattimer 2009-04-25 15:09:30 UTC
Same here on a macbook 1,1 Xorg works if KMS is disabled (nomodeset)
Comment 24 John Reiser 2009-04-29 16:06:17 UTC
The Fedora 11 i386 Preview DVD has gotten worse: Rescue mode now crashes, too. These modes crash: default, vnc, xdriver=vesa, text, rescue. Choosing default but adding " nomodeset" works. A netinst.iso composed by pungi from rawhide on April 25 (Saturday) detects failure to start graphics, and falls back to text mode. Rescue mode works.
Comment 25 August Schwerdfeger 2009-05-23 22:54:17 UTC
Confirming on the Fedora 11 Preview live-CD and CD for network installation, both downloaded on May 22. Of the above suggested kernel parameters, only "nomodeset" provides a successful boot. Have not attempted an install.
Comment 26 Mildred 2009-05-24 09:01:32 UTC
Do you think bug #495149 is a duplicate of this bug ? The problem described is that it's impossible at all to boot rawhide F11 with EFI, and booting in legacy mode is only possible with KMS disabled.
Comment 27 Adam Williamson 2009-05-25 19:31:44 UTC
*** Bug 495149 has been marked as a duplicate of this bug. ***
Comment 28 Adam Williamson 2009-05-25 19:31:57 UTC
Indeed, thanks for the tip. Looks the same.
Comment 29 Bug Zapper 2009-06-09 13:21:03 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 30 Fabian Deutsch 2009-06-10 18:22:52 UTC
Anything new on this? Today I tried F11 final on my MacBook using the same Intel Graphics Adapter, unfortunately I can not even boot the live cd as it does not boot into GDM.
Comment 31 John Reiser 2009-06-10 22:23:38 UTC
(In reply to comment #30) > unfortunately I can not even boot the live cd as it does not boot into GDM. Fedora-11-i686-Live CD-ROM works for me if I add " nomodeset" to the kernel command line. When the message "Auto boot in ..." appears, then type a <Tab> to get a GRUB screen with choices for boot. Type another <Tab> to get the full text of the kernel command line; then append " nomodeset" onto the end of the line, and type <Enter> to activate. It took about 7 or 8 seconds before the screen changed and booting began. Fedora-11-i386-DVD also installs for me if I append " nomodeset" onto the end of the kernel command line before booting. Without the 'nomodeset' then it crashes hard after "Waiting for devices to settle..." from within "Running /sbin/loader".
Comment 32 Fabian Deutsch 2009-06-13 16:02:04 UTC
(In reply to comment #31) > (In reply to comment #30) > > unfortunately I can not even boot the live cd as it does not boot into GDM. > > Fedora-11-i686-Live CD-ROM works for me if I add " nomodeset" to the kernel > command line. This workaround also works for me. Problematic is, that the keyboard of my MacBook doesn't work in grub. Which wasn't a problem as long as no changes were needed in grub. thanks for the hint though.
Comment 33 Adam Williamson 2009-06-15 16:47:05 UTC
fabian: well, you can just add it to /boot/grub/menu.lst instead, that way you don't have to do it at boot time. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 34 Adam Williamson 2009-06-17 01:09:12 UTC
*** Bug 504933 has been marked as a duplicate of this bug. ***
Comment 35 Felix Möller 2009-07-05 09:27:16 UTC
I have tried todays git of xf86-video-intel (version: 74227141923a2f5049592219ab80e8733062a5d9) which required libdrm-2.4.11. Sadly this did not help at all. Is there anything to help to resolve this bug? My graphics performance is really a show stopper. :-(
Comment 36 Matt Rogers 2009-07-08 21:25:59 UTC
This sounds like http://bugs.freedesktop.org/show_bug.cgi?id=21710 and I had this happen to me upon installing Fedora 11 as well. The relevant commit has been merged for 2.6.31. Perhaps we can get it merged for a later Fedora kernel update?
Comment 37 Felix Möller 2009-07-09 06:57:19 UTC
Thanks alot Matt. The patch is applied in Linus tree at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b5aa8a0fc132dd512c33e7c2621d075e3b77a65e Is there any kernel of the day repository for Fedora where i can find a current 2.6.31 kernel?
Comment 38 Felix Möller 2009-07-09 07:37:14 UTC
ok I found kernel 2.6.31 at ftp://ftp.uni-bayreuth.de/pub/linux/fedora/linux/development/i386/os/Packages/kernel-2.6.31-0.42.rc2.fc12.i586.rpm an installed it on my F11. It does work wonderfully on my internal display with KMS und UXA. Really great and faster than ever! BUT: XAA does not work anymore for me. With my Virtual size set in xorg.conf to 2960x1050 I get the following on Xorg-Startup: (==) intel(0): VideoRam: 4194303 KB (II) intel(0): Attempting memory allocation with tiled buffers. (EE) intel(0): max_gtt_map_size: 52264kb. (II) intel(0): Tiled allocation successful. (II) UXA(0): Driver registered support for the following operations: (II) solid (II) copy (II) composite (RENDER acceleration) (==) intel(0): Backing store disabled (==) intel(0): Silken mouse enabled (II) intel(0): Initializing HW Cursor (EE) intel(0): max_gtt_map_size: 52264kb. (II) intel(0): Fixed memory allocation layout: (II) intel(0): 0x00000000-0xffff4fff: DRI memory manager (4194260 kB) (II) intel(0): 0x00000000: end of aperture (II) intel(0): BO memory allocation layout: (II) intel(0): 0x00000000: start of memory manager (II) intel(0): 0x02000000-0x03067fff: front buffer (16800 kB) (II) intel(0): 0x01400000-0x01409fff: HW cursors (40 kB) (II) intel(0): 0xffff5000: end of memory manager failed to add fb Fatal server error: AddScreen/ScreenInit failed for driver 0 X starts with a virtual size of 1680x1050 but I cannot get any resolution higher than 1280x800 to my external display...
Comment 39 Adam Williamson 2009-07-15 21:00:10 UTC
We don't care at all about XAA not working if UXA does work. XAA will be deprecated in favour of UXA anyway. Thanks for the note of a patch, Matt; Kristian, other X guys, is there any chance we could get this patch merged for future F11 updates? Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 40 Paul Jenner 2009-08-26 19:10:06 UTC
This is resolved for me with kernel 22.214.171.124-32 from F11 updates-testing. On a Mac Mini with this chipset booting in legacy BIOS mode, I am now able to boot with KMS and use X with UXA. [root@localhost xsessions]# lspci -nn | grep Graphics 00:02.0 VGA compatible controller : Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03) [root@localhost xsessions]# rpm -q kernel xorg-x11-drv-intel kernel-126.96.36.199-32.fc11.x86_64 xorg-x11-drv-intel-2.7.0-7.fc11.x86_64
Comment 41 John Reiser 2009-08-26 22:59:38 UTC
The problem persists for me. During an initial install from DVD the machine fails to make the transition to graphical mode. I have verified that the problem persists using Fedora-12-Alpha-i386-DVD.iso burned to a DVD. Booting and selecting the first choice "Install or update..." gets a hard crash at the transition from text to graphics mode. The screen goes black, the backlight on the display is off, and there is no response to the keyboard <Ctrl><Alt>F2 trying to get a shell on VT2. The only option is power cycle: turn off, turn on. Again using the Fedora 12 Alpha DVD for i386, but selecting the second choice to install with basic video driver, gets a soft hang. The screen is blank, the backlight is on, I can get a shell on VT2. "ps ax" suggests that "modprobe fcoe" is going nowhere in async_D+ state. (There is no Fibre Channel over ethernet on this box. There is an external harddrive connected via ieee1394 (400MHz FireWire.) According to Apple "About this Mac" the hardware is: Model Name: Mac mini Model Identifier: Macmini1,1 Processor Name: Intel Core Duo Processor Speed: 1.66 GHz Number Of Processors: 1 Total Number Of Cores: 2 L2 Cache: 2 MB Memory: 2 GB Bus Speed: 667 MHz Boot ROM Version: MM11.0055.B08 Intel GMA 950: Chipset Model: GMA 950 Type: Display Bus: Built-In VRAM (Total): 64 MB of Shared System Memory Vendor: Intel (0x8086) Device ID: 0x27a2 Revision ID: 0x0003 Displays: 1740CX: Resolution: 1280 x 1024 @ 60 Hz Depth: 32-Bit Color Core Image: Hardware Accelerated Main Display: Yes Mirror: Off Online: Yes Quartz Extreme: Supported Rotation: Supported
Comment 42 John Reiser 2009-08-26 23:05:11 UTC
Examining the Packages directory on Fedora-12-Alpha-i386-DVD, I see: kernel-PAE-2.6.31-0.125.4.2.rc5.git2.fc12.i686.rpm xorg-x11-drv-intel-2.8.0-3.fc12.i686.rpm
Comment 43 Adam Williamson 2009-08-27 02:44:20 UTC
reiser: your second problem, for sure, is a different bug, so please report it separately. not sure about the first. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 44 John Reiser 2009-08-27 03:05:57 UTC
(In reply to comment #43) > reiser: your second problem, for sure, is a different bug, so please report it > separately. not sure about the first. https://bugzilla.redhat.com/show_bug.cgi?id=519618 is for Fedora-12.
Comment 45 Mildred 2009-10-30 19:07:40 UTC
The issue I described in bug #495149 (a duplicate of this bug) is gone. I can boot with EFI on 2.6.31 kernel with KMS and everything works fine. Perhaps this issue is resolved as well.
Comment 46 Adam Williamson 2009-10-31 05:10:17 UTC
is anyone who reported issues in this thread still having them with a recent Rawhide, F12 beta, or nightly build - http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ ? Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 47 John Reiser 2009-10-31 16:24:02 UTC
As reported yesterday in related bug #519618, a DVD from Thursday's rawhide for F12 successfully transitions to graphics mode using either the first choice "Install or upgrade an existing system" or the second choice "basic video driver." So F12 is in good shape. F11+updates still hangs on the first choice, but succeeds with basic video driver. That's using a DVD composed yesterday from F11+updates. Therefore F11 might benefit from a back port of xorg-x11-drv-intel from F12. Or, considering the possible interactions with kernel, and the substantial work still required to make F12 fully functional on rv600-series radeon chips, it might be better to suspend work indefinitely on this bug 494390.
Comment 48 Adam Williamson 2009-10-31 19:26:41 UTC
well, that's up to the maintainer; I just wanted to be sure F12 was OK. thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 49 Matěj Cepl 2009-11-05 18:25:27 UTC
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. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . 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.]
Comment 50 John Reiser 2009-11-05 20:57:29 UTC
As explained in comment #47 above (from 5 days ago: Saturday, 2009-10-31), F12 is in good shape. However, F11 stlil hangs on the default first choice, but succeeds with "basic video driver."
Comment 51 Matěj Cepl 2009-11-08 23:27:24 UTC
Thank you for letting us know about Rawhide. I am afraid we won't backport intel driver to F11, because it depends too much on particular state of kernel and generally the backport would be more complicated than we want to invest into F11 distribution. Users who need this functionality working, are encouraged to upgrade to F12 when it is released. Closing as CLOSED/NEXTRELEASE.