Description of problem: I tried using the nomodeset parameter for kernel-2.6.27-0.327.rc6.git2.fc10.i686 because X crashes fairly regularly at start up. (Once I get it fully started it seems to work OK.) I was hoping this would help things, but I had 2 hangs after the starting udev prompt (before any OKs) in two attempts. I am using a radeon 9200 agp card. I am using a rebuilt xorg-x11-drv-ati-6.9.0-14.fc10.i386 with a one line change to make it work with my old LCD display. I figure this negates any complaints about crashes, but I wasn't sure if this would have any effect on hangs before X is started when nomodeset is used. Version-Release number of selected component (if applicable): How reproducible: 2 out of 2. Does not happen when I don't use nomodeset. Steps to Reproduce: 1. Reboot using the nomodeset parameter. 2. 3. Actual results: Hang right after udev is started. Expected results: Successful boot. Additional info:
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) 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 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.
Created attachment 316954 [details] Xorg.0.log without an xorg.conf file. I tried getting an Xorg.0.log from the hanging (nomodeset) boot, but things apparently didn't get far enough long to leave one at the next boot. I do have logs from with and without an xorg.conf file booting without the nomodeset parameter. I also tested using nomodeset on the *329* kernel and saw the same hang problem. (I didn't see a start up crash of X, but those are intermittant and I didn't do a lot of tests.) Also the one line change I made to the driver was to force my monitor to be recognized as a MT_DFP instead of MT_NONE, otherwise the video output does not go to the correct port (which is another bugzilla report).
Created attachment 316955 [details] Xorg.0.log from boot with an xorg.conf file
Created attachment 316956 [details] xorg.conf file
Created attachment 316958 [details] lspci -vvv output Since this bug might really be a kernel or udev bug I should probably include a some more hardware info and note that I am currently using udev-127-1.fc10.i386. There are two AMD Athlon(tm) MP 2400+ cpus and I have attached lspci -vvv output.
I retested this with the *332* kernel and saw the same problem. I'll be able to try the *336* (or later if available) kernel tonight.
I tested this with the 337 kernel and had the same results. I also want to note that the hang isn't total. While it never prints out any messages about starting services and does not appear to finish the boot process, hitting enter while waiting adds a blank line to the screen and forces a scroll up.
I retested this with kernel-2.6.27-0.372.rc8.fc10.i686 and xorg-x11-drv-ati-6.9.0-20.fc10.i386 (modified to force MT_DFP) and saw the same issue.
I am still seeing this with kernel-2.6.27-0.393.rc8.git7.fc10.i686.
I retested this tonight waiting at the udev step for several minutes. It eventually timed out and the boot continued until the point at which X would normally start and then the system was effectively locked up.
I am still seeing this with xorg-x11-drv-ati-6.9.0-26.fc10.i386, mesa-dri-drivers-7.2-0.8.fc10.i386 and kernel-2.6.27-3.fc10.i686. With the recent MAKEDEV bug I'll note the hang is after the errors displayed by that bug.
I am still seeing the hang with xorg-x11-drv-ati-6.9.0-28.fc10.i386, kernel-2.6.27.3-30.rc1.fc10.i686 and mesa-dri-drivers-7.2-0.12.fc10.i386.
I noticed that this got turned into a blocker. I hadn't been worrying about this one too much (though I have been retesting pretty much daily) because it didn't really affect me much as booting without nomodeset works fine on that machine. However if it's a blocker that raises its importance somewhat. Is there something I can do get more information about the cause?
This is still happening with: kernel-2.6.27.4-65.fc10.i686 xorg-x11-drv-ati-6.9.0-36.fc10.i386
I tried this again with kernel-2.6.27.5-88.fc10.i686 and xorg-x11-drv-ati-6.9.0-42.fc10.i386 and am still seeing a hang after starting udev. After a couple of minutes udev times out and continues the boot process. That continues normally until where X and gdm would be started at which point the monitor loses signal. I was unable to get a vt. I didn't have an easy way to use a network connection to see if the system was live or not.
Bruno, This no longer happens for me. kernel-2.6.27.5-109.fc10.i686 udev-127-3.fc10.i386 xorg-x11-drv-ati-6.9.0-45.fc10.i386 Can you confirm that it no longer happens on your machine as well?
Sorry about not retesting this over the weekend. (I saw there was a new udev and a comment about nomodeset in the kernel changelog, so I should have retested.) Any way I am not seeing the problem now. (For the record I am using the -46 ati driver rather than the -45 version.) I think this is safe to close now and will do so.