Make sure you have the firmware in your initrd if you are using modules, or built into the kernel if you built radeon into the kernel rather than as a module.  See the "Troubleshooting Extra Firmware" section of this page:
http://wiki.x.org/wiki/radeonBuildHowTo

Comparing the initrd of 2.6.37 and 2.6.32 show they are both the same, and neither of them have any firmware in them. They didn't actually have the radeon module at all.

I compared /lib/firmware to the git repository http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git , everything matched (I checked with md5sum) except the newer BARTS/CAICOS/BTC/PALM/SUMO/TURKS firmware which I assume is all later than my card.

I tried to force update-initramfs to include the radeon kernel modules by listing it in /etc/initramfs-tools/modules, but this caused the update-initramfs to hang when loading radeon.ko in.

Rather than try to insert everything manually in my initrd, I blacklisted radeon in /etc/modeprobe.d and modprobe'd it in after a complete boot to a virtual terminal.

On my old kernel, this worked swimmingly (no radeon in lsmod, module loaded nicely). On the debian stock kernel modprobe hangs, I stopped timing after ten minutes, the screen doesn't resize as usual for KMS, lsmod lists radeon/drm/drm_kms_helper. dmesg again shows only RS780 Microcode being loaded.

:/ Sorry, my last paragraph was a little ambigous.

On my old debian 2.6.32 kernel, this worked swimmingly (module loaded nearly instantly, screen resolution jumped up). 
On the debian 2.6.37 kernel modprobe hangs, I stopped timing after ten minutes, the screen doesn't resize as usual for KMS but lsmod lists radeon/drm/drm_kms_helper. dmesg again shows only RS780 Microcode being loaded.

In each case, before starting, I checked with lsmod to make sure radeon was not loaded.



Since my last comment, I also checked Ubuntu 10.10 (2.6.35), and it has graphics issues as well - it is much harder to see what is happening because plymouth gives me a blank screen, but it also has a modprobe timeout, apparently no KMS loading, and firmware seems to be available in /lib/firmware.

(In reply to comment #4)
> [    4.414321] radeon 0000:01:05.0: WB enabled

Does passing the parameter no_wb=1 to the radeon kernel module help?

Alternatively, does disabling the integrated RS780 GPU work around the problem?

> Does passing the parameter no_wb=1 to the radeon kernel module help?

It doesn't seem to help. `dmesg | grep WB` shows it as Disabled, but modprobe still hangs on load at the RS780 firmware.

> Alternatively, does disabling the integrated RS780 GPU work around the problem?

Works. With the RS780 GPU disabled, everything functions.

BIOS -> Advanced Chipset Features -> Surround View -> [Disabled], KMS works, no modprobe hang.

I didn't know that that card could be switched on and off. Thanks :)

Owen, can you bisect?

Just trying a few intermediate versions from http://snapshot.debian.org/ would already be useful.  For narrowing down the regression range beyond that, "git bisect" can help:

 git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 cd linux
 git bisect start -- drivers/gpu/drm/radeon
 git checkout (bad version)
 make localmodconfig; # minimal configuration
 make -j2 deb-pkg
 dpkg -i ../(package).deb
 reboot
 # confirm that it is actually bad
 git bisect bad

 git checkout (good version)
 make silentoldconfig; # reuse configuration
 make -j2 deb-pkg
 dpkg -i ../(package).deb
 reboot
 # confirm that it is good
 git bisect good

 # now it checks out an intermediate version to test
 make silentoldconfig
 make -j2 deb-pkg
 dpkg -i ../(package).deb
 reboot
 git bisect bad; # if it hangs in the same way
 git bisect good; # if it boots correctly
 git bisect skip; # if some other problem makes it hard to test

 ... rinse and repeat ...

 git bisect visualize; # to watch the regression range narrowing
 git bisect log; # to summarize partial results if you get bored

This problem was resolved a couple of kernel updates ago.