Bug 92891
| Summary: | Maschine hangs forever at loading the radeon module | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | georg |
| Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
| Status: | NEW --- | ||
| Severity: | normal | CC: | alexdeucher, szg00000 |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | v3.14.31-rt28 / e1a0d6d8b023c54a5677310e68222e7a58b11f91 / linux-stable-rt | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
Kernel config
config 3.10.20-rt17 which did run for a year with evergreen card bisect log the config used as the bisect ended vbios PITCAIRN dmesg of current 3.18.5 (non rt) dmesg when display doesnt update anymore |
||
Created attachment 166051 [details]
config 3.10.20-rt17 which did run for a year with evergreen card
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. Can you bisect? 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. Created attachment 166201 [details]
bisect log
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. Created attachment 166211 [details]
the config used as the bisect ended
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 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 Does disabling dpm help? Append radeon.dpm=0 to the kernel command line in grub. 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 Created attachment 166481 [details]
vbios PITCAIRN
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? (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. Created attachment 166491 [details]
dmesg of current 3.18.5 (non rt)
This is from the curren working 3.18.5 (non-rt) kernel.
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
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 .... |
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?