Bug 462420 - nomodeset seems to cause a hang after starting udev
nomodeset seems to cause a hang after starting udev
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-09-15 23:35 EDT by Bruno Wolff III
Modified: 2018-04-11 12:26 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-17 17:15:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg.0.log without an xorg.conf file. (33.53 KB, text/plain)
2008-09-17 09:29 EDT, Bruno Wolff III
no flags Details
Xorg.0.log from boot with an xorg.conf file (31.66 KB, application/octet-stream)
2008-09-17 09:30 EDT, Bruno Wolff III
no flags Details
xorg.conf file (1000 bytes, text/plain)
2008-09-17 09:32 EDT, Bruno Wolff III
no flags Details
lspci -vvv output (12.28 KB, text/plain)
2008-09-17 09:39 EDT, Bruno Wolff III
no flags Details

  None (edit)
Description Bruno Wolff III 2008-09-15 23:35:03 EDT
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.
Actual results:
Hang right after udev is started.

Expected results:
Successful boot.

Additional info:
Comment 1 Matěj Cepl 2008-09-16 10:57:24 EDT
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.
Comment 2 Bruno Wolff III 2008-09-17 09:29:01 EDT
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).
Comment 3 Bruno Wolff III 2008-09-17 09:30:47 EDT
Created attachment 316955 [details]
Xorg.0.log from boot with an xorg.conf file
Comment 4 Bruno Wolff III 2008-09-17 09:32:19 EDT
Created attachment 316956 [details]
xorg.conf file
Comment 5 Bruno Wolff III 2008-09-17 09:39:42 EDT
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.
Comment 6 Bruno Wolff III 2008-09-19 12:43:49 EDT
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.
Comment 7 Bruno Wolff III 2008-09-20 11:05:41 EDT
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.
Comment 8 Bruno Wolff III 2008-10-01 10:15:19 EDT
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.
Comment 9 Bruno Wolff III 2008-10-07 02:06:05 EDT
I am still seeing this with kernel-2.6.27-0.393.rc8.git7.fc10.i686.
Comment 10 Bruno Wolff III 2008-10-08 00:28:03 EDT
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.
Comment 11 Bruno Wolff III 2008-10-13 14:08:07 EDT
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.
Comment 12 Bruno Wolff III 2008-10-20 23:13:41 EDT
I am still seeing the hang with xorg-x11-drv-ati-6.9.0-28.fc10.i386, kernel- and mesa-dri-drivers-7.2-0.12.fc10.i386.
Comment 13 Bruno Wolff III 2008-10-22 13:01:58 EDT
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?
Comment 14 Bruno Wolff III 2008-10-30 05:00:37 EDT
This is still happening with:
Comment 15 Bruno Wolff III 2008-11-08 11:51:32 EST
I tried this again with kernel- 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.
Comment 16 Scott Dodson 2008-11-17 15:50:24 EST

This no longer happens for me. 


Can you confirm that it no longer happens on your machine as well?
Comment 17 Bruno Wolff III 2008-11-17 17:15:10 EST
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.

Note You need to log in before you can comment on or make changes to this bug.