Bug 92891 - Maschine hangs forever at loading the radeon module
Summary: Maschine hangs forever at loading the radeon module
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-07 10:42 UTC by georg
Modified: 2016-03-23 18:30 UTC (History)
2 users (show)

See Also:
Kernel Version: v3.14.31-rt28 / e1a0d6d8b023c54a5677310e68222e7a58b11f91 / linux-stable-rt
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Kernel config (91.90 KB, application/octet-stream)
2015-02-07 10:42 UTC, georg
Details
config 3.10.20-rt17 which did run for a year with evergreen card (99.44 KB, application/octet-stream)
2015-02-07 10:43 UTC, georg
Details
bisect log (2.48 KB, text/plain)
2015-02-09 18:00 UTC, georg
Details
the config used as the bisect ended (90.70 KB, text/plain)
2015-02-09 18:03 UTC, georg
Details
vbios PITCAIRN (99.00 KB, application/octet-stream)
2015-02-11 18:00 UTC, georg
Details
dmesg of current 3.18.5 (non rt) (46.56 KB, text/plain)
2015-02-11 19:58 UTC, georg
Details
dmesg when display doesnt update anymore (24.27 KB, text/plain)
2015-02-11 20:05 UTC, georg
Details

Description georg 2015-02-07 10:42:27 UTC
Created attachment 166041 [details]
Kernel config

Hi all,

recently i changed my Gfx card from a evergreen/hd5770 to a pitcairn/r290 (Chipset: "PITCAIRN" (ChipID = 0x6811)).
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Curacao PRO [Radeon R9 270] [1002:6811]

On a second partition a realtime system without any problems. The system ran for a year with the kernel 3.10.20-rt17 perfect fine. 

Now as i updated my hardware with the new gfx card i started the RT system, i assumed the problem is the gfx card driver. I updated the kernel to the latest in 
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git . The first try was v3.14.31-rt28. But it froze like the old (v3.10.20-rt17) kernel. After some testing i found out that the old (3.10) and the new (3.14) kernel start the machine when i disable KMS (radeon.modeset = 0). 

The exact point in the startup procedure is "Waiting for uevents". At this stage udev get started and loads the modules. 

After testing various kernel versions i picked 3.14.31-rt28 this did start the machine without the commandline "radeon.modeset=0" and i thought i have a working commit, but X did not start and i tried to load the module manually. At this point (modprobe radeon) the machine froze again.

I attached the old evergreen card in the machine and tested with this card what configuration runs. I got the following results:

Evergreen:
v3.10.20-rt17    Ok
v3.14.20-rt17    Not Ok (freeze)

Pitcairn:
v3.10.20-rt17    Not Ok (freeze)
v3.14.20-rt17    Not Ok (freeze)


So i just filled this bugreport against the newest version i tried.

What info should i add?
Comment 1 georg 2015-02-07 10:43:46 UTC
Created attachment 166051 [details]
config 3.10.20-rt17 which did run for a year with evergreen card
Comment 2 georg 2015-02-07 10:45:33 UTC
Sorry: Correction
After testing various kernel versions i picked 3.8.13.14-rt31 this did start the machine without the commandline "radeon.modeset=0" and i thought i have a working commit, but X did not start and i tried to load the module manually. At this point (modprobe radeon) the machine froze again.
Comment 3 Alex Deucher 2015-02-09 15:29:17 UTC
Can you bisect?
Comment 4 georg 2015-02-09 17:59:30 UTC
Hello Alex,

this is my bisect result:
git bisect bad
01ac8794a77192236a4b91c33adf4177ac5a21f0 is the first bad commit
commit 01ac8794a77192236a4b91c33adf4177ac5a21f0
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Dec 18 19:11:27 2013 -0500

    drm/radeon: re-order firmware loading in preparation for dpm rework
    
    We need to reorder the driver init sequence to better accomodate
    dpm which needs to be loaded earlier in the init sequence.  Move
    fw init up so that it's available for dpm init.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

:040000 040000 eba931a20e6dbe63d4b24e7e0fce83a8ac24d327 4e0bc09de082e88d43615b492b3a9433f99148f5 M	drivers

I added my bisect log.
Comment 5 georg 2015-02-09 18:00:14 UTC
Created attachment 166201 [details]
bisect log
Comment 6 georg 2015-02-09 18:01:59 UTC
I know this is a commit not on the RT Tree. I have done this bisecting with the evergreen card.

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Juniper XT [Radeon HD 5770] [1002:68b8]

As config i always used the 3.14.20-rt17 config for oldconfig source.
Comment 7 georg 2015-02-09 18:03:03 UTC
Created attachment 166211 [details]
the config used as the bisect ended
Comment 8 georg 2015-02-09 19:29:33 UTC
After the current bisect result did not satisfy me, i tried various other RT
kernels prior the 3.13 result from the bisect with the evergreen card.

Between 3.12.15-rt25 and 3.10.20-rt17 i have no rt tags in my tree. I know
that both cards run with 3.18.5 (non rt). 

So i tried a manual search in the tree, i tried "non-rt" and "rt" versions out of my tree with the evergreen card.

3.12.37-rt51 : bad
3.12.15-rt25 : bad
3.10.20-rt17 : good
3.10.67-rt71 : good

3.11.0 : good
3.12.0 : good
3.12.15: bad
3.13.0 : good
Comment 9 georg 2015-02-09 19:59:18 UTC
Now plug the PITCAIRN card into the pc again. I tried the saved kernels from avouve. There i discouvered, that the machine is not hanging itself, it is just the display which hangs. The display connected to the DVI-0 and DVI-1 port dont update anymore. I could ssh into the machine. Even the RT kernels did respond.... 

The results with the PITCAIRN card:
3.12.37-rt51 : No image
3.12.15-rt25 : No image
3.10.20-rt17 : No image
3.10.67-rt71 : No image

3.11.0 : No image
3.12.0 : No image
3.12.15: No image
3.13.0 : No image
Comment 10 Alex Deucher 2015-02-09 20:02:00 UTC
Does disabling dpm help?  Append radeon.dpm=0 to the kernel command line in grub.
Comment 11 Alex Deucher 2015-02-09 20:03:36 UTC
Please attach your dmesg output and a copy of your vbios.  To get a copy of your vbios:
(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom
Comment 12 georg 2015-02-11 18:00:08 UTC
Created attachment 166481 [details]
vbios PITCAIRN
Comment 13 georg 2015-02-11 18:02:17 UTC
With radeon.dpm=0 the 3.10.67 kernel did boot up and showed me on the PITCAIRN card the display and let me work on it.

What kernel/card combination dmesg log should i post?
Comment 14 Alex Deucher 2015-02-11 18:24:02 UTC
(In reply to georg from comment #13)
> With radeon.dpm=0 the 3.10.67 kernel did boot up and showed me on the
> PITCAIRN card the display and let me work on it.
> 
> What kernel/card combination dmesg log should i post?

It doesn't matter.  I just want to see the basic output from the driver.
Comment 15 georg 2015-02-11 19:58:38 UTC
Created attachment 166491 [details]
dmesg of current 3.18.5 (non rt)

This is from the curren working 3.18.5 (non-rt) kernel.
Comment 16 georg 2015-02-11 20:05:18 UTC
Created attachment 166501 [details]
dmesg when display doesnt update anymore

And this is the dmesg when the display doesnt update anymore without radeon.dpm=0
Comment 17 georg 2015-02-11 20:11:55 UTC
Oh my god! I just saw it!
[   17.080350] si_cp: Failed to load firmware "radeon/PITCAIRN_pfp.bin"

After i copied from my other partition the radeon firmware to /lib/firmware, the display is now ok....

I wonder why the 3.14 kernel did not install the firmware ....

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