Bug 596985

Booting with serial console shows nothing unusual.

A third attempt with basic video driver using Radeon HD 4550 (pci 1002:9540) succeeds enough to get into bug 596585 (traceback from harddrive partitioner.)  During reboot the console switches back to VT1, and displays "ImportError: No module named gi" between the lines "Starting graphical installation" and "loading /lib/kbd/keymaps/...".

Can you do a text install to get through anaconda?  Can you do a VNC install and see if X works post-install?  When you say the machine is hung, are they keyboard lights flashing?  Do you have any other evidence whether X is hung vs. the entire machine?

Created attachment 417665 [details]
/var/log/Xorg.0.log

Text install (append " text" to boot command line) does not offer custom disk partitioning, so I cannot use text mode.
VNC install (append " vnc" to boot command line) works, at least until it runs into bug 596585 (traceback from custom harddrive partitioner)
All 3 keyboard LEDs (numlock, capslock, scrolllock) are off and not flashing.
Waiting at blank screen with "No video signal" (detected and displayed by microcode in LCD display) for 75 seconds gives nothing.  Then typing <ctrl><alt><del> reboots.

Will change Component to xorg-x11-drv-ati-6.13.1-0.20100519git428125c09.fc14.x86_64
because video card is now
PCI:*(0:1:0:0) 1002:9540:174b:e970 ATI Technologies Inc RV710 [Radeon HD 4550] rev 0

I cannot figure out how to change Component to xorg-x11-drv-ati.  There is no Edit link next to the Component field, the scroll box arrows allow access to only one component (anaconda) which cannot be over-typed, and Clicking on the Component link just presents a list of all components, with nice explanations but no means to change this bug to some other component.

Please change this bug to Component xorg-x11-drv-ati.

Now it lets me change Component to xorg-x11-drv-ati.  Let's see if it works.

Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information especially concerning your hardware we require that will be helpful in our diagnosis of this issue.

If the anaconda crashes during the switching to the graphic mode, most likely the problem lies in Xorg support for your graphics chip. There are couple of options how we can obtain information necessary for resolving the issue.

If the computer is not completely frozen when installation fails, switch to the console (Ctrl+Alt+F2) and copy /tmp/X* and /var/log/anaconda.xlog to some other place -- USB stick, some other computer via network, somewhere on the Internet, and please attach it to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

If the computer is completely useless after installation fails, you can also install Fedora with a VESA mode driver (see http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/ for more information on that). Then after successful installation you can collect /var/log/anaconda.xlog, /var/log/Xorg.0.log, and the output of the program dmesg instead.

Or you can install Fedora in a text mode completely, and then start X after that. If it fails, still /var/log/Xorg.0.log and the output of dmesg program from the failed attempt to start X would be useful.

We will review this issue again once you've had a chance to attach this information.

Thank you very much in advance.

Created attachment 417876 [details]
/tmp/X.log of failed ATI driver

Display had no video but keyboard was working.  I switched to VT2 (still no video) and saved data to USB2.0 flash memory.

Created attachment 417877 [details]
/tmp/anaconda.log of failed ATI driver

Created attachment 417879 [details]
dmesg output from failed ATI driver

Created attachment 417880 [details]
/tmp/X.log of vesa driver

Option "Install with basic video driver" on the boot splash screen appends " xdriver=vesa nomodeset" to the kernel boot command line.  Graphic install begins successfully but anaconda crashes at custom disk paritioning (bug #596585).  This data was captured using VT2 while VT6 displayed the graphical install splash screen in vesa mode.

Created attachment 417881 [details]
/tmp/anaconda.log of vesa driver

Created attachment 417882 [details]
dmesg output from vesa driver

OK, so this is what I've found in the logs for the ATI driver.

==========================================================================
1) We have one userspace crash:

Backtrace:
[    55.454] 0: Xorg (xorg_backtrace+0x28) [0x49e6f8]
[    55.454] 1: Xorg (0x400000+0x603c9) [0x4603c9]
[    55.454] 2: /lib64/libc.so.6 (0x7f542dcb8000+0x339d0) [0x7f542dceb9d0]
[    55.454] 3: Xorg (0x400000+0xbf9bf) [0x4bf9bf]
[    55.455] 4: Xorg (TraverseTree+0x6c) [0x44eb7c]
[    55.455] 5: Xorg (RRDeleteAllOutputProperties+0xb8) [0x4bf988]
[    55.455] 6: Xorg (0x400000+0xbea9b) [0x4bea9b]
[    55.455] 7: Xorg (FreeClientResources+0xd3) [0x449083]
[    55.455] 8: Xorg (FreeAllResources+0x47) [0x449147]
[    55.455] 9: Xorg (0x400000+0x21a02) [0x421a02]
[    55.455] 10: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f542dcd6d2d]
[    55.455] 11: Xorg (0x400000+0x21579) [0x421579]
[    55.455] Segmentation fault at address (nil)
[    55.455] 
Fatal server error:
[    55.455] Caught signal 11 (Segmentation fault). Server aborting

===========================================================================
2) Another interesting stuff (but probably not related) is in dmesg:

===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
no locks held by watchdog/1/8.

stack backtrace:
Pid: 8, comm: watchdog/1 Not tainted 2.6.34-11.fc14.x86_64 #1
Call Trace:
 [<ffffffff8107bed6>] lockdep_rcu_dereference+0xaa/0xb3
 [<ffffffff8103ec3f>] task_subsys_state+0x4e/0x65
 [<ffffffff810488b4>] __sched_setscheduler+0x1a2/0x305
 [<ffffffff81480a45>] ? schedule+0x5eb/0x653
 [<ffffffff81483201>] ? _raw_spin_unlock_bh+0xc/0x39
 [<ffffffff810ac60f>] ? watchdog+0x0/0x91
 [<ffffffff81048a3c>] sched_setscheduler+0x13/0x15
 [<ffffffff810ac63e>] watchdog+0x2f/0x91
 [<ffffffff810ac60f>] ? watchdog+0x0/0x91
 [<ffffffff8106a8f4>] kthread+0x9a/0xa2
 [<ffffffff8107c820>] ? trace_hardirqs_on_caller+0x111/0x135
 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10
 [<ffffffff814835d0>] ? restore_args+0x0/0x30
 [<ffffffff8106a85a>] ? kthread+0x0/0xa2
 [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10

==========================================================================

3) This is another piece of dmesg, which I doubt is much related:

pcieport 0000:00:01.0: setting latency timer to 64
  alloc irq_desc for 24 on node -1
  alloc kstat_irqs on node -1
pcieport 0000:00:01.0: irq 24 for MSI/MSI-X
pcieport 0000:00:1c.0: setting latency timer to 64
  alloc irq_desc for 25 on node -1
  alloc kstat_irqs on node -1
pcieport 0000:00:1c.0: irq 25 for MSI/MSI-X
pcieport 0000:00:1c.2: setting latency timer to 64
  alloc irq_desc for 26 on node -1
  alloc kstat_irqs on node -1
pcieport 0000:00:1c.2: irq 26 for MSI/MSI-X
pcieport 0000:00:1c.5: setting latency timer to 64
  alloc irq_desc for 27 on node -1
  alloc kstat_irqs on node -1
pcieport 0000:00:1c.5: irq 27 for MSI/MSI-X
pcieport 0000:00:01.0: Requesting control of PCIe PME from ACPI BIOS
pcieport 0000:00:01.0: Failed to receive control of PCIe PME service: no _OSC support
pcie_pme: probe of 0000:00:01.0:pcie01 failed with error -13
pcieport 0000:00:1c.0: Requesting control of PCIe PME from ACPI BIOS
pcieport 0000:00:1c.0: Failed to receive control of PCIe PME service: no _OSC support
pcie_pme: probe of 0000:00:1c.0:pcie01 failed with error -13
pcieport 0000:00:1c.2: Requesting control of PCIe PME from ACPI BIOS
pcieport 0000:00:1c.2: Failed to receive control of PCIe PME service: no _OSC support
pcie_pme: probe of 0000:00:1c.2:pcie01 failed with error -13
pcieport 0000:00:1c.5: Requesting control of PCIe PME from ACPI BIOS
pcieport 0000:00:1c.5: Failed to receive control of PCIe PME service: no _OSC support
pcie_pme: probe of 0000:00:1c.5:pcie01 failed with error -13

Vesa logs contain both 2) and 3) of the ATI logs, but aside from that it seems to be working well in the graphics department.

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

Blocks F14Alpha because it relates to unmet Alpha Release Requirement #6: The installer must be able to complete an installation using the text, graphical and VNC installation interfaces.  In this case, a graphical install using an ATI card will crash [attempting to start the X11 server.]

Discussed at 2010/07/16 blocker meeting. That criterion is intended to cover the functionality of the installer itself - that is, it's considered broken if there's a bug such that _any_ attempt to do a graphical install would fail. A hardware-related X bug which incidentally makes it impossible to do a graphical install, because X won't run, isn't always considered a criteria breakage; it depends on the impact of the bug.

So far, we only know of one system suffering the bug (yours), and we don't usually consider single-system X bugs severe enough to block releases. So for now we don't accept this as a blocker. Please re-add it to the list for re-examination if we find more people affected by it, or the maintainer of the driver thinks it could affect many people.

Since you have problems doing an install even with vesa, and you had problems with a different graphics card, it seems like there's at least two other bug reports hiding in here somewhere; a bug in the radeon driver can't really affect the system when there's an NVIDIA card in it, or when you're trying to install using the vesa driver. Could you file those bugs separately? Thanks.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

https://bugzilla.redhat.com/show_bug.cgi?id=610076#c5 was a separate bug that noted no problem with [one] nVidia card, only with [one] ATI card.  Somebody on a triage team decided that bug 610076 was the same as this bug 596985.  The traceback is similar enough; but it is now 6 weeks later, and the version of X11 server is not the same, and there has been no response to either bug, other than "these two are duplicates."

I will try a different box that has a different ATI card.

Meanwhile, the problem with vesa install (bug 613817) was determined to be a disconnect between anaconda and yum, and therefore independent of X11.  Thus it is already separate.

I don't think this is ati bug, John do you see somethings on screen before the crash (graphical boot). If so i think it could be a bug related to your input system, what kind of mouse/keyboard/tablet ? Connected to the computer with USB/PS2/... ?

Oh it's in the log, i keep failing at seing that, so it's logitech + apple usb keyboard ? Can you try with a different keyboard ?

Comment 8 to bug 610076 shows the same traceback with a different ATI card, on a different box, with different input devices.

At boot (the very beginning, both machines) the display is in VGA text with 25 lines of 80 characters.  Some kernel log messages fly by on the display, which scrolls rapidly.  Then the display switches to "native character mode" which is something like 63 lines of 160 characters (1280x1024), more kernel messages appear, then the Media Check and Language Selection dialog boxes appear in Newt character-cell "graphics".  Then some anaconda messages appear, then the display starts to switch into full graphics mode: blinking underscore cursor at top left, black screen but raster still visible, "garbage" pixels on top 1/6 of display, black screen with no raster, finally the microcode in the hardware display detects "No input signal."

The second machine (comment 8 of bug 610076) has a Logitech PS/2 keyboard and a Logitech USB trackball.

The Apple keyboard with Logitech mouse works with nVidia 8400GS (a third box.)

Using a Logitech USB keyboard (and no mouse) fails with the ATI card.

Only the Media Check dialog appears in Newt character cell graphics.  The Language Selection dialog would be later, in graphical mode.  I mis-remembered in Comment 21, but noticed when running more tests.  Sorry for any confusion.

Created attachment 434831 [details]
/tmp/X.log; card 1002:5157:174b:7161; ATI Radeon 7500 QW

Boot DVD of rawhide for Fedora 14 for fresh graphical install fails on a third box with a third ATI card.  This one has PS/2 keyboard and PS/2 mouse.

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

The problem persists in Fedora 14 Alpha TC2 (Test Compose 2) DVD/CD of August 3.  All radeon cards will hang upon attempting the transition to graphical mode in order to display the anaconda graphical splash screen.  (Verified on 7500, HD 3600, HD 4550.)

does the radeon driver work in normal use once you complete installation using the workaround?

re-adding this for consideration as a blocker, if it truly prevents install by default on all radeon cards, that's a significant issue.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Choosing "Install with basic video driver" adds "nomodeset" to the kernel boot command line when booting the installer, and the installer dutifully propagates this into the GRUB stanza that gets installed for the new system.  Thus every boot of the newly-installed system will get "nomodeset" until the _user_ changes grub.conf.

I have Fedora 14 branched "pre-"installed on another partion in the box with the HD 4550 card.  I upgraded that box from Fedora 13 to rawhide as soon as Fedora 13 was released, and repeatedly "yum update" several times a week.  It uses the default radeon driver, and compiz Desktop Effects work properly (smooth alpha-blended window exposes, etc.)  So, yes, the radeon driver does work on the installed system once "nomodeset" is removed.

"Choosing "Install with basic video driver" adds "nomodeset" to the kernel boot
command line when booting the installer, and the installer dutifully propagates
this into the GRUB stanza that gets installed for the new system.  Thus every
boot of the newly-installed system will get "nomodeset" until the _user_
changes grub.conf."

Yes, this is intended. Usually, if the native driver won't work during installation, it won't work post-installation either, so we configure the system to use vesa post-install. ('nomodeset' is added because having KMS enabled can cause vesa not to work).

"I have Fedora 14 branched "pre-"installed on another partion in the box with
the HD 4550 card.  I upgraded that box from Fedora 13 to rawhide as soon as
Fedora 13 was released, and repeatedly "yum update" several times a week.  It
uses the default radeon driver, and compiz Desktop Effects work properly
(smooth alpha-blended window exposes, etc.)  So, yes, the radeon driver does
work on the installed system once "nomodeset" is removed."

Thanks. So this is an unusual issue which is somehow to do with anaconda as well as the video driver. Adding a few X and anaconda people to CC - guys, this is a high priority issue for the alpha, can you possibly help to figure out what's going wrong here?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Experienced the same thing with my ati card.  Black/blank screen when starting the gui.  But install will proceed when using basic video driver.  Then changing grub.conf and removing nomodeset lets me then use the radeon/ati driver as normal.

What are the next steps and plans for fixing this bug?  Can someone please provide more information?

If this is in fact a blocker we can't compose the Fedora 14 Alpha Release Candidate today unless it is fixed.

Several people have indeed confirmed multiple cards are affected.  I have a HD 4850 but haven't had a chance to try it.

So if I'm not mistaken, the question is, does the workaround constitute enough of a mitigating factor to allow the release to proceed (i.e. this is not a true blocker)?  If a few systems are affected, not all, and there's (1) a workaround, and (2) a very good chance we'll stomp the bug before Beta, I don't know that this is blocker-worthy.  Willing to be proven wrong.

Mike: can you get us some logs so we can confirm you're seeing the same thing as John?

so, we're talking about the blockeriness of this bug. it's definitely worrying, but so far we really only have input from two reporters and we're not entirely sure of the cause of this problem.

for now we'd like to hold it in 'undecided' status and push a compose today which will likely be RC1, which will be the first compose (hopefully) without major other bugs in it. that way we should hopefully be able to get some more feedback and find out if a lot of people hit this problem or if it's somehow quite specific to the two reporters we've seen so far. at that point we can make a final determination on its blocker status.

Being very explicit, here's how I got my logs:
1) The keyboard is working; you just get no visual feedback at all on the
screen, so type slowly and carefully.  <Backspace> or <Ctrl>h works for erasing
the last character; <Ctrl>u will erase the whole line that has been entered so
far.
2) Type <Ctrl><Alt><F2> to switch to virtual terminal 2 (VT2), which is running
a shell.
3) Plug in a USB2.0 flash memory device that has a vfat filesystem on partition
1.  The device's activity LED should flash as the new device is recognized.
4) mkdir /key
5) mount /dev/sdc1 /key   # where the 'c' of "sdc" is the next letter after
your fixed harddrives.  I had two drives sda and sdb, so sdc is the USB2.0
flash drive that I inserted in step 3.
6) cd /key; mkdir 0805   # make a unique directory so that it is easy to keep
stuff separate from other stuff (I use MMDD for month and day)
7) cp  /tmp/*  0805   # copy logs from /tmp to the new directory
8) sync  # be sure that everything makes it onto the USB2.0 drive

Then reboot (or just unplug the USB2.0 flash memory.)

(In reply to comment #35)
> so, we're talking about the blockeriness of this bug.

Is there *ANY* report of successful install using a Radeon card with _radeon_
driver, which is the default first choice on the very first splash screen?  Or do *ALL* of the other testers use nVidia cards *only*?

There is a workaround: use basic video driver to install, then after install
remove "nomodeset" from the GRUB boot stanza in /boot/grub/grub.conf [or where
ever it is].  But that workaround will be required by 25% of installers of
F14alpha, or whatever is the actual installed share of Radeon cards, which may
be the #2 most popular cards sold over the last few years.

Seems to work fine here (tested on R6XX) using :
http://serverbeach1.fedoraproject.org/pub/alt/stage/14.TC2/Fedora/i386/iso/

Are you using a different iso ? (beside x86-64) i can't test x86-64 right now
as i don't have any x86-64 cpu. Also the error on input device makes me think
that radeon is not at fault here, maybe something to do with usb...

Also works on HD4550 (up to the partition disk step in graphical boot with kms enabled, still i386)

john: the problem is that we just don't know; the candidates released so far have been so broken that few people have managed to do an install at all, so we just don't have the data. What we're hoping is the candidate we roll today *won't* be broken in any other big way, so more people will be able to do an install, and we'll get a better feel for the impact of the bug.

jerome's feedback suggests it's in *some* way hardware specific, at least. we just need more data.

(In reply to comment #38)
> http://serverbeach1.fedoraproject.org/pub/alt/stage/14.TC2/Fedora/i386/iso/

[Now] I use CD1 from there and the corresponding one for x86_64.  Burned to physical CD-R, checked both on the burning machine (dd | cmp) and via MediaCheck during install [the first check succeeded, so not checked after that.]

I have 3 boxes (two x86_64, one i686) with radeon cards (7500, HD 3600, HD 4550) and 3 boxes (all x86_64) with nVidia cards (8400GS, 9400GS, GT 220).  I have three keyboards (Apple USB, Logitech USB, Logitech PS/2) and three pointers (USB mouse via Apple keyboard, USB trackball direct, PS/2 mouse).  No matter which keyboard nor which mouse (swapping among boxes in many combinations, although not all 3x3x2 of them), all the radeon cards hang with traceback and all the nVidia cards succeed [at least past the anaconda graphical splash screen.]  The x86_64 systems all have ASUS motherboards 0.5 to 3 years old, assembled by me; the i686 box has a 9-year old ASUS mobo assembled by a local clone shop.

Created attachment 437176 [details]
/tmp/X.log

The problem persists with RC1 of F14 Alpha for i686 (http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Alpha.RC1/Fedora/i386/iso/Fedora-14-Alpha-i386-disc1.iso).  The x86_64 CD fails much earlier (bug 621775).

This is /tmp/X.log with the HD 4550 booting i686 CD1 on x86_64 hardware.

Created attachment 438217 [details]
/tmp/x.log

The problem persits in http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Alpha.RC3/Fedora/x86_64/iso/Fedora-14-Alpha-x86_64-disc1.iso

so, a wrinkle here. See https://bugzilla.redhat.com/show_bug.cgi?id=623129 . I believe the 'Basic video driver' option is not actually working correctly. It passes the xdriver=vesa parameter to tell anaconda to use vesa as the video driver, but this isn't working. It also passes 'nomodeset' to disable KMS (this is intended to avoid KMS modules loading and preventing vesa from working). For Intel and NVIDIA chipsets, this results in vesa being used, because the native drivers do not work with KMS turned off. radeon, however, still has UMS support - so when you select 'Basic video driver', you get radeon, but with UMS rather than KMS.

That may explain why people are having varying results with 'Basic video driver' - it's not actually using vesa, it's using radeon UMS, which may well work for some but not others.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

re-adding to F14Alpha for consideration for the go/no-go meeting. we're still very unclear on the exact breadth of the impact of this bug.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

The same thing seems to happen with VirtualBox (see bug 621893), should that be marked as a duplicate of this?

Discussed at the go/no-go meeting today. The Alpha release is slipping for a different bug. We are still not sure as to whether this one should block the release. We plan to try and find more radeon-equipped testers and re-assess at a blocker meeting on Friday. Leaving on the F14Alpha list for now.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

andre: unless the X log looks extremely like what's in this bug, no. VirtualBox uses a different graphics driver. Note that 'Basic Video Driver' likely isn't working for you with VBox in RC3 because of https://bugzilla.redhat.com/show_bug.cgi?id=623129 ; that should be fixed for RC4.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I am not sure, but perhaps bug 604931. Starting with 2.6.34 kernels, I haven't been able to use KMS with my rv280 based card. UMS gets things to work for a while.

Ok, so i found a reproducer, i only see this bug with :

RV370 or RV515 PCIE + apple display (other screen i have works fine) John can you try a different monitor ? Are you using a KVM ? if so which one ? (please gives full ref of monitor) thanks

John could you also test with the affected monitor to boot in rescue mode (from dvd/cd) with kms activated add sshd, skip step about automatic repair and go to shell, once in shell you should be able to log in remotely from another computer
(ssh root@ipofbrokencomputer no password) and from the remote computer launch anaconda (here it works)

but if anaconda is launch from the dvd shell it bugs the same way.

Using the F14 Alpha RC3 I get the blank screen with x86_64 using RV710 and RV620. With the i386 version on RV350 I get the correct graphical install screens.
I tried the RV710 machine with a Philips LCD and a Dell CRT and had the problem with both monitors.
Choosing the basic graphics driver option worked for both the RV710 and RV620.
Trying the i386 version on the RV710 also gave the same blank screen problem.

Created attachment 438608 [details]
/tmp/*.logs on VT2 after the screen turned to black

I booted F14-alpha-rc4 with normal install(ATI Technologies Inc RV620 LE [Radeon HD 3450], KMS), as previous releases, the screen turned to totally black without displaying graphical anaconda, but the keyboard worked fine. The attached was the /tmp/*.logs saved on VT2.

As expected, if I use vesa driver(xdriver=vesa) or UMS(nomodeset), the graphical anaconda is displayed successfully.

Hardware Profile:
http://www.smolts.org/client/show/pub_fc189b8a-d0db-4ad0-bda4-d912e207ad96

(In reply to comment #53)
> Created an attachment (id=438608) [details]
> /tmp/*.logs on VT2 after the screen turned to black
> 
> I booted F14-alpha-rc4 with normal install(ATI Technologies Inc RV620 LE
> [Radeon HD 3450], KMS), as previous releases, 

s/releases/F14 Alpha builds

Created attachment 438635 [details]
logs when install with basic video driver

Created attachment 438636 [details]
Logs after install with basic video driver

Created attachment 438688 [details]
/tmp/X.log

Still fails: F14-Alpha-RC4 on x86_64, using CD1.iso.  Attached is X.log from ATI Radeon HD 4550 (RV710/730) using Planar PL1700 17-inch LCD monitor via VGA Dsub-15 connector.  The full EDID info for the monitor is in X.log, what else do you need?  I believe it is running 1280x1024@60Hz.

All of my tests for this bug are run using physical CD-R or DVD+RW media on "bare metal" hardware (no virtualization, no emulation.)

(In reply to comment #51)
> John could you also test with the affected monitor to boot in rescue mode (from
> dvd/cd) with kms activated add sshd, skip step about automatic repair and go to
> shell, once in shell you should be able to log in remotely from another
> computer
> (ssh root@ipofbrokencomputer no password) and from the remote computer launch
> anaconda (here it works)
> 
> but if anaconda is launch from the dvd shell it bugs the same way.    

I'm unsure how to follow those directions.
On a box which otherwise reproduces the hang at start of X11 during install:
1. Boot, use <DownArrow> enough times to highlight the line for Rescue mode, then type <Enter>.  That works.  I choose English language and US-English keyboard, and ask for a Shell.
2. What does it mean "with kms activated"?  
3. What does it mean "add sshd"?  If I type "sshd" to the shell then it complains because no absolute pathname.  If I type "/bin/sshd" then it complains because no /etc/ssh/sshd_config.

Created attachment 438693 [details]
/tmp/X.log

Fails on F14-Alpha-RC4 x86_64, ATI Radeon HD 4550 RV710/730, ViewSonic VX500 15-inch LCD monitor using DVI connector, 1024x768@60Hz.  Full EDID info is in this X.log.

Conspicuously absent is any comment from an X11 maintainer.  Does this mean that Fedora cannot debug SIGSEGV in Xserver?  Does Xserver run under valgrind(memcheck)?

Alpha RC4 i686 - 01:00.0 VGA compatible controller: ATI Technologies Inc RV730XT [Radeon HD 4670] (01:00.0 0300: 1002:9490)

Black screen, unresponsive...

Created attachment 438712 [details]
/tmp/X.log

Fails: F14-Alpha-RC4 CD1 on x86_64, ATI Radeon HD 3600 RV635 card, Samsung SyncMaster 730B 17-inch LCD monitor, DVI interface, 1280x768@60Hz.  Complete EDID info is in this X.log.

I have now reproduced this problem on three different monitors (Planar, ViewSonic, Samsung), three different Radeon video cards (7500, HD3600, HD4550), two different electrical interfaces (Dsub15 analog, DVI digital), three different keyboards (Apple USB, Logitech USB, Logitech PS/2), three different mice (USB trackball via hub in Apple keyboard, USB direct, PS/2 direct), two different architectures (i686 and x86_64), and in many combinations of CPU+card+monitor+interface+keyboard+mouse (all that have been tried: at least 10 in total.)  When are the Fedora X11 experts going to fix the *code*?

reiser: "Conspicuously absent is any comment from an X11 maintainer."

Um, no it isn't. Jerome Glisse is one of the two maintainers of the driver for Fedora, along with Dave Airlie.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

"I'm unsure how to follow those directions.
On a box which otherwise reproduces the hang at start of X11 during install:
1. Boot, use <DownArrow> enough times to highlight the line for Rescue mode,
then type <Enter>.  That works.  I choose English language and US-English
keyboard, and ask for a Shell.
2. What does it mean "with kms activated"?  
3. What does it mean "add sshd"?  If I type "sshd" to the shell then it
complains because no absolute pathname.  If I type "/bin/sshd" then it
complains because no /etc/ssh/sshd_config."

Select rescue mode, hit tab, add 'sshd' to the parameters. 'With KMS activated' just means don't pass 'nomodeset'. Adding 'sshd' on the kernel command line will cause sshd to be loaded as part of the rescue session and let you log in from another system as Jerome describes.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #64)
> Select rescue mode, hit tab, add 'sshd' to the parameters. 'With KMS activated'
> just means don't pass 'nomodeset'. Adding 'sshd' on the kernel command line
> will cause sshd to be loaded as part of the rescue session and let you log in
> from another system as Jerome describes.

OK, result is successful X11 splash screen.  Specifically: adding " sshd" to the end of the kernel boot command line for Rescue mode (and with no other changes to kernel boot command line), Skip search for installed systems to rescue, go directly to shell.  Then use another system to login via ssh to the box-under-test, and run "anaconda" in the shell under ssh.  The graphical splash screen appears on the box-under-test, and clicking Next proceeds with install.  This is the RV710/730 HD4550 card, Planar PL1700 17" LCD monitor at 1280x1024@60Hz, Apple USB keyboard, Logitech USB mouse via hub in Apple keyboard.

Will attach /tmp/X.log.

Created attachment 438726 [details]
/tmp/X.log

Successful anaconda graphical splash screen when booting Rescue mode with sshd, then logging in via ssh and starting "anaconda" in shell.

Created attachment 438748 [details]
Xorg log from failed attempt with RC4

xorg-x11-server-1.8.99.906-2.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.8.99.906-2.fc14

Can all those affected by this bug please test with the following boot.iso:

http://adamwill.fedorapeople.org/boot.iso

and report whether it works? As fast as possible would really help, we're getting tight on time for the Alpha again. Thanks!

(In reply to comment #69)
> Can all those affected by this bug please test with the following boot.iso:
> 
> http://adamwill.fedorapeople.org/boot.iso
> 
> and report whether it works? As fast as possible would really help, we're
> getting tight on time for the Alpha again. Thanks!

Works nicely on my workstation (ATI Technologies Inc RV620 LE [Radeon HD 3450]) which had to disable kms on previous Alpha builds.

On my Sony VGN-FW21E laptop (ATI Technologies Inc Mobility Radeon HD 3400 Series; ChipID in Xorg.0.log is 0x95c4) I get the same backtrace as John has in comment 43, attachment 438217 [details] on the x86_64 RC4.

Basic video driver option starts graphical install nicely. Will test the iso from comment 69 tonight.

Rgw (In reply to comment #69)
> Can all those affected by this bug please test with the following boot.iso:
> 
> http://adamwill.fedorapeople.org/boot.iso
> 
> and report whether it works? As fast as possible would really help, we're
> getting tight on time for the Alpha again. Thanks!

W00t! The image boots fine on an Acer TM6465WLMi laptop with X1300 without any changes (other than adding tpm_tis.interrupts=0). Great work!

Created attachment 438947 [details]
Anaconda log of boot.iso from comment 69

Created attachment 438948 [details]
X log of boot.iso from comment 69 (HD5970)

Results of testing the boot.iso from comment 69 on a box with a Gigabyte X58, Intel i7, 6GB mem and a ATI Radeon HD5970:

1) default boot (no changes): black screen, keyboard active. Logs attached called hd5970-X.log and hd5970-anaconda.log

2) default boot with nomodeset added: black screen

3) default boot with xdriver=vesa added: gets to the initial install screen fine

4) boot with basic video driver: gets to the initial install screen fine

Please let me know if you need more information or if I can test anything else.

Results of testing the boot.iso from comment 69 on a box with a Gigabyte X58,
Intel i7, 6GB mem and a ATI Radeon HD5970 via rescue mode with sshd appended: black screen. 

Logs attached called hd5970-start-anaconda-command-line.log, hd5970-anaconda-via-sshd.log and hd5970-X-via-sshd.log

Created attachment 438954 [details]
hd5970-start-anaconda-command-line.log

Created attachment 438955 [details]
hd5970-anaconda-via-sshd.log

Created attachment 438956 [details]
hd5970-X-via-sshd.log

(In reply to comment #69)
> Can all those affected by this bug please test with the following boot.iso:
> 
> http://adamwill.fedorapeople.org/boot.iso
> 
> and report whether it works? As fast as possible would really help, we're
> getting tight on time for the Alpha again. Thanks!

It works for me on all three ATI radeon cards (7500, HD 3600, HD 4550).  Booting the first choice from the GRUB splash screen (Install or upgrade system ...) transitions successfully to X11 graphics and displays the anaconda graphical splash screen, and installing continues to the next screens with appropriate input (<Space> or Next, etc.)  Thank you.

(In reply to comment #69)
> Can all those affected by this bug please test with the following boot.iso:
> 
> http://adamwill.fedorapeople.org/boot.iso
> 
> and report whether it works? As fast as possible would really help, we're
> getting tight on time for the Alpha again. Thanks!

Default install option:
RV710 Radeon HD 4350 - pass
RV620 Mobility Radeon HD 3400 - pass
RV350 AP Radeon 9600 - pass

Basic video driver option:
RV710 Radeon HD 4350 - pass
RV620 Mobility Radeon HD 3400 - pass
RV350 AP Radeon 9600 - fail - Does not display anaconda screen, has a black screen, monitor not in powersave mode, keyboard inoperative.

(With the old boot.iso version RC3 the RV350 system gives a message that X failed to start and offers a VNC or Text installation instead, the initial few screens of the text version display correctly)

Patrick: your X log from your 'still broken' system doesn't have the classic backtrace we're used to seeing here, so it seems like a different bug. Does that system work okay with a live image?

xorg-x11-server-1.8.99.906-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-server'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/xorg-x11-server-1.8.99.906-2.fc14

Fixes it on "01:00.0 VGA compatible controller: ATI Technologies Inc RV730XT [Radeon HD 4670]" for me...

Given that this affects only a subset of radeon hardware, and has a workaround, I'm a little leery of holding/slipping the alpha for this as a true alpha blocker.

(In reply to comment #82)
> Patrick: your X log from your 'still broken' system doesn't have the classic
> backtrace we're used to seeing here, so it seems like a different bug. Does
> that system work okay with a live image?

On the box with the ATI Radeon HD5970 the RC4 x86_64 Live image boots fine into the Desktop.

After just testing Alpha RC4 x86_64 install DVD and the boot.iso from comment 69 I can to report that sadly both show the same behaviour on my system with a HD 5850 card: black screen, keyboard/sshd working. Killing anaconda (and therefore the defunct Xorg) and starting Xorg over ssh resulted in the same again (due to another yet-to-be-reported non-blocking bug I see the difference of a defunct Xorg and no Xorg running on the display).

Created attachment 438996 [details]
X.log for comment 87 with HD 5850

Created attachment 438997 [details]
anaconda.log for comment 87 with HD 5850

btw. when I start Xorg after killing anaconda as described in comment 87 I only get this as output (leaving away the common header stuff):
(II) [KMS] Kernel modesetting enabled.
[dix] Could not init font path element catalogue:/etc/X11/fontpath.d, removing from list!
(EE) A4Tech USB Full Speed: failed to initialize for relative axes.

When I then ctrl-c (either after 1 second or after a few minutes) I get this - not sure if it says anything useful or just what one would expect on ctrl-c:

Xorg: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed.

I'm starting to suspect we have a distinct issue that's affecting Radeon 5xxx cards here, we should probably open a new bug for that to avoid confusion. Does 'basic video driver' with RC4 work on these cards?

'Basic video driver' with RC4 works for me (HD 5850).

(In reply to comment #91)
> I'm starting to suspect we have a distinct issue that's affecting Radeon 5xxx
> cards here, we should probably open a new bug for that to avoid confusion. Does
> 'basic video driver' with RC4 work on these cards?

Yes assuming the boot.iso from Comment 69 is RC4. See my Comment 75 under item 4.

OK, cool. Jerome confirms Radeon 5xxx which don't work even with boot.iso from comment #69 are a different issue, please file a new bug and let me know the bug number, with logs. Thanks!

After extensive discussion today based on further information gleaned from the X developers we decided this bug doesn't quite qualify as an Alpha blocker. Release engineering, development (represented by ajax) and QA all voted against the bug being a blocker.

Our thinking was that, at a guesstimate, this will affect somewhere in the region of 20% of Alpha installations - possibly fewer, if use of the Live images is very popular. There is a relatively easy-to-apply workaround available which we have enough time to ensure is very prominently documented. Given that the release is an Alpha, we felt this impact was not sufficient to consider it a blocker issue.

Just to recap, the workaround for this issue is to install with the 'basic graphics driver' option, and then post-install to remove the xorg.conf file and grub.conf snippet which disable KMS and enable the vesa driver, to return to normal usage of the radeon driver. It is then advised that you update to the latest xorg-x11-server package - which will be in updates-testing and likely stable soon - which contains a fix for the underlying cause of this bug, which you could at least theoretically encounter outside of anaconda.

Putting this on the Beta list in case we have to discuss whether it's a Beta blocker, but that's highly unlikely as the fix should go stable soon.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

xorg-x11-server-1.8.99.906-2.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

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