Re: Softlockup on boot with Cape Verde XT on many kernels

[Federico <federicotg@xxxxxxxxx>]

It works.
- I applied the patch (manually),
-  recompiled Ubuntu 14.04's kernel 3.13.0-44-generic AMD64,

- uninstalled Catalyst,

- and removed nomodeset kernel parameter from grub.

Ubuntu says I'm running Gallium 0.4 on AMD CAPE VERDE

sudo lshw -c video
[sudo] password for fede:
  *-display              
       descripción: VGA compatible controller
       producto: Cape Verde XT [Radeon HD 7770/8760 / R7 250X]
       fabricante: Advanced Micro Devices, Inc. [AMD/ATI]
       id físico: 0
       información del bus: pci@0000:01:00.0
       versión: 00
       anchura: 64 bits
       reloj: 33MHz
       capacidades: pm pciexpress msi vga_controller bus_master cap_list rom
       configuración: driver=radeon latency=0
       recursos: irq:50 memoria:d0000000-dfffffff memoria:fde80000-fdebffff ioport:ee00(size=256) memoria:fde00000-fde1ffff

It's working fine AFAIK.
I player a few 1080 videos full screen, played duke nukem3d. Unity desktop seems fine.

Here are some logs in case you want to see anything there.

Xorg.log: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299507/+files/Xorg.0.log

dmesg: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299508/+files/dmesg_working.txt

lspci: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299509/+files/lspci_working.txt

I'd love to see this patch pushed everywhere. :-)

2015-01-15 3:21 GMT-03:00 Michel Dänzer <michel@xxxxxxxxxxx>:

On 15.01.2015 12:53, Federico wrote:
> How about this? It seems at least related.
>
> https://github.com/alterapraxisptyltd/openatom/issues/1
>
> Quote:
> [linux] Infinite loop in pci_get_rom_size()
>
> This is one of those issues that you find when putting supposedly stable
> code through unusual situations. I did expect any function in linux that
> is not part of radeon.ko to not be rock solid. Turns out that's not
> really the case.
>
> If we have a PCIR structure with a zero size length, the loop iterating
> through those structure does not advance. It simply does "image +=
> readw(pds + 16) * 512;", but if that field is zero we're back analyzing
> the same structure on the next loop. The way to get out of this loop is
> to set bit 7 of the type field. That's what 'last_image' does. If that
> bit is not set, with the above, that's an infinite loop.
>
> Luckily, it doesn't crash the kernel, but it hangs any driver that calls
> the function under said circumstances. No more modprobe -r or unbinding.
> Reboot is needed. No idea why a firmware blob here is treated as trusted
> input.

That could indeed explain it, does the attached patch help?

--
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel