Bug 66942

As a side note, it could be related to bug 66940

probably a duplicate of bug 66551.

(In reply to comment #2)
> probably a duplicate of bug 66551.

Probably not, the bug happens prior to the commit identified in bug 66551. I'm bisecting as we are talking.

I also noticed a small glitch that was not in kernel 3.9 but is present in 3.10 that I'll report in another bug.

Here is the first bad commit, which is pretty large since it doesn't point what was changed before. It could be about any commit before that that touches Cayman.

69e0b57a91adca2e3eb56ed4db39ab90f3ae1043 is the first bad commit
commit 69e0b57a91adca2e3eb56ed4db39ab90f3ae1043
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Apr 12 16:42:42 2013 -0400

    drm/radeon/kms: add dpm support for cayman (v5)
    
    This adds dpm support for cayman asics.  This includes:
    - clockgating
    - dynamic engine clock scaling
    - dynamic memory clock scaling
    - dynamic voltage scaling
    - dynamic pcie gen1/gen2 switching (requires additional acpi support)
    - power containment
    - shader power scaling
    
    Set radeon.dpm=1 to enable.
    
    v2: fold in tdp fix
    v3: fix indentation
    v4: fix 64 bit div
    v5: attempt to fix state enable
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Jerome Glisse <jglisse@redhat.com>

:040000 040000 aa90c4d442d7640629695b1dc48e0ef1b3958e20 fc06e4965a658e0600ab5b250ae135e9e8225ca4 M	drivers

Sounds like you may be waiting for the firmware loader to timeout.  Make sure you have the new cayman smc ucode installed:
http://people.freedesktop.org/~agd5f/radeon_ucode/CAYMAN_smc.bin

(In reply to comment #5)
> Sounds like you may be waiting for the firmware loader to timeout.  Make
> sure you have the new cayman smc ucode installed:
> http://people.freedesktop.org/~agd5f/radeon_ucode/CAYMAN_smc.bin

Yes, it was missing. I'll test kernel 3.11-rc1 with it and with bug 66551's patch.

I may be doing something wrong, but even with the firmware in the same folder as the others (/usr/lib/firmware/radeon) and 66551's patch, it still hangs at the same place.

Here is the content of that folder.
/usr/lib/firmware/radeon$ ls -l CAYMAN*
-rw-r--r-- 1 root root 24148 May 29 20:22 CAYMAN_mc.bin
-rw-r--r-- 1 root root  8704 May 29 20:22 CAYMAN_me.bin
-rw-r--r-- 1 root root  8704 May 29 20:22 CAYMAN_pfp.bin
-rw-r--r-- 1 root root  4096 May 29 20:22 CAYMAN_rlc.bin
-rw-r--r-- 1 root root 31212 Jul 16 21:10 CAYMAN_smc.bin

Did you re-generate the initrd after installing the missing firmware?

If the problem is the missing firmware, it should continue booting after three minutes or so. Have you waited that long?

(In reply to comment #8)
> Did you re-generate the initrd after installing the missing firmware?
> 
> If the problem is the missing firmware, it should continue booting after
> three minutes or so. Have you waited that long?

Yes. And just to be sure, I rebuilt the kernel tonight and reinstalled it (with a new generated initramfs). I also decompressed the initramfs file and had a look if the firmware had been packaged. There it was.

Also, it never timed out, it sat there for ever (I took time to have dinner).

Tested with today's kernel from Linus' git. Still the same. I built the radeon driver in the kernel instead of building it as a module. No change.

Does it boot correctly if you build radeon as a module, then disable radeon (add radeon.modeset=0 to your kernel command line in grub) and boot to a non-X runlevel, then load radeon manually?

modprobe -r radeon
modprobe radeon modeset=1

(In reply to comment #11)
> Does it boot correctly if you build radeon as a module, then disable radeon
> (add radeon.modeset=0 to your kernel command line in grub) and boot to a
> non-X runlevel, then load radeon manually?
> 
> modprobe -r radeon
> modprobe radeon modeset=1

No, sadly, it still hangs at the same place. Problem is, I can't tell if it hangs when loading the initramfs or when it tries to initialize the display beyond that...

Any other suggestion? By the way, I built an 3.11.0-rc2 kernel this morning with as few drivers as possible for my system, just in case, but without any luck.

Same/similar problem here, with firmware built into the kernel (vanilla 3.11.0-rc2). With nomodeset the system boots, without it it doesn't.

Please ignore my post, it was a kernel configuration problem. Got confused by the many tests and used a wrong config... DPM works fine now, but radeon ring 5 problem with GPU stall after resuming from hibernation still exists in 3.11-rc2. Maybe some patches haven't made it into git yet, so I'll look for them.

(In reply to comment #14)
> Please ignore my post, it was a kernel configuration problem. Got confused
> by the many tests and used a wrong config... DPM works fine now, but radeon
> ring 5 problem with GPU stall after resuming from hibernation still exists
> in 3.11-rc2. Maybe some patches haven't made it into git yet, so I'll look
> for them.

What was the error in your kernel config?

Sorry, I think I have to disappoint you, I don't think it will help with your problem; I got the wrong config without the CAYMAN_smc.bin, and it hang for a minute or so. After adding it, all worked fine (except for the issue with hibernate/resume).

Alex, is there a chance for me to reverse some commits prior to 69e0b57 to find which one or which feature is hanging my computer? Any approach I should try?

(In reply to comment #17)
> Alex, is there a chance for me to reverse some commits prior to 69e0b57 to
> find which one or which feature is hanging my computer? Any approach I
> should try?

I'm not really sure what would have broken your system.  I also don't really see how 69e0b57 could have broken anything since nothing changes with that as long as dpm is disabled.  Do you still have the issue if you reset your tree to the commit prior to 69e0b57?  Do you still get hangs if you disable radeon (e.g., add radeon.modeset=0 to your kernel command line in grub)?

Does booting a recent 3.11rc kernel with radeon.aspm=0 help?

(In reply to comment #19)
> Does booting a recent 3.11rc kernel with radeon.aspm=0 help?

No, still hangs at the same point.

(In reply to comment #18)
> (In reply to comment #17)
> > Alex, is there a chance for me to reverse some commits prior to 69e0b57 to
> > find which one or which feature is hanging my computer? Any approach I
> > should try?
> 
> I'm not really sure what would have broken your system.  I also don't really
> see how 69e0b57 could have broken anything since nothing changes with that
> as long as dpm is disabled.  Do you still have the issue if you reset your
> tree to the commit prior to 69e0b57?  Do you still get hangs if you disable
> radeon (e.g., add radeon.modeset=0 to your kernel command line in grub)?

I'll have to test when I'll get home, but I rebuilt a rc3 yesterday night and I made sure to make it clean. I'll see if this helps. I'll also go back just prior to 69e0b57 if it doesn't help. Finally, I'll play with the init and disable some options just in case. Who knows what might help.

(In reply to comment #18)
> (In reply to comment #17)
> > Alex, is there a chance for me to reverse some commits prior to 69e0b57 to
> > find which one or which feature is hanging my computer? Any approach I
> > should try?
> 
> I'm not really sure what would have broken your system.  I also don't really
> see how 69e0b57 could have broken anything since nothing changes with that
> as long as dpm is disabled.  Do you still have the issue if you reset your
> tree to the commit prior to 69e0b57?  Do you still get hangs if you disable
> radeon (e.g., add radeon.modeset=0 to your kernel command line in grub)?

Good new, if I can say. I cleaned my build tree, updated my packages (one was about gcc), redownloaded the firmware and recompiled 69e0b57: it now boots with and without radeon.dpm=1. So, I'm closing this bug. One of those things must have been the culprit.

I just have to test with rc3 now and hope for the best.