Fedora :: Microcode - Boot Process Hangs At Startx Time

Ever since the kernel update to 2.6.34.6-47.fc13.x86_64, my boot process hangs at about startx time. I boot cleanly at runlevel 3 in either this or the previous 2.6.33.8 kernel. If I execute startx from here (in either kernel), the system hangs at the same place. During the early troubleshooting, I read in another thread (250929) about installing xorg-x11-drv-catalyst, which I did using yum. This led to the failure of the 2.6.33 kernel; yum remove did not fix this. I have carefully followed the instructions in the fglrx HOWTO (updated a week ago by Hlingler) as they relate to a PAE kernel (including reinstalling mesa-libGL), and that fixed earlier difficulties. Hence, I felt I needed a new thread.

dmesg tells me
Code:
microcode: CPU0: patch_level=0x2000032
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
Linux video capture interface: v2.00
piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0
microcode: CPU1: patch_level=0x2000032
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: Microcode Update Driver: v2.00 .....

But the program itself reports
Code:
# microcode_ctl -h
This program is for updating the microcode on Intel processors belonging to the IA32 family - PentiumPro upwards (x86-64 included). It depends on the Linux kernel driver. The website urbanmyth.org/microcode (mentioned by yum info microcode_ctl) clearly indicates that Intel has taken over this microcodecode distribution, and suggests that it is no longer valid for AMD processors.

I found a reference to a kernel configuration flag CONFIG_MICROCODE_AMD (as a plausible subsititute for CONFIG_MICROCODE_INTEL) that possibly belongs in a script in /etc/init.d - but the above context leads me to suspect this is not true any more. In any event, those flags are not mentioned anywhere in my init.d scripts - in fact nowhere in the entire /etc tree. My microcode file exists, and is dated March 23. How do I get it installed? Or is this completely unrelated to my hanging boot problem, as suggested by the "platform microcode" line in the dmesg output? If so, where should I be looking?