<div dir="ltr"><div><div><div><div><div><div><div><div>It works.<br>- I applied the patch (manually),<br>-  recompiled Ubuntu 14.04's kernel 3.13.0-44-generic AMD64,<br></div>- uninstalled Catalyst,<br></div>- and removed nomodeset kernel parameter from grub.<br><br></div><div>Ubuntu says I'm running Gallium 0.4 on AMD CAPE VERDE<br><br>sudo lshw -c video<br>[sudo] password for fede: <br>  *-display               <br>       descripción: VGA compatible controller<br>       producto: Cape Verde XT [Radeon HD 7770/8760 / R7 250X]<br>       fabricante: Advanced Micro Devices, Inc. [AMD/ATI]<br>       id físico: 0<br>       información del bus: pci@0000:01:00.0<br>       versión: 00<br>       anchura: 64 bits<br>       reloj: 33MHz<br>       capacidades: pm pciexpress msi vga_controller bus_master cap_list rom<br>       configuración: driver=radeon latency=0<br>       recursos: irq:50 memoria:d0000000-dfffffff memoria:fde80000-fdebffff ioport:ee00(size=256) memoria:fde00000-fde1ffff<br><br></div>It's working fine AFAIK. <br>I player a few 1080 videos full screen, played duke nukem3d. Unity desktop seems fine.<br><br></div>Here are some logs in case you want to see anything there.<br><br></div>Xorg.log: <a href="https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299507/+files/Xorg.0.log">https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299507/+files/Xorg.0.log</a><br></div>dmesg: <a href="https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299508/+files/dmesg_working.txt">https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299508/+files/dmesg_working.txt</a><br></div>lspci: <a href="https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299509/+files/lspci_working.txt">https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299509/+files/lspci_working.txt</a><br><br></div>I'd love to see this patch pushed everywhere. :-)<br><div><div><div><div><div><div><br></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-15 3:21 GMT-03:00 Michel Dänzer <span dir="ltr"><<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15.01.2015 12:53, Federico wrote:<br>
> How about this? It seems at least related.<br>
><br>
> <a href="https://github.com/alterapraxisptyltd/openatom/issues/1" target="_blank">https://github.com/alterapraxisptyltd/openatom/issues/1</a><br>
><br>
> Quote:<br>
> [linux] Infinite loop in pci_get_rom_size()<br>
><br>
> This is one of those issues that you find when putting supposedly stable<br>
> code through unusual situations. I did expect any function in linux that<br>
> is not part of radeon.ko to not be rock solid. Turns out that's not<br>
> really the case.<br>
><br>
> If we have a PCIR structure with a zero size length, the loop iterating<br>
> through those structure does not advance. It simply does "image +=<br>
> readw(pds + 16) * 512;", but if that field is zero we're back analyzing<br>
> the same structure on the next loop. The way to get out of this loop is<br>
> to set bit 7 of the type field. That's what 'last_image' does. If that<br>
> bit is not set, with the above, that's an infinite loop.<br>
><br>
> Luckily, it doesn't crash the kernel, but it hangs any driver that calls<br>
> the function under said circumstances. No more modprobe -r or unbinding.<br>
> Reboot is needed. No idea why a firmware blob here is treated as trusted<br>
> input.<br>
<br>
</span>That could indeed explain it, does the attached patch help?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
Earthling Michel Dänzer               |               <a href="http://www.amd.com" target="_blank">http://www.amd.com</a><br>
Libre software enthusiast             |             Mesa and X developer<br>
</div></div></blockquote></div><br></div>