Not sure if this has been known. After trying to update to kernel 3.13rc2, I get problems booting my mini.iso system. Once the system loads, it loses the HDMI signal, and I get no picture. I get errors talking about the HAWAII drivers not loaded: update-initramfs: Generating /boot/initrd.img-3.13.0-031300rc2-generic W: Possible missing firmware /lib/firmware/radeon/HAWAII_smc.bin for module radeon W: Possible missing firmware /lib/firmware/radeon/HAWAII_sdma.bin for module radeon W: Possible missing firmware /lib/firmware/radeon/HAWAII_rlc.bin for module radeon W: Possible missing firmware /lib/firmware/radeon/HAWAII_mc.bin for module radeon W: Possible missing firmware /lib/firmware/radeon/HAWAII_mec.bin for module radeon W: Possible missing firmware /lib/firmware/radeon/HAWAII_ce.bin for module radeon W: Possible missing firmware /lib/firmware/radeon/HAWAII_me.bin for module radeon W: Possible missing firmware /lib/firmware/radeon/HAWAII_pfp.bin for module radeon here are my log files:xbmc@xbmc:~$ dmesg | pastebinit http://paste.ubuntu.com/6514897/ xbmc@xbmc:~$ cat ~/.xbmc/temp/xbmc.log | pastebinit http://paste.ubuntu.com/6514899/ xbmc@xbmc:~$ cat /var/log/Xorg.0.log | pastebinit http://paste.ubuntu.com/6514901/ xbmc@xbmc:~$ DISPLAY=:0 vdpauinfo | pastebinit [1]+ Stopped DISPLAY=:0 vdpauinfo | pastebinit xbmc@xbmc:~$ dpkg -l | grep mesa | pastebinit http://paste.ubuntu.com/6514909/ as you can see, when I try to run DISPLAY=:0 vdpauinfo, my system hangs, and I have to force kill the command.
Created attachment 90196 [details] [review] possible fix Does the attached patch fix the issue? Also, please attach files rather than pointing to pastebin since pastebin entries can disappear.
this patch did not fix the issue. should I attach newer logs?
(In reply to comment #2) > this patch did not fix the issue. > > should I attach newer logs? Does the patch fix the segfault in dce6_afmt_write_speaker_allocation?
(In reply to comment #2) > this patch did not fix the issue. > > should I attach newer logs? Yes, please attach the logs with the patch applied.
now it's saying: perf samples too long (* > *), lowering kernel.per_event_max_sample_rate to *** this repeats for about 5 lines where I have asteriks(*), are random numbers that keep changing every time a new line shows up. this is the last line: perf samples too long (463153 > 250000), lowering kernel.per_event_max_sample_rate to 500 seems to have stopped here.
okay, i was able to get past that last error. I apologize, it was a bad kernel build (i'm pretty sure). now I'm able to get the kernel to load a little more, and I'm now getting this on my screen i get: *ERROR* UVD not responding, trying to reset the VCPU!!! this repeats until it gives up then it says: *ERROR* radeon: failed initializing UVD (-1) i've had other people report this similar experience with this patch
(In reply to comment #6) > okay, > > i was able to get past that last error. > I apologize, it was a bad kernel build (i'm pretty sure). > > now I'm able to get the kernel to load a little more, and I'm now getting > this > > on my screen i get: > *ERROR* UVD not responding, trying to reset the VCPU!!! > > this repeats until it gives up > then it says: > *ERROR* radeon: failed initializing UVD (-1) Make sure you have installed the latest rlc ucode for your chip and make sure you've updated the ucode in your initrd if you are using one. > > i've had other people report this similar experience with this patch Which patch?
> > Make sure you have installed the latest rlc ucode for your chip and make > sure you've updated the ucode in your initrd if you are using one. I'm not sure what you mean. can you point me in the right direction? thanks in advance. > > > > > i've had other people report this similar experience with this patch > > Which patch? the patch you provided above.
i copied over the HAWAII drivers from here -> http://people.freedesktop.org/~agd5f/radeon_ucode/ so when i run: update-initramfs -k all -u it no longer complains about the HAWAII firmware not installed. was this the proper way to do this? when i pull the git version of linux-firmware, these files are not in the repo.
(In reply to comment #8) > > > > Make sure you have installed the latest rlc ucode for your chip and make > > sure you've updated the ucode in your initrd if you are using one. > my system is just not very stable. sometimes i get the UVD errors sometimes i get the reference to [<ffffffffa01b7ecb>] dce6_afmt_write_speaker_allocation+0xdb/0x140 [radeon] and a couple of times it will get a little bit further, and then freeze. but i can't get any logs, cause it never gets to loading my network.
not sure if these reports will help you. http://forum.xbmc.org/showthread.php?tid=174854&page=123 i see that you and fritsch are working together on this. thanks for all your help and support. let us know if there is any information that we can give you to help out.
(In reply to comment #9) > i copied over the HAWAII drivers from here -> > http://people.freedesktop.org/~agd5f/radeon_ucode/ > > so when i run: > update-initramfs -k all -u > > it no longer complains about the HAWAII firmware not installed. > was this the proper way to do this? Yes. You can ignore the hawaii errors though since you aren't using a hawaii board.
Created attachment 90534 [details] dmesg Here are new logs with the latest drm-intel kernel (http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/)
Created attachment 90535 [details] X.org.0.log
still no signal with the latest kernel from today Dec. 10. do you need more logs?
(In reply to comment #15) > still no signal with the latest kernel from today Dec. 10. Can you bisect?
i can try. i can tell you that this started happening as soon as 3.13 started rolling out. so, i will try to start there.
which git repo should i use? https://www.kernel.org/
Yes, please use Linus' git tree: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
3017 revisions between 3.12 - 3.13rc1 wow!!! this is gonna take a while. is there a faster way???
i think i have found the culprit. it was a merge that happened right before rc2. i'm still bisecting, i have about 6 more steps to go. so, hopefully by the end of the week, i will have a report.
i'm still testing. this is my log so far: root@xbmc:~/linux# git bisect log # bad: [dc1ccc48159d63eca5089e507c82c7d22ef60839] Linux 3.13-rc2 # good: [5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52] Linux 3.12 git bisect start 'v3.13-rc2' 'v3.12' # good: [5cbb3d216e2041700231bcfc383ee5f8b7fc8b74] Merge branch 'akpm' (patches from Andrew Morton) git bisect good 5cbb3d216e2041700231bcfc383ee5f8b7fc8b74 # good: [d8fe4acc88da8fbbe360b6592c9d0abbb85117dc] Merge branch 'akpm' (patch-bomb from Andrew Morton) git bisect good d8fe4acc88da8fbbe360b6592c9d0abbb85117dc # good: [4914d7b458e35a7db2f9c7dc6eb014620254bbbf] alpha: Use qemu+cserve provided high-res clock and alarm. git bisect good 4914d7b458e35a7db2f9c7dc6eb014620254bbbf # bad: [82023bb7f75b0052f40d3e74169d191c3e4e6286] Merge tag 'pm+acpi-2-3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm git bisect bad 82023bb7f75b0052f40d3e74169d191c3e4e6286 # bad: [1ea406c0e08c717241275064046d29b5bac1b1db] Merge tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband git bisect bad 1ea406c0e08c717241275064046d29b5bac1b1db ---------------
Created attachment 90699 [details] dmesg Same problem.
Created attachment 90700 [details] Xorg
Created attachment 90723 [details] [review] possible fix Does this patch fix the issue?
Created attachment 90731 [details] dmesg Still broken.
Created attachment 90732 [details] Xorg
Created attachment 90735 [details] first bad commit so, it says that this is the first bad commit for me. doesn't seem quite right, and this seems to deal with Samba...
Created attachment 90736 [details] git bisect log Here's my full git bisect log. still not sure if I did this correctly. I never saw a 3.13 kernel build...?
Created attachment 90737 [details] [review] possible fix Does this patch work any better?
Created attachment 90739 [details] dmesg i now have a working screen. i get this error in dmesg: [drm:dce4_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0 but video and audio is working for me. many thanks.
yup... this patch works!!! now we just gotta figure out the artifacts :-)
-- 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/414.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.