Re: [PATCH] build in microcode driver on x86
On Wed, 14 Jan 2009 13:49:57 -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. > 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
Re: [PATCH] build in microcode driver on x86
On Wed, 2009-01-14 at 15:26 -0500, Bill Nottingham wrote: > 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. Hmm. Wrap all firmware in ELF EM_NONE headers, add modinfo sections so we can pattern match? - 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
On Wed, Jan 14, 2009 at 03:24:43PM -0500, Adam Jackson wrote: > 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". sure. > If you actually need the microcode to get out > of initramfs, you have already lost, and this move won't change > anything. We've only ever had one case where an updated microcode was required to boot, and that was on pre-production hardware, so I don't think it's really that critical. 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
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, 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
On Wed, Jan 14, 2009 at 03:20:01PM -0500, Bill Nottingham wrote: > 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. groovy. Should be safe to do then. Given we're always loading this on Intel (and I think AMD), might as well build it 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, 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
[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
