I'm using the git snapshots between when Linus merged from drm-core-next and when network drivers were merged (breaks build). If there is a better patch relative to a released source I'll gladly test it too; however the other sources I tried also had similar issues. When radeon.ko (or build in init) starts the screens blank and a few seconds later the system completely reboots. This is 100% repeatable. I have firmware from Arch's (AUR) linux-firmware-git package installed, /lib/firmware pointed as the source, and the relevant blobs for the recent ATI/AMD GPUs. When built as a module I can modprobe radeon to trigger the exact same behavior. Problems debugging: * It resets so hard there isn't a peep from netconsole. * It resets so hard that my disks loose md raid sync and need to completely rebuild (yeah, I know, I'll add a write-intent log before I test this again next time...; it wasn't an issue before I got the brainwave of making it a module to try to give netconsole/syslog time to get setup.) How can I possibly approach isolating this? Even a link to the correct documentation would be helpful.
What radeoon chip do you have? If it's an r6xx, r7xx, or evergreen asic, this possibly a duplicate of this bug: https://bugs.freedesktop.org/show_bug.cgi?id=33027 If so, does the patch there help?
It's a 6850 with two DVI's in use. I think that's a "Northern Islands" chip? The system is an Athlon II x4, 00:00.0 Host bridge: Advanced Micro Devices [AMD] RS880 Host Bridge ( M4A785TD-V EVO vendor: ASUSTeK Computer INC. ) I'm going to try booting a copy of drm-next's tree that finished compiling while I was running errands; it should have everything possible already. drm-2.6-drm-next-56bec7c - Nope, that totally failed too. I'm going to collect some system information and what logs I can.
Created attachment 43702 [details] lspci, dmidecode, config and netconsole logs
I noticed something when looking at the files in /lib/firmware/radeon to make sure I had /all/ the correct ones in place. BARTS*, which wasn't in my config (I copy/pasted an example for that section without paying it much attention, and wouldn't have remembered which chip codename I had anyway.) when added allows at /least/ drm-next to work correctly. There are two outstanding issues I noticed however. 1) When the firmware isn't found the module very un-gracefully reboots without //any// explanation (no information provided to lead to enlightenment). Correct behavior should be to fail gracefully and provide a clean message in the kernel log without taking the system fully offline. 2) the EXTRA firmware line has a size limit. I didn't look at what it was exactly, but it can't contain the expansion of cd /lib/firmware; ls radeon/* ; a more preferable solution might be to allow the use of shell wildcards (or document that they are evaluated). I am --not-- marking this as resolved since the first issue is still a major problem (it makes this error non-trivial to diagnose for no good reason).
Created attachment 46072 [details] Don't load if MC ucode is not available The default boot state only allows limited operation.
Michael please confirm Alex fixed the issue (should be upstream already)