Description of problem: Fedora install hangs on Automatic Login screen. The screen shows highlighted "Automatic Login" plus bubble saying "Automatically login to the sytem after selecting options". Above that two lines of text are superimposed. Below are two buttons "Cancel" and "Login" neither of which espond to the mouse. Bottm bar is "Language" with no seletion and "Keyboard" with USA. Mouse moves okay. Version-Release number of selected component (if applicable): 10 How reproducible: Boot from install disk Steps to Reproduce: 1. Boot from install disk 2. 3. Actual results: hangs Expected results: installed v10 Additional info:
I see this also (Dell Dimension 8400)
Can you switch ttys when this occurs?
I can't switch ttys. There is no keyboard response. ctrl-alt-del doesn't work either and I have to hard-power down. The mouse responds to movement but not to mouse clicks. Current working version of Linux is FC 8. Video card is Intel 82845G. Booting FC8, /var/log/messages reports "CPU0: Intel P4/Xeon Extended MCE MSRs (12) available". uname -a reports "i686".
I had the same behavior - could not switch to ttys, ctrl-alt-del didn't work, ctrl-alt-backspace didn't work either. Same with the mouse. I am currently running FC9 uname -r reports 2.6.27.9-73.fc9.i686
GDM doesn't do anything to stop vt switches, must be a problem lower in the stack... What kind of video cards do you have? Radeon?
I have the generic Intel one - from lspci: VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
Same here: VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
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. Could you please also try to run without any /etc/X11/xorg.conf (if you have one) whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
to clarify - do you mean from my current distro of FC9? Or during some pre-boot stage of the FC10 live image?
Created attachment 329270 [details] startx X server log with no xorg.conf
Created attachment 329271 [details] start X server log with the given xorg.conf
Created attachment 329272 [details] xorg.conf file used when Xorg.1.log was produced
I have an HP Pavillion 503n with the same video chipset. If I boot this machine from the Live CD I get the same behavior as stated above. I have had very similar problems with a fully installed F10. The machine boots to run level three, I ssh into it and run "startx". Regardless of whether I have a xorg.conf or not, I get a crosshatch, then garbage, then a very odd pattern with no keyboard response (not even Num Lock) or mouse (or mouse cursor). In the attachments I have provided, the Xorg.0.log was when I had no xorg.conf, and the Xorg.1.log was when I had the provided xorg.conf. Also, lspci | grep VGA gives: 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) Hope that helps -- I'm suffering!
Sorry, I just wanted to add that this particular machine (the HP Pav 503n with the Intel 82845G/GL/GE) worked just fine with the X and driver in FC9.
I have an Fujitsu-Siemens ScenicS2 with the same video chipset. If I boot this machine from the Fedora10 LiveCD I get the same behavior as stated above. The same behavior I get from Fedora 11 Alpha LiveCD. I tested the LiveCD's also on an IBM NetVista 8313 and a Compaq Evo D510 with the same results. The error seems to be related to the acceleration method used in the xorg-x11-i810 driver (the default now is EXA before was XAA). In Fedora 10 there is a workaround: by generating an xorg.conf and changing the accel method to xaa the driver works. However in Fedora 11 Alpha this workaround does not work.
Created attachment 337867 [details] Xorg.0.log with Fedora11 Beta LiveCD on i845 video The Fedora11 Beta Live CD does not work as expected on my hardware (Fujitsu-Siemens ScenicS2 with i845 integrated video ): boots, almost everything works exept no mouse cursor. It detects motion, but the cursor is invisible.I can guess where the cursor is and click in windows.This is the same behaviour as with the 2009-03-12 intel Test Days Live CD. I attached the Xorg.0.log for this case. Adding "nomodeset" to the boot command line resulted in a running Xserver with mouse cursor. Everithing looks normal, but the graphical interface is a bit slower then expected. My computer works fine with Fedora8 and Fedora9, the above stated behaviour appeared since Fedora10.
Try to boot this machine in runlevel 3 by editing the default runlevel in /etc/inittab file. Then connect to the machine from another machine in the network. with -X option of ssh eg. $ssh -X ip.add.re.ss then run the follwing command if your computer is connected to the Internet. $yum install system-config-display $system-config-display change the screen resolution and the VGA card driver to vesa and then try to boot the machine in runlevel 5. This may work for you. Anoop
*** Bug 474165 has been marked as a duplicate of this bug. ***
*** Bug 473427 has been marked as a duplicate of this bug. ***
With current rawhide, it should work better. KMS shouldn't hang at least. Can you retry?
*** Bug 477323 has been marked as a duplicate of this bug. ***
Reporter doesn't reply. Closing since we don't have sufficent data to debug this further. It's likely that it was fixed along with many changes in current intel driver.
same for f12.
UMS mode hung with black screen, KMS hungs with alive mouse.
OK, let's reopen it then.
-56 kernel works better (fedora beta), -96 less better (gliches on screen), and last kernel -127 hangs.
Created attachment 399362 [details] f13-intel-dmesg
Created attachment 399363 [details] f13-intel-Xorg
Created attachment 399364 [details] f13-intel-messages
f13 the same.
Alexey, I am suspicious, that you have different issue (actually duplicate of bug 573462) than what's going here -- your logs seem very different. Could you please move over there?
yes, sorry. i choose wrong bug report to attach files. miss read the bug subject.
(In reply to comment #9) > to clarify - do you mean from my current distro of FC9? Or during some > pre-boot stage of the FC10 live image? Sorry, I meant of course from the machine where the issue is reproducible. There are some ways we can try to get logs even from less than perfectly responding machine: 1) you can try to start in a text mode by adding 3 to the end of the kernel command line, and then you can login in the text mode as either root or liveuser, both of which should have no password 2) if you have some other computer with which you can connect to the tested one, login as root, and run /sbin/service sshd restart 3) if you don't have other computer, then we have to just try our luck, and so in either case login liveuser and run startx 4) then it depends on the results. If Xorg crashes and you get back to the text mode, please collect and attach * your X server config file (/etc/X11/xorg.conf, there shouldn't be any, just in case), * output of the dmesg command after the crash, * system log (/var/log/messages), and * X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. 5) if you don't have text mode and you can connect to the computer via ssh, you can collect the information through ssh. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
http://bugs.freedesktop.org/show_bug.cgi?id=27187 gtt chipset flush v6 against kernel-2.6.34-rc3 (git) solve my issue! please apply against fedora build!
(In reply to comment #34) > http://bugs.freedesktop.org/show_bug.cgi?id=27187 > > gtt chipset flush v6 against kernel-2.6.34-rc3 (git) solve my issue! please > apply against fedora build! And we are talking about this bug or about bug 573462 again?
can be :( what i found, nvidia opensource drivers has same issue. i think that is much deeper problem then just ati related bug.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
I no longer have that system. Sorry, can't test any more.
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.