Arch Linux

I can confirm this after recompiling a new kernel (2.6.31.4-1) with Radeon KMS enabled as well as upgrading to xorg-server 1.7.0.901-1 from testing.

The boot process stops at "Starting UDEV Daemon [Busy]"

Selecting a separate kernel (possibly without KMS enabled) boots with no problem.

Card: Radeon 9600 (RV350)

Kernel log attached (call trace)

@KitchM: if you boot without vga parameter?

What vga parameter?

You boot your system in 80x25 textmode or in some VESA mode? What is the exact kernel command line? Try nomodeset with/out combination with vga= parameter. Maybe this help. I don't know KMS.

What vga parameter?

My GRUB default line contains the following:
root (hd0,0)
kernel/vmlinuz26 root=/dev/disk/by-uuid/c882892e-14d0-495b-a9cb-66ad1a678f5f ro
initrd /kernel26.img

Pretty standard stuff.

have you tested adding intel_apg before radeon module in rc.conf? all wiki hints don't work? is the non-kms mode also broken?

I can't get to a CLI.

fix it.

Fix what?

He's suggesting you use a livecd or something of the sort to boot the system, and adjust the rc.conf. Or use 'e' in grub to adjust the KMS settings as per the wiki

Oh, I see.

I tried the grub editing (which I wrote about in the wiki), but the options given in the news item's wiki link do not seem to work. If there was something to try to get it to work as it did the first time, I would like to put that in. I did try the nomodeset, but got nothing.

I wonder why the radeon.modeset=0 worked once, but not again. Isn't that significant to you programmers?

If I understand correctly, the alternative is to boot from the ISO cd, try to mount the file system found on the hard drive, start nano with the rc.conf file and add something. The referenced intel_apg doesn't seem right to me with my ATI Radeon-based card.

I will try to see what I can do, but programming is not my area of expertise.

Hmmm, odds are if it worked once, than it actually didn't do anything, but something ELSE caused it to succeed. It could be chance.

It might be possible to set disablemodules=radeon (or whatever the actual module is named) on the grub line. It should boot, but won't give you X, I imagine.

Hmm, when do these "red lines" appear? Before X, or after?

Thanks, Aaron.

I tried disablemodules=radeon as you suggested. I did get a different pattern of garbage on the screen, but nothing else.

Just for fun I listened for the hard drive to stop accessing, typed in root, Enter, and then the password, Enter. Then I tried startx but got no change of screen. I heard disk access for the amount of time I would expect it to take to get to the DE. Then I had to do Ctrl-Alt-Del to reboot. Everything sounds like it is working, but I can't see anything until I reboot. There is no doubt that something in the upgrade (most likely KMS) caused the video problem.

More later. (I've got to find that darn DVD. Now where did I put it.......)

As was mentioned, the red lines appear right after the screen shows the part about UDEV starting up. At that point one does not know if it is occurring during the UDEV process or just after it. IMHO, there is no way that X would have started yet.

BTW, found the DVD; now I've just got to figure out how to mount my hard drive so as to be able to edit the files on it. (Damn man page......)

when udev causes your system fail please check your modules section in rc.conf! maybe you left a framebuffer there or another gfx card module. It really sounds like a configuration issue not a general kernel/kms bug.

Still trying to figure how to mount my hard drive partitions. As soon as I figure that out, I'll be glad to try your suggestions.

I just wish the darn thing worked the first time. The lost productivity is adding up. I guess I don't understand why it was necessary to screw around with an ATI setup that was working. There is an implied trust that is broken when an automatic "upgrade" that is performed causes a working system to become unusable. (Once I get this figured out, I'll be very interested in finding the individual responsible for this royal f**k-up. He and I will have a little talk.)

Hello,

I ran into the same problem trying to install Archlinux for the first time on my old PC.

Booting on the netinstall CD --> no problem
Archlinux installation --> no problem
First boot --> Black screen a few seconds after UDEV loading

I rebooted countless times in the install cd, mounting my root partition, editing /etc/rc.sysinit, and echoing some stuff..
Finaly, adding a big "sleep 30" after the udev section makes my system to hang before displaying other things, so the problem effectively seems to come from udev loading.

And I found this bug, and adding "radeon.modeset=0" to the kernel boot command line fixes my problem.

My ATI card from lspci : Radeon R350 (Radeon 9800 Pro)

Is there any thing/trace I can give to you to help you fix the problem ?

Marc

Thanks. But since I don't know what is wrong, I don't know what to ask for. I know that there are many slammed by this problem. The good news is that I was finally able to mount the necessary hard drive partition under the install CD. The video card's processor is identified as Radeon R100 QD (Radeon 7200).

The important parts of rc.conf:
MOD_AUTOLOAD="yes"
MODULES=(fuse)
USELVM="no"
DAEMONS=(syslog-ng network netfs @crond alsa @openntpd hal avahi-daemon avahi-dnsconfd dhcpcd webmin !stbd samba)

More later.

There is no framebuffer in use.
Nothing in mkinitcpio.conf either.
There appears to be no way to get a non-KMS mode as an alternative. So, yes, that must also be broken.

If you have any other requests for information, I can get to it now; so let me know.

In the news item I read this:
"Experimental kernel modesetting (KMS) for the radeon driver is now enabled."

I found this in the wiki:
"Note: For now, only Radeons up to R5xx (X1xxx) support KMS. Support for later Radeon cards will be added in Linux kernel 2.6.32."
(I'm beginning to think that isn't correct.)

IMHO, someone put an experimental function into the normal upgrade process. Experimental stuff is supposed to go into the [testing] repo, so that we can avoid it automatically. Further, this appears to <u>not</u> be tested on all ATI cards. Knowing that there are enough problems with the many permutations of ATI and nVidia cards, these things should always be optional at the very least. At the best, coders should put into the upgrade process a chipset identification routine, and a user choice of questionable "features" before compilation of the new kernel.

Does anyone know how to compile the old kernel from an install CD?

I think I experienec the same issue on a machine. Why does arch release this kernel without the X-Components being ready? I think kms should be disabled as default for now. (Even though I got kms working with radeon, standby and suspend are broken, and there are some speed issues)

I just wish it would work at all.

Why can't you just disable kms mode as recommended in the news? Once kms is disabled your card should behave like before. KMS is just an addtional feature we have enabled now by default. If it doesn't work for you simply disable it.

As I stated before, it didn't work but once. Never again. As I also mentioned, nothing in the associated wiki worked either.

Bottom line, the video had never given any problem before. Exactly after the "upgrade" and one (1) reboot, I got the aforementioned result. Nothing seems to bring it back. I am working on restoring the old kernel and hopeful of getting back to a usable computer.

Okay, I was finally able to use the Kernel Panic wiki page, and, after figuring out the errors there, get the older kernel reinstalled. (I found the correct one by using the Arch Rollback Machine web site and looking thru directories until I found the last one before the lost display.) I hope this will get others back and working again as well.

Now everything is back like it was before the disastrous kernel change. I realize that I must not have understood the Arch definition of "cutting edge". It must be "buggy and in need of testing by users". I should probably count myself lucky in that I was able to solve the problem by myself, and that I only lost one week of computer usage.

Sorry. How should we help you when you can't exactly describe what steps you do to solve your problem. Again, use the latest kernel from core and then either Xorg from extra or the one from testing. When your card can't work in kms mode you need to get it work in non-kms mode. I'd like to help but you need to give better feedback.

Last try: report you rc.conf, modprobe.conf, mkinitcpio.conf and kernel append line from grub. make sure you rebuild your initrd after changes you do. When something goes wrong report exactly the error messages you can get from screen, dmesg, everything.log.

If you are not interested I'll close this one soon.

Good heavens, Andreas; what part didn't I make clear?

I believe I was extremely clear in how to solve the problem. I described how I had to downgrade to the previous kernel. Those are the steps to solve the problem. Did you not read my post?

Of course I can't use the latest kernel since IT DOESN'T WORK RIGHT!!!!!
Of course one needs to get the card to work in non-kms mode; duh. You haven't been able to help with that yet; which is the point of posting the bug report.
Better feedback? Did you not read the post? There was no command line. I documented everything I had to do to get to the place where I could read the files requested. When I was finally able, I clearly listed the important content. Also, please note that no one asked for modprobe.conf before. And immediately when asked, here it is:
#
# /etc/modprobe.d/modprobe.conf (for v2.6 kernels)
#
Hope that helps a lot.

Error messages?
screen - I don't know how to read red lines. Maybe you do. If so, you're better than me.
dmesg - see attached
everything - see attached
(Please note again that the last two are only available now that I did all the work to get the system working again.)

I suggest this only be closed when the problem is found by the people who made the changes to the latest kernel and there is a published fix. Until such a time is reached, this is obviously not fixed and remains a reproduceable bug.

If you don't want to help, that's fine. But don't ever imply that I didn't do all I was asked. In fact I went much further to research and check with others who had similar problems. When a user cannot get to a usable screen, the very first thing should have been to give clear steps to boot into a usable display, but you choose not to do so. How else would some be able to give proper feedback? That is so obvious that it shouldn't have to be explained.

So, IMHO, we can either be a part of the problem or a part of the solution. Being a part of the solution is offering useful steps to get out of the problem. This I have done. What about you?

Hey c'mon, we need to fix the non-kms mode for the current .31.xx kernels. You won't be able to live a long time with the old one.

Please put radeon.modeset=0 into your /etc/modprobe.d/modprobe.conf, make sure the same is in your grub append line or try there with "nomodeset". Clean mkinitcpio.conf and rc.conf. pacman -S kernel26. See also http://wiki.archlinux.org/index.php/ATI#Kernel_Mode_Setting_Troubleshooting - so far you are the only one not getting 2.6.31.4 kernel booting.

When the kernel loads in non-kms mode passing the initrd shouldn't be hard. If it keeps hanging at udev loading modules that's can usually be fixed with loading the desired apg module before radeon module.

And please post logs from failing runs not from working old kernel. You should be able to find the log in everything.log even after a hardfreeze when klogd was already up at that state. Or try pressing STRG+PageUp to go back if possible.

First, please explain "radeon.modeset=0". Why does it start with the word "radeon"? Are there other forms? Are you sure that is the one I should use?

Second, if the setting is in grub, why does it also have to be in modprobe.conf, or vice versa? Also, I want to know why you think that setting will work now when it didn't before.

Third, what do you mean by "Clean mkinitcpio.conf and rc.conf"?

Fourth, do you next want me to run pacman -S kernel26 from the CLI?

Fifth, to be clear, when I pointed out that I had done the research, please know that I have already gone over the applicable part of the linked wiki page a number of times. And your statement that I am the only appears to be an unwarranted assumption without any foundation in reality. The fact is that I immediately knew what caused the problem, while many others would not recognise that. Perhaps they would not respond either. Also, I posted, when others may not have known what to do. Further, there are many other associated problems with this kernel upgrade which are listed right here in the bugs listings. IMHO, I think there is a lot more than video issues here, and many more people than might be sampled in the bugs listings. So, I hope you can understand my misgivings regarding the statements made.

Sorry, but you can understand how we are beginning to question some of the things we are told. Your suggested steps entail a lot of work whether or not successful, and the system works right now just fine with regard to the video. (I don't yet experience any other issue.)

Anyway, I am not sure how one guarantees that the kernel does load without the KMS mode. And as I pointed out, there is evidence to indicate that the system does not hang, but rather is struck with an unusable video. As to the logs, I don't think you understand how difficult what you are asking is to do. Hell, I don't even know what "STRG" stands for.

1) grub can pass options to any kernel module. syntax: modulenme"dot"option. check valid option for radeon module with modinfo radeon.

2) mkinicpio can build modules into the initrd. you need to specify the file modprobe.conf to include in mkinitcpio.conf. so you can modify the behavior in early "mode", if the radeon module should be included or not and what option you want to pass to the module.

3) remove the radeon module from the module line or blackmask it if you don't want it to be inluced in intrd or loaded at udev call

4) when you change settings for the initrd you need to rebuild it. this can be done with mkinitcpio -p kernelname or pacman -S kernelname

5) Closing this bug. KMS and non KMS mode both work for me and anybody else. The bugtracker is not for personal support. If you can't manage to solve it with the hints I gave you please ask in our support forum and irc channels. I'm sure you will find out what you are doing wrong.

This is a big problem with lots of people (me included) in kernel 2.6.31. Fedora, Red Hat and OpenSuse people are experiencing this exact issue (search their bug trackers). It is definitely a radeon driver/KMS problem. Please reopen.

This is fixed only in recent git commits. 2.6.32.1 still has it. Should be closed with 2.6.32.2.

Svenstaro, it is nice to see that others are finally realizing that what I had experienced was a kernel issue. I was beginning to think that I lived alone in a parallel universe. Similar to the old saying "But we've always done it this way", is the one that states "It works for me, so there can't be any problem with anyone else". This remains a huge problem that many don't care to acknowledge.

Thanks for your help. I appreciate people who aren't afraid to stand up and point out that the emperor has no clothes.

Now, now. Everybody makes errors and sometimes does quick judgment when under some stress. Let's all love and be friends. :)
Rather than that, can you try git master and see if the problem appears for you? I can only replicate it inconsistently.

Well, I do love you. :) But you ought to see all the fantastic examples I've come across. But I can never be sure where the good intentions leave off and poor planning and coding begin.

So there is no way I will go thru that problem again. I'll wait until the new kernel is available in the normal way. I figure that more delay is beter, because I can then allow them (whoever they are) more time for testing. Like many users, I'm kind of tired being a guinea pig. So I'll be watching this problem closely.

Thanks again.

Good news, everyone. The latest kernel upgrade has been fixed. I installed 2.6.32.2-2 and rebooted. NO VIDEO PROBLEMS!!!!!!!!
Yahooooooo!!!!!!

Of course there is no way in hell that any of us peons will be able to find where the change was made and exactly what it was. But I do know one thing for sure; it works now and the version changed. Discuss it amongst yourselves.

The bottom line? It works for me. Mark this one as "Solved".

Big thanks to whoever figured it out!