Softlockup on boot with Cape Verde XT on many kernels

[Federico]

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 at 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 at daenzer.net>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150115/c63a526c/attachment.html>