[Bug 34462] New: 180 second hang on boot, DRM doesn't seem to initialize (firmware issue?)

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Feb 18 14:01:20 PST 2011


https://bugs.freedesktop.org/show_bug.cgi?id=34462

           Summary: 180 second hang on boot, DRM doesn't seem to
                    initialize (firmware issue?)
           Product: DRI
           Version: unspecified
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Radeon
        AssignedTo: dri-devel at lists.freedesktop.org
        ReportedBy: owen.riddy at gmail.com


Created an attachment (id=43540)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=43540)
dmesg from Debian Unstable, fails to load

I have a Radeon 3450 graphics card and have been using Debian Squeeze (linux
2.6.32). The card was/is very well supported by the radeon graphics driver, and
firmware was being properly loaded (Debian splits the firmware into a separate
package from the kernel).

Whenever I compiled a newer vanilla kernel KMS didn't work (starting with
2.6.33, I believe. It was a while ago) and X wouldn't load. Every so often I
tried a different kernel, and the problem remained. On X, the system would
completely hang with a blank screen (I couldn't access any virtual terminals).
I assumed I'd mis-configured my kernel and gave up.

Debian has now upgraded to linux 2.6.37-1 and this image seems to have the same
problem. After upgrading, I get a suspicious 180 second pause when the kernel
"populates /dev", which I now attribute to a bug. I'm getting an error message
about modprobe blocking (in dmesg).

I suspect firmware loading problems:
Wheezy (fails, 2.6.37):
dmesg | grep -C 4 icroc

[    4.325551] [drm] radeon: 256M of VRAM memory ready
[    4.325554] [drm] radeon: 512M of GTT memory ready.
[    4.325619] [drm] radeon: irq initialized.
[    4.325622] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    4.326544] [drm] Loading RS780 Microcode
[    4.329997] input: HDA ATI SB Headphone as
/devices/pci0000:00/0000:00:14.2/sound/card0/input7
[    4.414321] radeon 0000:01:05.0: WB enabled
[    4.446469] [drm] ring test succeeded in 1 usecs
[    4.446595] [drm] radeon: ib pool ready.

Squeeze (works, 2.6.32):
dmesg | grep -C 4 icroc

[    4.616162] [drm] radeon: 256M of VRAM memory ready
[    4.616163] [drm] radeon: 512M of GTT memory ready.
[    4.616204] [drm] radeon: irq initialized.
[    4.616206] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    4.616624] [drm] Loading RS780 Microcode
[    4.616627] platform radeon_cp.0: firmware: requesting radeon/RS780_pfp.bin
[    4.714728] hda_codec: ALC1200: BIOS auto-probing.
[    4.716081] input: HDA Digital PCBeep as
/devices/pci0000:00/0000:00:14.2/input/input6
[    4.809447] platform radeon_cp.0: firmware: requesting radeon/RS780_me.bin
--
[    4.941941] radeon 0000:02:00.0: irq 30 for MSI/MSI-X
[    4.941946] radeon 0000:02:00.0: radeon: using MSI.
[    4.941978] [drm] radeon: irq initialized.
[    4.941980] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    4.942370] [drm] Loading RV620 Microcode
[    4.942372] platform radeon_cp.0: firmware: requesting radeon/RV620_pfp.bin
[    4.982496] platform radeon_cp.0: firmware: requesting radeon/RV620_me.bin
[    4.988086] platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin
[    5.025570] [drm] ring test succeeded in 0 usecs

To be sure I haven't tainted the configuration, the method to get a test
platform was:
* Installed the Squeeze release base system
* Upgrade to Wheezy, rebooted to test KMS (virtual terminal screen resolution
was large, suggesting it worked)
* Upgraded to unstable and reboot, at which point I get the 180 second hang and
modprobe errors, as well as a rather low resolution VT.

lspci and other info can be found on this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613922

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the dri-devel mailing list