[PATCH] build in microcode driver on x86
It doesn't really gain anything from being static, aside from requiring odd udev rules and/or init scripts to load it. Bill ? diff ? kernel-2.6.27 ? linux-2.6.26.tar.bz2 ? linux-2.6.27.tar.bz2 ? patch-2.6.27-rc7-git3.bz2 ? patch-2.6.27-rc7.bz2 ? patch-2.6.28-rc9-git1.bz2 ? patch-2.6.28-rc9.bz2 Index: config-x86-generic === RCS file: /cvs/extras/rpms/kernel/devel/config-x86-generic,v retrieving revision 1.60 diff -u -r1.60 config-x86-generic --- config-x86-generic 13 Jan 2009 21:22:54 - 1.60 +++ config-x86-generic 14 Jan 2009 18:16:20 - @@ -64,7 +64,7 @@ CONFIG_I8K=m CONFIG_SONYPI=m CONFIG_SONYPI_COMPAT=y -CONFIG_MICROCODE=m +CONFIG_MICROCODE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_EDD=m Index: config-x86_64-generic === RCS file: /cvs/extras/rpms/kernel/devel/config-x86_64-generic,v retrieving revision 1.63 diff -u -r1.63 config-x86_64-generic --- config-x86_64-generic 13 Jan 2009 21:22:54 - 1.63 +++ config-x86_64-generic 14 Jan 2009 18:16:20 - @@ -18,7 +18,7 @@ # CONFIG_IA32_AOUT is not set # CONFIG_IOMMU_DEBUG is not set CONFIG_DEBUG_RODATA=y -CONFIG_MICROCODE=m +CONFIG_MICROCODE=y CONFIG_SWIOTLB=y CONFIG_CALGARY_IOMMU=y CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] build in microcode driver on x86
On Wed, Jan 14, 2009 at 01:17:38PM -0500, Bill Nottingham wrote: It doesn't really gain anything from being static, aside from requiring odd udev rules and/or init scripts to load it. We had this discussion yesterday on irc, but I never really got this in my head. It works ok with microcode.dat, but what happens if Intel release an update in /lib/firmware/intel-ucode/$f-$m-$s format ? The driver will do a request_firmware, but if we build the driver in, we'll be in the initrd, where that file won't exist. To make it work, we'll either have to.. - have the firmware in the initramfs or - pretend the request_firmware didn't happen, and have the initscript continue to do the microcode_ctl Which direction are we moving in ? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] build in microcode driver on x86
Dave Jones (da...@redhat.com) said: On Wed, Jan 14, 2009 at 01:17:38PM -0500, Bill Nottingham wrote: It doesn't really gain anything from being static, aside from requiring odd udev rules and/or init scripts to load it. We had this discussion yesterday on irc, but I never really got this in my head. It works ok with microcode.dat, but what happens if Intel release an update in /lib/firmware/intel-ucode/$f-$m-$s format ? The driver will do a request_firmware, but if we build the driver in, we'll be in the initrd, where that file won't exist. To make it work, we'll either have to.. - have the firmware in the initramfs or - pretend the request_firmware didn't happen, and have the initscript continue to do the microcode_ctl Which direction are we moving in ? AIUI, the driver's firmware request will get kicked off again when udev triggers all the normal coldplug events. So, that should be handled OK. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] build in microcode driver on x86
On Wed, 2009-01-14 at 13:49 -0500, Dave Jones wrote: On Wed, Jan 14, 2009 at 01:17:38PM -0500, Bill Nottingham wrote: It doesn't really gain anything from being static, aside from requiring odd udev rules and/or init scripts to load it. We had this discussion yesterday on irc, but I never really got this in my head. It works ok with microcode.dat, but what happens if Intel release an update in /lib/firmware/intel-ucode/$f-$m-$s format ? Just to be clear, by works ok you mean we request_firmware() for f/m/s and get nothing, and then some time later an initscript loads microcode.dat instead. If you actually need the microcode to get out of initramfs, you have already lost, and this move won't change anything. The driver will do a request_firmware, but if we build the driver in, we'll be in the initrd, where that file won't exist. To make it work, we'll either have to.. - have the firmware in the initramfs Do we have any way of querying the kernel for firmware requests it will itself make? I don't think we do, let alone the ability to notice pattern matches like f/m/s. - ajax ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] build in microcode driver on x86
Adam Jackson (a...@redhat.com) said: Do we have any way of querying the kernel for firmware requests it will itself make? I don't think we do, let alone the ability to notice pattern matches like f/m/s. There's the MODULE_FIRMWARE tag, but it obviously doesn't handle runtime-generated firmware names. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] build in microcode driver on x86
On Wed, 14 Jan 2009 13:49:57 -0500, Dave Jones da...@redhat.com wrote: On Wed, Jan 14, 2009 at 01:17:38PM -0500, Bill Nottingham wrote: It doesn't really gain anything from being static, aside from requiring odd udev rules and/or init scripts to load it. The driver will do a request_firmware, but if we build the driver in, we'll be in the initrd, where that file won't exist. To make it work, we'll either have to.. A trick exists to go around it: http://people.redhat.com/zaitcev/linux/linux-2.6.27-204396-5.diff If you recall, libusual has the same problem if it's built in. -- Pete ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
