I take it back, I just checked the 'module versioning' as displayed by a make xconfig, in the 220.127.116.11-per-bfs tree, and it is not enabled. Neither is src checksumming, but everything else is enabled. That is the one I'm running ATM since nothing newer will co-habit with nvidia.
also, when it comes time to load the cpu microcode, it looks only for Intel, and of course does not find it, saying so in the boot log. I did run with the neauvou driver for a couple weeks, but that puppy goes away, forcing a reboot tore-enable it at about 36 hour intervals on average.
The screen image the OS driver gave was excellent, doing a better job on small text rendering than the nvidia driver did, but I was forced back the the dark side by the fact that the neauvou driver doesn't support its being a target for an ssh -Y connection to any of my other machines on this home network.
As for your statement about this kernel supporting amd stuff, if it did, why does the microcode loader go looking only for Intel microcode. I would have expected, since the microcode loader is in /etc/init.d, to have seen something like this:
Apr 8 22:01:03 coyote klogd: microcode: CPU0: patch_level=0x1000065
Apr 8 22:01:04 coyote ifplugd(eth0): client: NETLINK: Packet too small or truncated! 64!=16!=1000
Apr 8 22:01:04 coyote klogd: microcode: CPU0: updated (new patch_level=0x1000083)
Apr 8 22:01:04 coyote klogd: microcode: CPU1: patch_level=0x1000065
Apr 8 22:01:04 coyote klogd: microcode: CPU1: updated (new patch_level=0x1000083)
Apr 8 22:01:04 coyote klogd: microcode: CPU2: patch_level=0x1000065
Apr 8 22:01:04 coyote klogd: microcode: CPU2: updated (new patch_level=0x1000083)
Apr 8 22:01:04 coyote klogd: microcode: CPU3: patch_level=0x1000065
Apr 8 22:01:04 coyote klogd: microcode: CPU3: updated (new patch_level=0x1000083)
Apr 8 22:01:04 coyote klogd: microcode: Microcode Update Driver: v2.00 <email@example.com
>, Peter Oruba
Apr 8 22:01:04 coyote klogd: microcode: Microcode Update Driver: v2.00 removed.
in the 3.2.14 bootlog, but its failure message in 3.2.14 never made it into the bootlog, I just see it going by since I am not using a graphical boot cover.
However, I just nuked the powerpc stuff from that 416 patch and it applied clean, so I have a 3.2.14 under construction.
If that appears successful, I'll reboot to it and see if the nvidia module will build correctly now as I've set it to build only for AMD stuff. I will come back and post once it has been boot tested.
But one final question, where does the dkms system store whether or not it has built a module for this kernel? I ask because my scripts copy the existing kernel stuffs to -old directories and recreate everything in /boot, /lib/modules etc from scratch so there are no left overs to confuse the issue, plus if I screw up, I can nuke the fresh version and undo the renaming of the -old trees and I am perfectly restored. But from past experience, this does not fix nvidia's installer, who thinks it a has already built it for this kernel, and I haven't found a way to force it to retry the build without renaming the kernel src tree and re-installing from scratch. That is understandably a PIMA. But I expect to have to do it again here. ;-)
Thanks & cheers.