Bug 494390

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.

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.

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.

(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.

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.

Created attachment 338561 [details]
lspci; lspci -n; lspci -v

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.

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.

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.

Created attachment 339231 [details]
/var/log/anaconda.syslog

Another apparent logfile from installation.

Created attachment 339232 [details]
/var/log/anaconda.log

Another apparent log file from installation.

Created attachment 339233 [details]
output from 'dmesg' in Rescue mode

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

-----

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

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

(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 11.5.0.44, then tried to enter graphics mode, and hung.

(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.

(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.

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

*** Bug 490496 has been marked as a duplicate of this bug. ***

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

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-2.6.29.1-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.

Same here on a macbook 1,1

Xorg works if KMS is disabled (nomodeset)

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.

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.

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.

*** Bug 495149 has been marked as a duplicate of this bug. ***

Indeed, thanks for the tip. Looks the same.

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

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.

(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".

(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.

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

*** Bug 504933 has been marked as a duplicate of this bug. ***

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. :-(

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?

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?

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...

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

This is resolved for me with kernel 2.6.30.5-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 [0300]: 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-2.6.30.5-32.fc11.x86_64
xorg-x11-drv-intel-2.7.0-7.fc11.x86_64

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

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

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

(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.

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.

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

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.

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

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.]

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."

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.