https://bugs.freedesktop.org/show_bug.cgi?id=83792
Priority: medium Bug ID: 83792 Assignee: dri-devel@lists.freedesktop.org Summary: Kernel hangs on boot without nomodeset option Severity: normal Classification: Unclassified OS: All Reporter: wayland@wayland.id.au Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI
Hi all. I have a Radeon FireMV 2400. I'm attempting to upgrade from Fedora 13 (kernel 2.6.33) to Fedora 20. More recent kernels have not worked for me; I recently discovered that if I use the nomodeset option, then I can book, but xorg no longer functions. Since it seems that using the nomodeset option is no longer going to be supported, I need to make this work without the nomodeset option. Unfortunately, the computer hangs (no ping via network) during boot. I tried to give it the netconsole option, but this did not seem to produce any results. What else can I try to help resolve this problem?
Thanks,
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #1 from Alex Deucher agd5f@yahoo.com --- Can you elaborate on what "not worked" means? Blank screen, corruption, hangs? Are you able to access the machine remotely? If so, can you attach your xorg log and dmesg output with the radeon driver loaded? Can you bisect the kernel to determine what commit broke your card?
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #2 from Tim Nelson wayland@wayland.id.au --- Regarding "not worked", these kernels have always hung on boot with a blank screen; most of these are from my attempts to upgrade to various different versions of Fedora between 13 (currently working for me) and 20 (the one I'm attempting to install now). I suspect that these kernels weren't being passed the "nomodeset" option by default, but I have no evidence of that, and I don't plan to go back and look unless it becomes necessary, since I want to get the Fedora 20 kernel working, rather than the intermediate ones.
When I boot the machine (after removing the "quiet rhgb" options, and adding "debug"), the machine spits out a bunch of log messages that scroll too quickly for me to see, and then the screens go blank (the LCD one displaying the message "No Signal"), and I can't access the machine remotely at that point; unfortunately this means that I also can't post the relevant dmesg and xorg information. I think the machine is hanging before the network card is enabled, although I will try to double-check that.
As for bisecting the kernel, I can have a go, but I suspect it will be the original KMS commit.
Thanks for the time you've put into this. I'll have some more time to put into it later, but probably not for another week or two, unfortunately.
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #3 from Christian König deathsimple@vodafone.de --- Well the nomodeset option only makes sense with the UMS support and that was deprecated in January 2013.
So as long as Fedora 20 doesn't compile their kernels with a deprecated feature they probably won't support nomodeset any more.
Without any logs it would be rather hard to figure out what's going wrong here.
So is there a possibility to attach for example a serial or network console to grab the last few lines of system log before the machine goes into nirvana?
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #4 from Alex Deucher agd5f@yahoo.com --- Can you also try blacklisting radeon and loading it after the box has booted and you have remote access? E.g., append modprobe.blacklist=radeon 3 to the kernel command line in grub (the 3 is to boot into runlevel 3 so X doesn't start). Then once the system is booted and you have remote access, as root, run: modprobe radeon and see if you can get the dmesg output.
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #5 from Tim Nelson wayland@wayland.id.au --- Just reporting back; blacklisting radeon as Alex specifies allows the machine to boot. "modprobe radeon" after boot makes it die. Unfortunately I only had a little time to put into it, so that's all my results at the moment, but I hope to put more time into it in the next couple of days.
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #6 from Tim Nelson wayland@wayland.id.au --- Created attachment 107113 --> https://bugs.freedesktop.org/attachment.cgi?id=107113&action=edit Kernel messages, round 1
Good news; I have some kernel messages to attach. These were gained using netconsole, which was on another machine. It seems to me that it detects the radeon FireMV2400 (although it never mentions it by name), and detects two of the four connectors (I'm assuming two that are connected to the same chip; this card has 2 chips with 2 displays each; total of 4 displays).
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #7 from Tim Nelson wayland@wayland.id.au --- Anyway, it looks like I was wrong about the kernel modesetting; I think this is a side-effect of the more modern radeon driver not supporting nomodeset. So it's just a bug in the radeon driver, pure and simple. So now I suspect I have to do a kernel bisect. If you have any other advice, though, let me know.
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #8 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #6)
Created attachment 107113 [details] Kernel messages, round 1
Good news; I have some kernel messages to attach. These were gained using netconsole, which was on another machine. It seems to me that it detects the radeon FireMV2400 (although it never mentions it by name), and detects two of the four connectors (I'm assuming two that are connected to the same chip; this card has 2 chips with 2 displays each; total of 4 displays).
If netconsole works, can you get remote access to the box (e.g., ssh) as well or does it hang completely?
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #9 from Tim Nelson wayland@wayland.id.au --- OK, I've narrowed it down quite a bit.
The kernel which Fedora (18) calls kernel-debug-3.6.10-4.fc18.x86_64 works. Xorg segfaults, but the radeon module successfully loads. The kernel which Fedora (19) calls kernel-debug-3.9.5-301.fc19.x86_64 crashes the machine.
Anyway, I will do some more narrowing down, and I'll try ssh access as well.
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #10 from Tim Nelson wayland@wayland.id.au --- OK, another report. First, when it locks up, there is no ssh access possible; it doesn't even ping.
Second, I've narrowed it down this far:
Working: kernel-debug-3.6.11-3.fc18.x86_64 Not working: config-3.7.0-0.rc0.git2.4.fc19.x86_64
Those kernel version numbers are the RPM packages that I installed.
Third, I grabbed a copy of the dmesg messages on the working kernel, so that we can see what happened immediately after the place where the crash was introduced. These may also be enlightening. I'll attach them.
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #11 from Tim Nelson wayland@wayland.id.au --- Created attachment 107982 --> https://bugs.freedesktop.org/attachment.cgi?id=107982&action=edit Kernel messages, last working version (3.6.11)
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #12 from Tim Nelson wayland@wayland.id.au --- Oh, one more comment - is there anything else I can do to help track down this bug further?
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #13 from Tim Nelson wayland@wayland.id.au --- Hmm. Just noticed that that one kernel version number says "config" at the start instead of "kernel". That's because I got the version number from the config file in /boot.
https://bugs.freedesktop.org/show_bug.cgi?id=83792
--- Comment #14 from Alex Deucher agd5f@yahoo.com --- (In reply to Tim Nelson from comment #12)
Oh, one more comment - is there anything else I can do to help track down this bug further?
Ideally you could use git to bisect between 3.6 and 3.7 to see what change caused the regression.
https://bugs.freedesktop.org/show_bug.cgi?id=83792
Martin Peres martin.peres@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |MOVED Status|NEW |RESOLVED
--- Comment #15 from Martin Peres martin.peres@free.fr --- -- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/530.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org