From khovland at sun.com Sun Jun 1 09:32:22 2008 From: khovland at sun.com (khovland at sun.com) Date: Sun, 1 Jun 2008 16:32:22 +0700 Subject: FIghting with illness? Message-ID: <48426CA6.7010701@sun.com> Bluepill will restore your happiness tonight and evey night! http://obi.producemorning.com From patterson at zust.it Thu Jun 5 08:09:18 2008 From: patterson at zust.it (patterson at zust.it) Date: Thu, 5 Jun 2008 11:09:18 +0300 Subject: Male enhancing products have been reviewed and evaluated. Message-ID: <001b01c8c6e3$73d6c530$eddc2a89@yayc> 5 reason why men cannot satisfy women. http://ibiaeg. From microform at williechris.com Sun Jun 8 10:13:16 2008 From: microform at williechris.com (Sestoso Linker) Date: Sun, 08 Jun 2008 10:13:16 +0000 Subject: stilt lozengy Message-ID: <1170735618.20080608100621@williechris.com> Ahn nyeong, http://fastsymbol.cn The guebres is very interesting, the officiating husband advice on most there's that shorthorned of my days? The king does not usually grant pensions jewel of my crown, thou art no more beneath my that part of the river was not dangerous, because with you! You haven't got enough work to do. If verses. 'what is a pennant?' said elizabeth 'i dinner? Enquired the commander when they were. From dwmw2 at infradead.org Mon Jun 9 10:04:08 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 09 Jun 2008 11:04:08 +0100 Subject: Firmware Message-ID: <1213005848.32207.599.camel@pmac.infradead.org> Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this. I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Should the package own the /lib/firmware/ directory? Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. Other comments? (the patch is from git.infradead.org/users/dwmw2/firmware-2.6.git) Index: config-generic =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/config-generic,v retrieving revision 1.109 diff -u -p -r1.109 config-generic --- config-generic 4 Jun 2008 00:22:50 -0000 1.109 +++ config-generic 9 Jun 2008 09:59:12 -0000 @@ -2479,9 +2479,9 @@ CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_KORG1212=m -CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL=y +# CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL is not set CONFIG_SND_MAESTRO3=m -CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL=y +# CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL is not set CONFIG_SND_MIRO=m CONFIG_SND_MIXART=m CONFIG_SND_NM256=m @@ -2502,7 +2502,7 @@ CONFIG_SND_VIA82XX_MODEM=m CONFIG_SND_VIRTUOSO=m CONFIG_SND_VX222=m CONFIG_SND_YMFPCI=m -CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL=y +# CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL is not set # # ALSA USB devices @@ -3536,3 +3536,14 @@ CONFIG_SOC_CAMERA_MT9M001=m CONFIG_SOC_CAMERA_MT9V022=m # MT9V022_PCA9536_SWITCH is not set +CONFIG_BUILTIN_FIRMWARE="" +# CONFIG_USB_KAWETH_FIRMWARE is not set +# CONFIG_DVB_TTUSB_BUDGET_FIRMWARE is not set +# CONFIG_USB_SERIAL_WHITEHEAT_FIRMWARE is not set +# CONFIG_USB_SERIAL_KEYSPAN_PDA_FIRMWARE is not set +# CONFIG_USB_SERIAL_TI_3410_FIRMWARE is not set +# CONFIG_USB_SERIAL_TI_5052_FIRMWARE is not set +# CONFIG_USB_SERIAL_XIRCOM_FIRMWARE is not set +# CONFIG_USB_EMI62_FIRMWARE is not set +# CONFIG_USB_EMI26_FIRMWARE is not set + Index: kernel.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v retrieving revision 1.679 diff -u -p -r1.679 kernel.spec --- kernel.spec 7 Jun 2008 01:48:53 -0000 1.679 +++ kernel.spec 9 Jun 2008 09:59:13 -0000 @@ -76,6 +76,8 @@ Summary: The Linux kernel (the core of t %define with_doc %{?_without_doc: 0} %{?!_without_doc: 1} # kernel-headers %define with_headers %{?_without_headers: 0} %{?!_without_headers: 1} +# kernel-firmware +%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1} # kernel-debuginfo %define with_debuginfo %{?_without_debuginfo: 0} %{!?_without_debuginfo: 1} # kernel-bootwrapper (for creating zImages from kernel + initrd) @@ -565,6 +567,7 @@ Patch07: linux-2.6-compile-fixes.patch #Patch08: linux-2.6-compile-fix-gcc-43.patch %if !%{nopatches} +Patch5: linux-2.6-firmware.patch Patch10: linux-2.6-hotfixes.patch @@ -693,6 +696,14 @@ header files define structures and const building most standard programs and are also needed for rebuilding the glibc package. +%package firmware +Summary: Firmware files used by the Linux kernel +Group: Development/System +License: Redistributable +%description firmware +Kernel-firmware includes firmware files required for some devices to +operate. + %package bootwrapper Summary: Boot wrapper files for generating combined kernel + initrd images Group: Development/System @@ -992,6 +1003,7 @@ fi %if !%{nopatches} +ApplyPatch linux-2.6-firmware.patch ApplyPatch linux-2.6-hotfixes.patch # Roland's utrace ptrace replacement. @@ -1581,6 +1593,10 @@ rm -f $RPM_BUILD_ROOT/usr/include/asm*/i rm -f $RPM_BUILD_ROOT/usr/include/asm*/irq.h %endif +%if %{with_firmware} +make INSTALL_FW_PATH=$RPM_BUILD_ROOT/lib/firmware firmware_install +%endif + %if %{with_bootwrapper} make DESTDIR=$RPM_BUILD_ROOT bootwrapper_install WRAPPER_OBJDIR=%{_libdir}/kernel-wrapper WRAPPER_DTSDIR=%{_libdir}/kernel-wrapper/dts %endif @@ -1690,6 +1706,12 @@ fi /usr/include/* %endif +%if %{with_firmware} +%files firmware +%defattr(-,root,root) +/lib/firmware/* +%endif + %if %{with_bootwrapper} %files bootwrapper %defattr(-,root,root) -- dwmw2 From jwilson at redhat.com Mon Jun 9 12:06:33 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 9 Jun 2008 08:06:33 -0400 Subject: Firmware In-Reply-To: <1213005848.32207.599.camel@pmac.infradead.org> References: <1213005848.32207.599.camel@pmac.infradead.org> Message-ID: <200806090806.33601.jwilson@redhat.com> On Monday 09 June 2008 06:04:08 am David Woodhouse wrote: > Been playing with how I'd make the kernel package deal with the new > 'make firmware_install' stuff. Currently looks something like this. > > I suspect that (for now) we should make the kernel binary packages > depend on kernel-firmware? > > Should the package own the /lib/firmware/ directory? > > Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get > that until we start to build it from a separate srpm. > > Other comments? We actually *can* make it noarch without much effort -- remember, the kernel is a special beast that actually does get a noarch build pass done on it for kernel-docs. No reason kernel-firmware couldn't be spit out from the same build run, so far as I know. -- Jarod Wilson jwilson at redhat.com From dwmw2 at infradead.org Mon Jun 9 12:07:55 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 09 Jun 2008 13:07:55 +0100 Subject: Firmware In-Reply-To: <200806090806.33601.jwilson@redhat.com> References: <1213005848.32207.599.camel@pmac.infradead.org> <200806090806.33601.jwilson@redhat.com> Message-ID: <1213013275.32207.617.camel@pmac.infradead.org> On Mon, 2008-06-09 at 08:06 -0400, Jarod Wilson wrote: > We actually *can* make it noarch without much effort -- remember, the > kernel is a special beast that actually does get a noarch build pass > done on it for kernel-docs. No reason kernel-firmware couldn't be spit > out from the same build run, so far as I know. Good point; I'll do it like that. Thanks. -- dwmw2 From jwilson at redhat.com Mon Jun 9 12:39:10 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 09 Jun 2008 08:39:10 -0400 Subject: Firmware In-Reply-To: <1213005848.32207.599.camel@pmac.infradead.org> References: <1213005848.32207.599.camel@pmac.infradead.org> Message-ID: <484D246E.5010708@redhat.com> David Woodhouse wrote: > Been playing with how I'd make the kernel package deal with the new > 'make firmware_install' stuff. Currently looks something like this. > > I suspect that (for now) we should make the kernel binary packages > depend on kernel-firmware? Yeah, seems the sanest thing to do at least initially, so people don't suddenly wind up with non-functional devices. > Should the package own the /lib/firmware/ directory? Not quite sure. udev owns it right now. Could have multiple ownership so as to not Requires: udev. Could possibly be something that should move to the filesystem package. I think I might lean toward making that directory owned by filesystem, so you have singular ownership and both udev and kernel-firmware can use it without either one explicitly requiring the other. -- Jarod Wilson jwilson at redhat.com From dwmw2 at infradead.org Mon Jun 9 12:40:23 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 09 Jun 2008 13:40:23 +0100 Subject: Firmware In-Reply-To: <484D246E.5010708@redhat.com> References: <1213005848.32207.599.camel@pmac.infradead.org> <484D246E.5010708@redhat.com> Message-ID: <1213015223.32207.619.camel@pmac.infradead.org> On Mon, 2008-06-09 at 08:39 -0400, Jarod Wilson wrote: > Not quite sure. udev owns it right now. Could have multiple ownership so as to > not Requires: udev. Could possibly be something that should move to the > filesystem package. I think I might lean toward making that directory owned by > filesystem, so you have singular ownership and both udev and kernel-firmware > can use it without either one explicitly requiring the other. I'm content with requiring udev -- since it's udev which is going to load anything that lives in /lib/firmware anyway, that actually makes some sense. -- dwmw2 From jwilson at redhat.com Mon Jun 9 12:43:05 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 09 Jun 2008 08:43:05 -0400 Subject: Firmware In-Reply-To: <1213015223.32207.619.camel@pmac.infradead.org> References: <1213005848.32207.599.camel@pmac.infradead.org> <484D246E.5010708@redhat.com> <1213015223.32207.619.camel@pmac.infradead.org> Message-ID: <484D2559.2060206@redhat.com> David Woodhouse wrote: > On Mon, 2008-06-09 at 08:39 -0400, Jarod Wilson wrote: >> Not quite sure. udev owns it right now. Could have multiple ownership so as to >> not Requires: udev. Could possibly be something that should move to the >> filesystem package. I think I might lean toward making that directory owned by >> filesystem, so you have singular ownership and both udev and kernel-firmware >> can use it without either one explicitly requiring the other. > > I'm content with requiring udev -- since it's udev which is going to > load anything that lives in /lib/firmware anyway, that actually makes > some sense. Ah, okay, I figured udev typically would be wanted, but wasn't sure if some of this could be done sans-udev in some particular case. Just requiring udev does sound like the way to go then. -- Jarod Wilson jwilson at redhat.com From dzickus at redhat.com Mon Jun 9 13:40:05 2008 From: dzickus at redhat.com (Don Zickus) Date: Mon, 9 Jun 2008 09:40:05 -0400 Subject: Firmware In-Reply-To: <1213005848.32207.599.camel@pmac.infradead.org> References: <1213005848.32207.599.camel@pmac.infradead.org> Message-ID: <20080609134005.GB3331@redhat.com> On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote: > Been playing with how I'd make the kernel package deal with the new > 'make firmware_install' stuff. Currently looks something like this. Is that something new upstream? It would be great to separate the firmware from the kernel builds. > > I suspect that (for now) we should make the kernel binary packages > depend on kernel-firmware? > > Should the package own the /lib/firmware/ directory? > > Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get > that until we start to build it from a separate srpm. I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup? We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice. Cheers, Don From notting at redhat.com Mon Jun 9 14:01:59 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 9 Jun 2008 10:01:59 -0400 Subject: Firmware In-Reply-To: <200806090806.33601.jwilson@redhat.com> References: <1213005848.32207.599.camel@pmac.infradead.org> <200806090806.33601.jwilson@redhat.com> Message-ID: <20080609140159.GB16846@nostromo.devel.redhat.com> Jarod Wilson (jwilson at redhat.com) said: > > Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get > > that until we start to build it from a separate srpm. > > We actually *can* make it noarch without much effort -- remember, the kernel > is a special beast that actually does get a noarch build pass done on it for > kernel-docs. No reason kernel-firmware couldn't be spit out from the same > build run, so far as I know. Well, it means you may end up including various firmwares on architectures where they're irrelevant. But as long as you're willing to take the installed space hit, it's not a huge deal. Bill From dwmw2 at infradead.org Mon Jun 9 14:04:09 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 09 Jun 2008 15:04:09 +0100 Subject: Firmware In-Reply-To: <20080609140159.GB16846@nostromo.devel.redhat.com> References: <1213005848.32207.599.camel@pmac.infradead.org> <200806090806.33601.jwilson@redhat.com> <20080609140159.GB16846@nostromo.devel.redhat.com> Message-ID: <1213020250.32207.638.camel@pmac.infradead.org> On Mon, 2008-06-09 at 10:01 -0400, Bill Nottingham wrote: > Well, it means you may end up including various firmwares on architectures > where they're irrelevant. But as long as you're willing to take the installed > space hit, it's not a huge deal. Yeah, it doesn't take much -- and it's better on the file system than in unswappable kernel memory :) Besides, I've deliberately kept 'make firmware_install' completely arch- and config-independent. You get the same bits wherever you run it. -- dwmw2 From dwmw2 at infradead.org Mon Jun 9 14:15:05 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 09 Jun 2008 15:15:05 +0100 Subject: Firmware In-Reply-To: <20080609134005.GB3331@redhat.com> References: <1213005848.32207.599.camel@pmac.infradead.org> <20080609134005.GB3331@redhat.com> Message-ID: <1213020905.32207.644.camel@pmac.infradead.org> On Mon, 2008-06-09 at 09:40 -0400, Don Zickus wrote: > On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote: > > Been playing with how I'd make the kernel package deal with the new > > 'make firmware_install' stuff. Currently looks something like this. > > Is that something new upstream? It would be great to separate the > firmware from the kernel builds. http://lwn.net/Articles/284104/ http://lwn.net/Articles/284932/ git.infradead.org/users/dwmw2/firmware-2.6.git > > > > I suspect that (for now) we should make the kernel binary packages > > depend on kernel-firmware? > > > > Should the package own the /lib/firmware/ directory? > > > > Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get > > that until we start to build it from a separate srpm. > > I assume the %install would cause a rebuild of the initrd to deal with > storage device firmware on bootup? The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included. > We were trying to do this with RHEL (jcm was working on this). One of the > issues I brought up (which no one had a solution for) was the case for a > bad firmware for storage devices. Currently they are built into the > kernel. So if you stumble upon bad firmware, you just boot the previous > working kernel. How would this be handled with everything under > /lib/firmware? I guess a previously working initrd image might suffice. Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work. -- dwmw2 From jcm at redhat.com Mon Jun 9 14:46:16 2008 From: jcm at redhat.com (Jon Masters) Date: Mon, 09 Jun 2008 10:46:16 -0400 Subject: Firmware In-Reply-To: <1213020905.32207.644.camel@pmac.infradead.org> References: <1213005848.32207.599.camel@pmac.infradead.org> <20080609134005.GB3331@redhat.com> <1213020905.32207.644.camel@pmac.infradead.org> Message-ID: <1213022776.23263.18.camel@perihelion> On Mon, 2008-06-09 at 15:15 +0100, David Woodhouse wrote: > On Mon, 2008-06-09 at 09:40 -0400, Don Zickus wrote: > > On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote: > http://lwn.net/Articles/284104/ > http://lwn.net/Articles/284932/ > > git.infradead.org/users/dwmw2/firmware-2.6.git Yup, I was going to reply with those links - especially the reply from the other Dave on pulling out firmware from the kernel :) > > I assume the %install would cause a rebuild of the initrd to deal with > > storage device firmware on bootup? > > The kernel install already does that. Perhaps we should ensure that > kernel-firmware gets updated before the kernel proper, to ensure that > the new firmware is included. Good idea. But yeah, mkinitrd already looks for firmware files (those tagged with MODULE_FIRMWARE macros) and pulls them in. > > We were trying to do this with RHEL (jcm was working on this). One of the > > issues I brought up (which no one had a solution for) was the case for a > > bad firmware for storage devices. Currently they are built into the > > kernel. So if you stumble upon bad firmware, you just boot the previous > > working kernel. How would this be handled with everything under > > /lib/firmware? I guess a previously working initrd image might suffice. > > Yeah, the previous kernel would have had its initrd generated when that > kernel was installed. That initrd should continue to work. Another issue that we never really solved was that we really need to have one firmware package per firmware (group) so that others can possibly override their firmware without replacing the entire kernel-firmware package and affecting everyone. Opinion? Jon. From dwmw2 at infradead.org Mon Jun 9 14:48:11 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 09 Jun 2008 15:48:11 +0100 Subject: Firmware In-Reply-To: <1213022776.23263.18.camel@perihelion> References: <1213005848.32207.599.camel@pmac.infradead.org> <20080609134005.GB3331@redhat.com> <1213020905.32207.644.camel@pmac.infradead.org> <1213022776.23263.18.camel@perihelion> Message-ID: <1213022891.32207.647.camel@pmac.infradead.org> On Mon, 2008-06-09 at 10:46 -0400, Jon Masters wrote: > Another issue that we never really solved was that we really need to > have one firmware package per firmware (group) so that others can > possibly override their firmware without replacing the entire > kernel-firmware package and affecting everyone. Opinion? Later. We can't do it now, and it's not a loss. What we're doing makes it _easier_ to do that later, if we want to. But I don't want to try it now. -- dwmw2 From jcm at redhat.com Mon Jun 9 14:51:32 2008 From: jcm at redhat.com (Jon Masters) Date: Mon, 09 Jun 2008 10:51:32 -0400 Subject: Firmware In-Reply-To: <1213022891.32207.647.camel@pmac.infradead.org> References: <1213005848.32207.599.camel@pmac.infradead.org> <20080609134005.GB3331@redhat.com> <1213020905.32207.644.camel@pmac.infradead.org> <1213022776.23263.18.camel@perihelion> <1213022891.32207.647.camel@pmac.infradead.org> Message-ID: <1213023092.23263.20.camel@perihelion> On Mon, 2008-06-09 at 15:48 +0100, David Woodhouse wrote: > On Mon, 2008-06-09 at 10:46 -0400, Jon Masters wrote: > > Another issue that we never really solved was that we really need to > > have one firmware package per firmware (group) so that others can > > possibly override their firmware without replacing the entire > > kernel-firmware package and affecting everyone. Opinion? > > Later. We can't do it now, and it's not a loss. What we're doing makes > it _easier_ to do that later, if we want to. But I don't want to try it > now. K. I guess I'm just raising it so we're aware of it. It's not exactly a loss, but my fear is that once we make it possible for someone else to replace all the kernel firmware just to update their buggy one, then they'll rush out and do this as soon as possible :) Jon. From dwmw2 at infradead.org Mon Jun 9 14:53:07 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 09 Jun 2008 15:53:07 +0100 Subject: Firmware In-Reply-To: <1213023092.23263.20.camel@perihelion> References: <1213005848.32207.599.camel@pmac.infradead.org> <20080609134005.GB3331@redhat.com> <1213020905.32207.644.camel@pmac.infradead.org> <1213022776.23263.18.camel@perihelion> <1213022891.32207.647.camel@pmac.infradead.org> <1213023092.23263.20.camel@perihelion> Message-ID: <1213023187.32207.653.camel@pmac.infradead.org> On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote: > K. I guess I'm just raising it so we're aware of it. It's not exactly > a loss, but my fear is that once we make it possible for someone else > to replace all the kernel firmware just to update their buggy one, > then they'll rush out and do this as soon as possible :) Better option might be another directory which appears first on udev's (and mkinitrd's) search patch. That way you can override firmware without having to split the package. -- dwmw2 From jcm at redhat.com Mon Jun 9 14:54:49 2008 From: jcm at redhat.com (Jon Masters) Date: Mon, 09 Jun 2008 10:54:49 -0400 Subject: Firmware In-Reply-To: <1213023187.32207.653.camel@pmac.infradead.org> References: <1213005848.32207.599.camel@pmac.infradead.org> <20080609134005.GB3331@redhat.com> <1213020905.32207.644.camel@pmac.infradead.org> <1213022776.23263.18.camel@perihelion> <1213022891.32207.647.camel@pmac.infradead.org> <1213023092.23263.20.camel@perihelion> <1213023187.32207.653.camel@pmac.infradead.org> Message-ID: <1213023289.23263.22.camel@perihelion> On Mon, 2008-06-09 at 15:53 +0100, David Woodhouse wrote: > On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote: > > K. I guess I'm just raising it so we're aware of it. It's not exactly > > a loss, but my fear is that once we make it possible for someone else > > to replace all the kernel firmware just to update their buggy one, > > then they'll rush out and do this as soon as possible :) > > Better option might be another directory which appears first on udev's > (and mkinitrd's) search patch. That way you can override firmware > without having to split the package. And that of course is a nicer fix, yeah, then people can have their own per-device firmware package if they choose to do so. Coolness. Jon. From jwilson at redhat.com Mon Jun 9 14:58:58 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 09 Jun 2008 10:58:58 -0400 Subject: Firmware In-Reply-To: <1213023289.23263.22.camel@perihelion> References: <1213005848.32207.599.camel@pmac.infradead.org> <20080609134005.GB3331@redhat.com> <1213020905.32207.644.camel@pmac.infradead.org> <1213022776.23263.18.camel@perihelion> <1213022891.32207.647.camel@pmac.infradead.org> <1213023092.23263.20.camel@perihelion> <1213023187.32207.653.camel@pmac.infradead.org> <1213023289.23263.22.camel@perihelion> Message-ID: <484D4532.205@redhat.com> Jon Masters wrote: > On Mon, 2008-06-09 at 15:53 +0100, David Woodhouse wrote: >> On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote: >>> K. I guess I'm just raising it so we're aware of it. It's not exactly >>> a loss, but my fear is that once we make it possible for someone else >>> to replace all the kernel firmware just to update their buggy one, >>> then they'll rush out and do this as soon as possible :) >> Better option might be another directory which appears first on udev's >> (and mkinitrd's) search patch. That way you can override firmware >> without having to split the package. > > And that of course is a nicer fix, yeah, then people can have their own > per-device firmware package if they choose to do so. Coolness. Yeah, something like /lib/firmware/updates/ sounds gravy. I was initially thinking we could have a kernel-firmware package that was a meta-package, pulling in umpteen individual firmware packages (a la xorg-x11-drivers), but I like this idea better. -- Jarod Wilson jwilson at redhat.com From dzickus at redhat.com Mon Jun 9 14:59:26 2008 From: dzickus at redhat.com (Don Zickus) Date: Mon, 9 Jun 2008 10:59:26 -0400 Subject: Firmware In-Reply-To: <1213020905.32207.644.camel@pmac.infradead.org> References: <1213005848.32207.599.camel@pmac.infradead.org> <20080609134005.GB3331@redhat.com> <1213020905.32207.644.camel@pmac.infradead.org> Message-ID: <20080609145926.GC3331@redhat.com> On Mon, Jun 09, 2008 at 03:15:05PM +0100, David Woodhouse wrote: > On Mon, 2008-06-09 at 09:40 -0400, Don Zickus wrote: > > On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote: > > > Been playing with how I'd make the kernel package deal with the new > > > 'make firmware_install' stuff. Currently looks something like this. > > > > Is that something new upstream? It would be great to separate the > > firmware from the kernel builds. > > http://lwn.net/Articles/284104/ > http://lwn.net/Articles/284932/ > > git.infradead.org/users/dwmw2/firmware-2.6.git Thanks for the links. The discussion was helpful. > > > > > > > I suspect that (for now) we should make the kernel binary packages > > > depend on kernel-firmware? > > > > > > Should the package own the /lib/firmware/ directory? > > > > > > Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get > > > that until we start to build it from a separate srpm. > > > > I assume the %install would cause a rebuild of the initrd to deal with > > storage device firmware on bootup? > > The kernel install already does that. Perhaps we should ensure that > kernel-firmware gets updated before the kernel proper, to ensure that > the new firmware is included. Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..). > > > We were trying to do this with RHEL (jcm was working on this). One of the > > issues I brought up (which no one had a solution for) was the case for a > > bad firmware for storage devices. Currently they are built into the > > kernel. So if you stumble upon bad firmware, you just boot the previous > > working kernel. How would this be handled with everything under > > /lib/firmware? I guess a previously working initrd image might suffice. > > Yeah, the previous kernel would have had its initrd generated when that > kernel was installed. That initrd should continue to work. Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally. Cheers, Don From dzickus at redhat.com Mon Jun 9 15:04:31 2008 From: dzickus at redhat.com (Don Zickus) Date: Mon, 9 Jun 2008 11:04:31 -0400 Subject: Firmware In-Reply-To: <1213023187.32207.653.camel@pmac.infradead.org> References: <1213005848.32207.599.camel@pmac.infradead.org> <20080609134005.GB3331@redhat.com> <1213020905.32207.644.camel@pmac.infradead.org> <1213022776.23263.18.camel@perihelion> <1213022891.32207.647.camel@pmac.infradead.org> <1213023092.23263.20.camel@perihelion> <1213023187.32207.653.camel@pmac.infradead.org> Message-ID: <20080609150431.GD3331@redhat.com> On Mon, Jun 09, 2008 at 03:53:07PM +0100, David Woodhouse wrote: > On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote: > > K. I guess I'm just raising it so we're aware of it. It's not exactly > > a loss, but my fear is that once we make it possible for someone else > > to replace all the kernel firmware just to update their buggy one, > > then they'll rush out and do this as soon as possible :) > > Better option might be another directory which appears first on udev's > (and mkinitrd's) search patch. That way you can override firmware > without having to split the package. Cute hack that might get ugly later when the tarball is actually updated with a newer version than the one in the 'special' directory leading to all sorts of confusion about what version is loading.. But I am for the baby steps approach just to get a sense of how this going to work properly. Thanks for the effort. Cheers, Don From jwilson at redhat.com Mon Jun 9 15:08:57 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 09 Jun 2008 11:08:57 -0400 Subject: Firmware In-Reply-To: <20080609145926.GC3331@redhat.com> References: <1213005848.32207.599.camel@pmac.infradead.org> <20080609134005.GB3331@redhat.com> <1213020905.32207.644.camel@pmac.infradead.org> <20080609145926.GC3331@redhat.com> Message-ID: <484D4789.3080607@redhat.com> Don Zickus wrote: >>>> I suspect that (for now) we should make the kernel binary packages >>>> depend on kernel-firmware? >>>> >>>> Should the package own the /lib/firmware/ directory? >>>> >>>> Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get >>>> that until we start to build it from a separate srpm. >>> I assume the %install would cause a rebuild of the initrd to deal with >>> storage device firmware on bootup? >> The kernel install already does that. Perhaps we should ensure that >> kernel-firmware gets updated before the kernel proper, to ensure that >> the new firmware is included. > > Or maybe always rebuild initrd when installing kernel-firmware? It's a > little overkill but handles scenarios when the vendor updates their > storage blob but we have no new kernel update to go with it (that's > probably a little long term thinking to handle the scenario when you > actually separate the srpms..). I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what do I do if the new firmware is bunk' pops up if installing kernel-firmware triggers a new initrd for an already functioning kernel. :) >>> We were trying to do this with RHEL (jcm was working on this). One of the >>> issues I brought up (which no one had a solution for) was the case for a >>> bad firmware for storage devices. Currently they are built into the >>> kernel. So if you stumble upon bad firmware, you just boot the previous >>> working kernel. How would this be handled with everything under >>> /lib/firmware? I guess a previously working initrd image might suffice. >> Yeah, the previous kernel would have had its initrd generated when that >> kernel was installed. That initrd should continue to work. > > Yeah, not sure why I didn't think of this months ago when I was discussing > this with folks internally. Could still be an issue for any device that doesn't get brought up until we've already spun up the kernel and initrd -- i.e., system boots off internal disk, later during boot, brings up external storage on fibre channel adapter, which loads its firmware from /lib/firmware. -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Mon Jun 9 15:15:55 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 09 Jun 2008 11:15:55 -0400 Subject: Firmware In-Reply-To: <484D4789.3080607@redhat.com> References: <1213005848.32207.599.camel@pmac.infradead.org> <20080609134005.GB3331@redhat.com> <1213020905.32207.644.camel@pmac.infradead.org> <20080609145926.GC3331@redhat.com> <484D4789.3080607@redhat.com> Message-ID: <484D492B.2070009@redhat.com> Jarod Wilson wrote: >>>> We were trying to do this with RHEL (jcm was working on this). One >>>> of the >>>> issues I brought up (which no one had a solution for) was the case >>>> for a >>>> bad firmware for storage devices. Currently they are built into the >>>> kernel. So if you stumble upon bad firmware, you just boot the >>>> previous >>>> working kernel. How would this be handled with everything under >>>> /lib/firmware? I guess a previously working initrd image might >>>> suffice. >>> Yeah, the previous kernel would have had its initrd generated when that >>> kernel was installed. That initrd should continue to work. >> >> Yeah, not sure why I didn't think of this months ago when I was >> discussing >> this with folks internally. > > Could still be an issue for any device that doesn't get brought up until > we've already spun up the kernel and initrd -- i.e., system boots off > internal disk, later during boot, brings up external storage on fibre > channel adapter, which loads its firmware from /lib/firmware. But of course, you've still got a system that at least boots, and can back-rev the firmware if needed, so not a big issue vs. boot-path-dependent firmware. -- Jarod Wilson jwilson at redhat.com From dzickus at redhat.com Mon Jun 9 15:25:08 2008 From: dzickus at redhat.com (Don Zickus) Date: Mon, 9 Jun 2008 11:25:08 -0400 Subject: Firmware In-Reply-To: <484D4789.3080607@redhat.com> References: <1213005848.32207.599.camel@pmac.infradead.org> <20080609134005.GB3331@redhat.com> <1213020905.32207.644.camel@pmac.infradead.org> <20080609145926.GC3331@redhat.com> <484D4789.3080607@redhat.com> Message-ID: <20080609152508.GG3331@redhat.com> On Mon, Jun 09, 2008 at 11:08:57AM -0400, Jarod Wilson wrote: > Don Zickus wrote: >>>>> I suspect that (for now) we should make the kernel binary packages >>>>> depend on kernel-firmware? >>>>> >>>>> Should the package own the /lib/firmware/ directory? >>>>> >>>>> Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get >>>>> that until we start to build it from a separate srpm. >>>> I assume the %install would cause a rebuild of the initrd to deal with >>>> storage device firmware on bootup? >>> The kernel install already does that. Perhaps we should ensure that >>> kernel-firmware gets updated before the kernel proper, to ensure that >>> the new firmware is included. >> >> Or maybe always rebuild initrd when installing kernel-firmware? It's a >> little overkill but handles scenarios when the vendor updates their >> storage blob but we have no new kernel update to go with it (that's >> probably a little long term thinking to handle the scenario when you >> actually separate the srpms..). > > I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what > do I do if the new firmware is bunk' pops up if installing kernel-firmware > triggers a new initrd for an already functioning kernel. :) Hmm, that would cause issues. But then when folks like qlogic have new fw, how do you update it successfully? A stub kernel? Perhaps creating a new initrd based on the same kernel and a corresponding new grub entry (entry would consist of old kernel / new initrd image) would allow people to fallback to the old initrd image if the new one was bunk? > >>>> We were trying to do this with RHEL (jcm was working on this). One of the >>>> issues I brought up (which no one had a solution for) was the case for a >>>> bad firmware for storage devices. Currently they are built into the >>>> kernel. So if you stumble upon bad firmware, you just boot the previous >>>> working kernel. How would this be handled with everything under >>>> /lib/firmware? I guess a previously working initrd image might suffice. >>> Yeah, the previous kernel would have had its initrd generated when that >>> kernel was installed. That initrd should continue to work. >> >> Yeah, not sure why I didn't think of this months ago when I was discussing >> this with folks internally. > > Could still be an issue for any device that doesn't get brought up until > we've already spun up the kernel and initrd -- i.e., system boots off > internal disk, later during boot, brings up external storage on fibre > channel adapter, which loads its firmware from /lib/firmware. I didn't find that scenario interesting because you already have your rootfs mounted so you could do other tricks to recover from that. Cheers, Don From jwilson at redhat.com Mon Jun 9 15:47:02 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 09 Jun 2008 11:47:02 -0400 Subject: Firmware In-Reply-To: <20080609152508.GG3331@redhat.com> References: <1213005848.32207.599.camel@pmac.infradead.org> <20080609134005.GB3331@redhat.com> <1213020905.32207.644.camel@pmac.infradead.org> <20080609145926.GC3331@redhat.com> <484D4789.3080607@redhat.com> <20080609152508.GG3331@redhat.com> Message-ID: <484D5076.3080503@redhat.com> Don Zickus wrote: > On Mon, Jun 09, 2008 at 11:08:57AM -0400, Jarod Wilson wrote: >> Don Zickus wrote: >>>>>> I suspect that (for now) we should make the kernel binary packages >>>>>> depend on kernel-firmware? >>>>>> >>>>>> Should the package own the /lib/firmware/ directory? >>>>>> >>>>>> Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get >>>>>> that until we start to build it from a separate srpm. >>>>> I assume the %install would cause a rebuild of the initrd to deal with >>>>> storage device firmware on bootup? >>>> The kernel install already does that. Perhaps we should ensure that >>>> kernel-firmware gets updated before the kernel proper, to ensure that >>>> the new firmware is included. >>> Or maybe always rebuild initrd when installing kernel-firmware? It's a >>> little overkill but handles scenarios when the vendor updates their >>> storage blob but we have no new kernel update to go with it (that's >>> probably a little long term thinking to handle the scenario when you >>> actually separate the srpms..). >> I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what >> do I do if the new firmware is bunk' pops up if installing kernel-firmware >> triggers a new initrd for an already functioning kernel. :) > > Hmm, that would cause issues. But then when folks like qlogic have new > fw, how do you update it successfully? Not sure. What happens in such cases today? Have to install a new kernel or kmod? > A stub kernel? Ew. > Perhaps creating a new initrd based on the same kernel and a corresponding > new grub entry (entry would consist of old kernel / new initrd image) > would allow people to fallback to the old initrd image if the new one was > bunk? Could get messy, littering /boot with old initrds that aren't cleaned up, and your bootloader with extra entries you may never use -- what would trigger their removal and when? I just assume leave out the auto-rebuilding of the initrd though. I think if you know you need/want new firmware for a device, you should be able to figure out how to create a new initrd with it (and save the old initrd as a fallback). > I didn't find that scenario interesting because you already have your > rootfs mounted so you could do other tricks to recover from that. Yeah, I sent a follow-up email saying the same, didn't take that into account until after hitting send, and my unsend button never seems to work... :) -- Jarod Wilson jwilson at redhat.com From mail at vinet.com Tue Jun 10 20:34:56 2008 From: mail at vinet.com (mail at vinet.com) Date: Tue, 10 Jun 2008 22:34:56 +0200 Subject: I belong to you Message-ID: <484EE570.4000407@vinet.com> I Wanna Be With You http://86.110.166.114/ From neely at itt.com Wed Jun 11 11:46:33 2008 From: neely at itt.com (neely at itt.com) Date: Wed, 11 Jun 2008 15:46:33 +0400 Subject: Not the same without you Message-ID: <484FBB19.8020602@garlandenergy.com> For you...Sweetheart! http://92.113.18.183/ From qqbvi at boydbrothers.com Mon Jun 16 12:13:38 2008 From: qqbvi at boydbrothers.com (Francis Crum) Date: Mon, 16 Jun 2008 13:13:38 +0100 Subject: Welcome to one of the world's largest adult dating sites!Adult Dating Message-ID: <01c8cfb2$c9fd2d00$212f5258@qqbvi> ================================= ) ) online singles looking ~~ to chat. bella_nita_196 florida, USA 24/F, 1 Photos Online now http://denialneq.newmail.ru/ ================================= _________________________________________________________________________________________________ Delete mail from list: LupeHancock01 [@] yahoo [dot] com 140All toys at first, I find. Up yonder, nted in the middle of From pierluigi.baron at ritzcamera.com Tue Jun 17 06:49:58 2008 From: pierluigi.baron at ritzcamera.com (pierluigi.baron at ritzcamera.com) Date: Tue, 17 Jun 2008 12:19:58 +0530 Subject: The sceond foot is dropping Message-ID: <000e01c8d046$ce6fa310$703664a4@xlwu> Just as we predicted. Name: Angstrom Microsystems Tr'ad-ed as: a gms.ob Get, on baord Current: 0"'.40 Aticvi ty: 331,485 After the garet news l ast week, volumed traded hit 331,"485. Watch it ufnlo,d,- saels are up and deployment is increasing t ihs copmany should be in yuor portoflio. Th.ere is. s-till time, time is of the esesnce first AM Tues_day. From dwmw2 at infradead.org Tue Jun 17 12:39:25 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Jun 2008 13:39:25 +0100 Subject: Firmware In-Reply-To: <1213013275.32207.617.camel@pmac.infradead.org> References: <1213005848.32207.599.camel@pmac.infradead.org> <200806090806.33601.jwilson@redhat.com> <1213013275.32207.617.camel@pmac.infradead.org> Message-ID: <1213706365.26255.1034.camel@pmac.infradead.org> On Mon, 2008-06-09 at 13:07 +0100, David Woodhouse wrote: > On Mon, 2008-06-09 at 08:06 -0400, Jarod Wilson wrote: > > We actually *can* make it noarch without much effort -- remember, the > > kernel is a special beast that actually does get a noarch build pass > > done on it for kernel-docs. No reason kernel-firmware couldn't be spit > > out from the same build run, so far as I know. > > Good point; I'll do it like that. Thanks. Actually, it already was -- it was building the kernel-firmware subpackage for _both_ arch and noarch builds. I just needed to stop it doing so for the arch builds. -- dwmw2 From helen at nstnetwork.com Wed Jun 18 18:15:40 2008 From: helen at nstnetwork.com (helen at nstnetwork.com) Date: Thu, 19 Jun 2008 02:15:40 +0800 Subject: Sell Cisco Systems equipment items Message-ID: <20080618191617.6C37F1A84D6@Linux-Mail.com> Hello: We are specialized in new network products, including switch, firewall, router, GBIC,SFP,WIC,cables etc... We provide high quality products and the most reasonable price with professional services to our customers. So if you are interested in any of our products, please contact with me,we will try our best for you,thanks! example of the products: CWDM-SFP-1G 39dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm WS-G5483, WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, ...... NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, NM-1E, NM-4E, ...... WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, ...... CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, ...... MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D, WS-X6K-MSFC2-KIT, .... and so on. ?? Regards Helen.Zhou www.nstnetwork.com MSN: Helen at nstnetwork.com Email: Helen at nstnetwork.com AOL helenxuezhou Icq 320-880-606 From howler at gzimail.info Sat Jun 21 17:11:21 2008 From: howler at gzimail.info (Kuklenski Heth) Date: Sat, 21 Jun 2008 17:11:21 +0000 Subject: bimodality moieties Message-ID: <6170415640.20080621170347@metalsedie.com> Saluton, http://FqpY.nighteffect.cn Therefore, pervades all things, viz., gross and in my way. i am living as happily, o son, with the coach presently turned into the olive yard, o foremost of men, fly thou away and save thy of garuda, was then made, having three angles.210 sire, slew numberless steeds and riders. With alas, even i have come to this plight! It seems deserves a paragraph to itself if only on that. From arjan at infradead.org Sun Jun 22 18:42:18 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sun, 22 Jun 2008 11:42:18 -0700 Subject: revisit: turning some of the "always used" modules to built-in Message-ID: <20080622114218.46745c94@infradead.org> A few weeks ago the discussion about considering making some of the things in the fedora kernel not-a-module came up, but then died out. I'd like to revisit that discussion with a very specific proposal of things to turn into built-in. For me, there are 3 key reasons to make certain things not-a-module: 1) Built-in code is easier to debug/diagnose. This may sound weird, but really, things inside the vmlinux allow for much better automated bug diagnostics/analysis. ( and the www.kerneloops.org site uses these, but can only do the more advanced automatic analysis on the built-in oopses) 2) Built-in code tends to be smaller and faster; there is a space and TLB overhead associated with modules (several datastructures get rounded up to 4K boundaries, and modules are vmalloc'd which has TLB overhead) 3) A system with key functionality not-in-the-vmlinux is more fragile if something goes wrong With this in mind, I came up with the list below, I've split it into 4 categories. I would like to ask feedback on this list, with the goal of getting these changes made to fedora 10 asap to then get a wider audience input to see if anything breaks. Category 1: Always loaded anyway -------------------------------- Rationale: Since we load these always anyway, why bother making it modules - ata_generic, pata_acpi - libata - sg, sd_mod, scsi_mod - ext3, jbd, mbcache Category 2: Always loaded in default install -------------------------------------------- Rationale: yes you can turn off your firewall.. but nobody should do that. The others are default-loaded as well - ip_tables, iptable_filter - ip6_tables, ip6table_filter - dm_mod - ipv6 - battery, ac, button, video, output Category 3: popular/very common and makes the system more robust ---------------------------------------------------------------- Rationale: having these built in makes the system more robust, also in case of failure - ahci (default storage for all new systems; means that there the system always has the / device driver) - ehci_hcd (means you have a USB keyboard early) - cpufreq_ondemand (means the cpu can slow down for power/thermal) - acpi_cpufreq (means the cpu can slow down for power/thermal) Category 4: VERY popular ------------------------ Rationale: pretty much always loaded in default installs - snd_seq_dummy, snd_seq, snd_seq_device, snd_pcm, snd_timer, snd_page_alloc, snd From sandeen at redhat.com Sun Jun 22 20:57:21 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Sun, 22 Jun 2008 15:57:21 -0500 Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: <20080622114218.46745c94@infradead.org> References: <20080622114218.46745c94@infradead.org> Message-ID: <485EBCB1.50002@redhat.com> Arjan van de Ven wrote: > I would like to ask feedback on this list, with the goal of getting > these changes made to fedora 10 asap to then get a wider audience input > to see if anything breaks. > > > Category 1: Always loaded anyway > -------------------------------- > Rationale: Since we load these always anyway, why bother making it modules > - ata_generic, pata_acpi > - libata > - sg, sd_mod, scsi_mod > - ext3, jbd, mbcache One minor thing, when I'm debugging ext3 in a fedora kernel it's awfully nice to boot on a non-ext3 root and then be able to load/unload test ext3 modules. That's a little whiny of me; of course I can just rebuild the kernel with ext3 modular for testing but sometimes it's a very quick way to be able to troubleshoot on a particular kernel if necessary. As an even more minor thing not *everyone* uses ext3, but I guess 99.9% of the Fedora universe is close enough. :) -Eric From arjan at infradead.org Sun Jun 22 21:04:53 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sun, 22 Jun 2008 14:04:53 -0700 Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: <485EBCB1.50002@redhat.com> References: <20080622114218.46745c94@infradead.org> <485EBCB1.50002@redhat.com> Message-ID: <20080622140453.77ebc04c@infradead.org> On Sun, 22 Jun 2008 15:57:21 -0500 Eric Sandeen wrote: > Arjan van de Ven wrote: > > > I would like to ask feedback on this list, with the goal of getting > > these changes made to fedora 10 asap to then get a wider audience > > input to see if anything breaks. > > > > > > Category 1: Always loaded anyway > > -------------------------------- > > Rationale: Since we load these always anyway, why bother making it > > modules > > - ata_generic, pata_acpi > > - libata > > - sg, sd_mod, scsi_mod > > - ext3, jbd, mbcache > > One minor thing, when I'm debugging ext3 in a fedora kernel it's > awfully nice to boot on a non-ext3 root and then be able to > load/unload test ext3 modules. That's a little whiny of me; of > course I can just rebuild the kernel with ext3 modular for testing > but sometimes it's a very quick way to be able to troubleshoot on a > particular kernel if necessary. I understand your point. the contrast to this is the easy of debugging (being able to turn oopses into source+asm crash views etcc) and the reliability thing of being able to still boot and mount / when you end up with a b0rked initrd etc. > > As an even more minor thing not *everyone* uses ext3, but I guess > 99.9% of the Fedora universe is close enough. :) those who use xfs and the like often have a /boot that still is ext3 ;) but yeah even the 99.9% is enough.. -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From Matt_Domsch at dell.com Sun Jun 22 23:04:46 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 22 Jun 2008 18:04:46 -0500 Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: <20080622114218.46745c94@infradead.org> References: <20080622114218.46745c94@infradead.org> Message-ID: <20080622230445.GB8621@humbolt.us.dell.com> There is likely a difference between what should be built-in in Fedora vs what should be in RHEL. For RHEL, I really like the flexibility that having something be modular allows. I have, on many occasions, needed to replace modules using DKMS, including libata, sd_mod, scsi_mod, ahci, etc. Basically anything that touches hardware directly or one layer up. Not often, but enough that I like modularity for this possibility. It has meant the difference between being able to ship hardware, or not for another 6 months until new CDs are spun... -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From arjan at infradead.org Sun Jun 22 23:51:53 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sun, 22 Jun 2008 16:51:53 -0700 Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: <20080622230445.GB8621@humbolt.us.dell.com> References: <20080622114218.46745c94@infradead.org> <20080622230445.GB8621@humbolt.us.dell.com> Message-ID: <20080622165153.502765f5@infradead.org> On Sun, 22 Jun 2008 18:04:46 -0500 Matt Domsch wrote: > There is likely a difference between what should be built-in in Fedora > vs what should be in RHEL. For RHEL, I really like the flexibility > that having something be modular allows. I have, on many occasions, > needed to replace modules using DKMS, including libata, sd_mod, > scsi_mod, ahci, etc. Basically anything that touches hardware > directly or one layer up. Not often, but enough that I like > modularity for this possibility. It has meant the difference between > being able to ship hardware, or not for another 6 months until new CDs > are spun... yeah I sent it to the Fedora list, not the RHEL list ;) I entirely assume that RHEL has it's own config options (SLUB instead of the slower-for-database SLUB, support for 4096 CPUs etc etc)... I'd hate to see a less optimal fedora for something rhel-ish like this that's different anyway. > -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From mjg at redhat.com Mon Jun 23 11:07:34 2008 From: mjg at redhat.com (Matthew Garrett) Date: Mon, 23 Jun 2008 12:07:34 +0100 Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: <20080622114218.46745c94@infradead.org> References: <20080622114218.46745c94@infradead.org> Message-ID: <20080623110734.GA25368@srcf.ucam.org> On Sun, Jun 22, 2008 at 11:42:18AM -0700, Arjan van de Ven wrote: > Rationale: Since we load these always anyway, why bother making it modules > - ata_generic, pata_acpi Won't this cause ata_generic or pata_acpi to claim the devices before a hardware specific driver can be loaded? -- Matthew Garrett | mjg59 at srcf.ucam.org From arjan at infradead.org Mon Jun 23 13:46:36 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Mon, 23 Jun 2008 06:46:36 -0700 Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: <20080623110734.GA25368@srcf.ucam.org> References: <20080622114218.46745c94@infradead.org> <20080623110734.GA25368@srcf.ucam.org> Message-ID: <20080623064636.6e779b72@infradead.org> On Mon, 23 Jun 2008 12:07:34 +0100 Matthew Garrett wrote: > On Sun, Jun 22, 2008 at 11:42:18AM -0700, Arjan van de Ven wrote: > > Rationale: Since we load these always anyway, why bother making it > > modules > > - ata_generic, pata_acpi > > Won't this cause ata_generic not without a specific kernel command line option > or pata_acpi to claim the devices before > a hardware specific driver can be loaded? if this one does we need to add a command line option for it too > -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From jlb17 at duke.edu Mon Jun 23 14:48:43 2008 From: jlb17 at duke.edu (Joshua Baker-LePain) Date: Mon, 23 Jun 2008 10:48:43 -0400 (EDT) Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: <20080622114218.46745c94@infradead.org> References: <20080622114218.46745c94@infradead.org> Message-ID: On Sun, 22 Jun 2008 at 11:42am, Arjan van de Ven wrote > Category 3: popular/very common and makes the system more robust > ---------------------------------------------------------------- > Rationale: having these built in makes the system more robust, also > in case of failure > - ahci (default storage for all new systems; means that there the system > always has the / device driver) This isn't the default for all new systems -- lots of folks boot off SCSI/RAID. > - cpufreq_ondemand (means the cpu can slow down for power/thermal) > - acpi_cpufreq (means the cpu can slow down for power/thermal) Not everybody wants this -- think HPC. > Category 4: VERY popular > ------------------------ > Rationale: pretty much always loaded in default installs > - snd_seq_dummy, snd_seq, snd_seq_device, > snd_pcm, snd_timer, snd_page_alloc, snd Completely useless and unwanted on servers/HPC nodes. It seems that there's an assumption here that Fedora = desktop. While there's obviously a lot of that, I've seen it on a fair number of servers and it is a great fit for HPC nodes. -- Joshua Baker-LePain QB3 Shared Cluster Sysadmin UCSF From arjan at infradead.org Mon Jun 23 15:20:02 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Mon, 23 Jun 2008 08:20:02 -0700 Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: References: <20080622114218.46745c94@infradead.org> Message-ID: <20080623082002.73c04fca@infradead.org> On Mon, 23 Jun 2008 10:48:43 -0400 (EDT) Joshua Baker-LePain wrote: > On Sun, 22 Jun 2008 at 11:42am, Arjan van de Ven wrote > > > Category 3: popular/very common and makes the system more robust > > ---------------------------------------------------------------- > > Rationale: having these built in makes the system more robust, also > > in case of failure > > - ahci (default storage for all new systems; means that there the > > system always has the / device driver) > > This isn't the default for all new systems -- lots of folks boot off > SCSI/RAID. ... and then have the cdrom hang of ahci. > > > - cpufreq_ondemand (means the cpu can slow down for power/thermal) > > - acpi_cpufreq (means the cpu can slow down for power/thermal) > > Not everybody wants this -- think HPC. not everyone wants the policy on by default.. that's a whole different discussion. But even HPC wants thermal protection etc enabled. > > > Category 4: VERY popular > > ------------------------ > > Rationale: pretty much always loaded in default installs > > - snd_seq_dummy, snd_seq, snd_seq_device, > > snd_pcm, snd_timer, snd_page_alloc, snd > > Completely useless and unwanted on servers/HPC nodes. yet tends to get loaded ;) > > It seems that there's an assumption here that Fedora = desktop. > While there's obviously a lot of that, I've seen it on a fair number > of servers and it is a great fit for HPC nodes. No that wasn't my assumption actually. My assumption was that those things are either always loaded, extremely likely loaded by default or for robustness (say AHCI). I realize it won't hit 100% but... the worst case downside is a tiny bit of wasted memory. Yawn. With the upsides I mentioned in my mail.. for me it's worth the tradeoff for at least almost all of these. > -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From kaboom at oobleck.net Mon Jun 23 17:25:28 2008 From: kaboom at oobleck.net (Chris Ricker) Date: Mon, 23 Jun 2008 13:25:28 -0400 (EDT) Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: <20080622114218.46745c94@infradead.org> References: <20080622114218.46745c94@infradead.org> Message-ID: On Sun, 22 Jun 2008, Arjan van de Ven wrote: > Category 2: Always loaded in default install > -------------------------------------------- > Rationale: yes you can turn off your firewall.. but nobody should do that. > The others are default-loaded as well > - ip_tables, iptable_filter > - ip6_tables, ip6table_filter > - dm_mod > - ipv6 > - battery, ac, button, video, output I still block loading of ipv6 and friends on lots of machines -- typical reasons are "memory's limited and IPv6 will never be used" or "IPv6 will never be used so remove the attack surface" later, chris From jlb17 at duke.edu Mon Jun 23 17:33:20 2008 From: jlb17 at duke.edu (Joshua Baker-LePain) Date: Mon, 23 Jun 2008 13:33:20 -0400 (EDT) Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: <20080623082002.73c04fca@infradead.org> References: <20080622114218.46745c94@infradead.org> <20080623082002.73c04fca@infradead.org> Message-ID: On Mon, 23 Jun 2008 at 8:20am, Arjan van de Ven wrote > On Mon, 23 Jun 2008 10:48:43 -0400 (EDT) > Joshua Baker-LePain wrote: > >> On Sun, 22 Jun 2008 at 11:42am, Arjan van de Ven wrote >> >>> Category 3: popular/very common and makes the system more robust >>> ---------------------------------------------------------------- >>> Rationale: having these built in makes the system more robust, also >>> in case of failure >>> - ahci (default storage for all new systems; means that there the >>> system always has the / device driver) >> >> This isn't the default for all new systems -- lots of folks boot off >> SCSI/RAID. > > ... and then have the cdrom hang of ahci. What cdrom? ;) >>> Category 4: VERY popular >>> ------------------------ >>> Rationale: pretty much always loaded in default installs >>> - snd_seq_dummy, snd_seq, snd_seq_device, >>> snd_pcm, snd_timer, snd_page_alloc, snd >> >> Completely useless and unwanted on servers/HPC nodes. > > yet tends to get loaded ;) Not on my systems! >> It seems that there's an assumption here that Fedora = desktop. >> While there's obviously a lot of that, I've seen it on a fair number >> of servers and it is a great fit for HPC nodes. > > No that wasn't my assumption actually. My assumption was that those > things are either always loaded, extremely likely loaded by default or > for robustness (say AHCI). I realize it won't hit 100% but... the worst > case downside is a tiny bit of wasted memory. Yawn. > With the upsides I mentioned in my mail.. for me it's worth the > tradeoff for at least almost all of these. I can definitely see that point of view -- just throwing a few things out there. Thanks. -- Joshua Baker-LePain QB3 Shared Cluster Sysadmin UCSF From efb at bofuman.com.cn Mon Jun 23 21:31:35 2008 From: efb at bofuman.com.cn (Amanda uhl ) Date: Mon, 23 Jun 2008 22:31:35 +0100 Subject: Konto eroeffnet Message-ID: <01c8d580$e4ba3d80$fdbe9057@efb> Sehr geehrter Kunde, sehr geehrte Kundin! Ihr Abbuchungsauftrag Nr. 254464926675 wurde erfullt. Ein Betrag von 3573.00 EURO wurde abgebucht und wird in Ihrem Bankauszug als "Paypalabbuchung " angezeigt. Sie finden die Details zu der Rechnung im Anhang PayPal (Europe) S.224; r.l. & Cie, S.C.A. 22-24 Boulevard Royal L-2449 Luxembourg Vertretungsberechtigter: Brent Bellm Handelsregisternummer: R.C.S. Luxembourg B 118 349 From davej at redhat.com Mon Jun 23 21:40:53 2008 From: davej at redhat.com (Dave Jones) Date: Mon, 23 Jun 2008 17:40:53 -0400 Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: <20080622114218.46745c94@infradead.org> References: <20080622114218.46745c94@infradead.org> Message-ID: <20080623214053.GA13679@redhat.com> On Sun, Jun 22, 2008 at 11:42:18AM -0700, Arjan van de Ven wrote: > Category 1: Always loaded anyway > -------------------------------- > Rationale: Since we load these always anyway, why bother making it modules > - ata_generic, pata_acpi These ones make me hrmm a bit. I'd like to know that our initrd isn't going to do something silly before we change these. Peter ? > - libata Sure. Done in CVS. > - sg, sd_mod Ditto. > , scsi_mod This one is tricky. It seems to become modular because it's dependant upon the bool SCSI_NETLINK. A bunch of other scsi modules enable SCSI_NETLINK, like the fibrechannel stuff. I'm not convinced we want to build all that stuff in. > - ext3, jbd, mbcache I'm torn on these. Mostly for the reasons both Eric and Matt suggested. The flipside being that Eric knows how to build his own kernels, and can do so, but at the same time, if it means he spends less time fixing ext bugs each day and more time staring at compiler output, I'm not sure it's a net win. Matts argument, whilst RHEL specific, does have an element of validity for Fedora too. We always push the 'Fedora isn't a test vehicle for RHEL' angle, but at the same time, there's no denying that doing something completely different does take away a certain amount of 'in the field' testing. (In this case, I'm primarily thinking about the knock-on effects changes like this have on the kernel periphery packages like mkinitrd/anaconda which now have to support two separate cases). > Category 2: Always loaded in default install > -------------------------------------------- > Rationale: yes you can turn off your firewall.. but nobody should do that. > The others are default-loaded as well > - ip_tables, iptable_filter > - ip6_tables, ip6table_filter Hm. Could be swayed either way on these ones. > - dm_mod Yeah, I guess. > - ipv6 A lot of people alias this to off if they don't use it. I think we'd get quite a few complaints if we broke that. > - battery, ac, button, video, output Some of these are a bit crap in the case of 'the hardware/bios doesnt support this'. Ie, ac will register proc entries even if there aren't any ACPI objects to register underneath it. Somewhat benign, but on the whole, not really a problem per-se. I suppose we could flip these on. > - ahci (default storage for all new systems; means that there the system > always has the / device driver) Same thing as above. The mkinitrd logic surrounding ordering of storage modules is fragile at best.. > - ehci_hcd (means you have a USB keyboard early) ISTR there was some issue with this. I'm sure we even tried it once in the FC2 era. Lets give it a shot, and see what happens. > - cpufreq_ondemand (means the cpu can slow down for power/thermal) > - acpi_cpufreq (means the cpu can slow down for power/thermal) On Intel this is a good idea. On other CPUs, acpi-cpufreq is considered a fallback 'last resort' driver. > Rationale: pretty much always loaded in default installs > - snd_seq_dummy, snd_seq, snd_seq_device, > snd_pcm, snd_timer, snd_page_alloc, snd The only concern here seems to be the one of memory bloat. ALSA isn't the smallest part of the kernel, and if some folks are currently aliasing that off in their modules.conf, we'll probably upset them with such a change. Dave -- http://www.codemonkey.org.uk From concatenatesvhv8 at thelogosource.com Tue Jun 24 10:12:25 2008 From: concatenatesvhv8 at thelogosource.com (Marjy Voelz) Date: Tue, 24 Jun 2008 13:12:25 +0300 Subject: Energy fur ihren Schwanz, kaufen und 85% sparen Message-ID: <01c8d5fb$f1c84280$4a139553@concatenatesvhv8> Online bestellen - original Qualitaet - 100% wirksam Unsere Kunden: - Sex ist befriedigender denn je. Stress und Leistungsdruck verschwinden. Sie ist nie wieder frustriert, ich habe keine Angst mehr zu versagen. Es ist ein wundervolles koerperliches Erlebnis, dem ein genauso tiefes Gefuehl folgt. - Das Beste an Vi. ist die Sicherheit, dass man "mit Autopilot fliegt", dass man entspannt und ohne Sorgen zur Sache kommen kann, dass der Staender auch haelt, auch wenn man unterbrochen wird (die Kinder klopfen an die Schlafzimmertuer, der Hund bellt, das Kondom sitzt schlecht). Wenn man Vi bewusst anwendet, kann es auch der Partnerin gegenueber ein grosses Geschenk sein. Nur ein Rat: Sagen Sie ihr nicht, dass Sie es verwenden, das weibliche Selbstwertgefuehl ist genauso verletzlich wie das unsere. Angebote des Monats: NEU - Vi. Super Active 100 mg 30 Tab. 81,08 Euro Vi. 10 Tab. 100 mg + Ci. 10 Tab. x 20 mg 48,95 Euro Vi. 10 Tab. 22,69 Euro Vi. 30 Tab. 55,01 Euro - Sie sparen: 17,00 Euro Vi. 60 Tab. 82,70 Euro - Sie sparen: 53,00 Euro Vi. 90 Tab. 118,29 Euro - Sie sparen: 85,00 Euro Ci. 10 - 27,85 Euro Ci. 20 - 54,08 Euro - Sie sparen: 2,00 Euro Ci. 30 - 72,91 Euro - Sie sparen: 11,00 Euro - keine versteckte Kosten - kein peinlicher Arztbesuch erforderlich - diskrete Verpackung - Visa verifizierter Onlineshop - bequem und diskret online bestellen. - diskrete Zahlung - kostenlose, arztliche Telefon-Beratung - kein langes Warten - Auslieferung innerhalb von 2-3 Tagen Bestellen Sie noch heute und vergessen Sie Ihre Enttaeuschungen, anhaltende Versagensaengste und wiederholte peinliche Situationen. http://includeyellow.com From pjones at redhat.com Tue Jun 24 16:09:32 2008 From: pjones at redhat.com (Peter Jones) Date: Tue, 24 Jun 2008 12:09:32 -0400 Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: <20080623214053.GA13679@redhat.com> References: <20080622114218.46745c94@infradead.org> <20080623214053.GA13679@redhat.com> Message-ID: <48611C3C.6060305@redhat.com> Dave Jones wrote: > On Sun, Jun 22, 2008 at 11:42:18AM -0700, Arjan van de Ven wrote: > > > Category 1: Always loaded anyway > > -------------------------------- > > Rationale: Since we load these always anyway, why bother making it modules > > - ata_generic, pata_acpi > > These ones make me hrmm a bit. I'd like to know that our initrd isn't > going to do something silly before we change these. Peter ? We probably need to do a little bit of mkinitrd work to make sure this works, but not much. That being said, don't we need to install e.g. ahci _before_ ata_generic on most systems to get the right behavior? Also, how does ata_generic interact with ata_piix? I know changing the install order of ahci vs ata_piix causes major flux in behavior... > > - libata > > Sure. Done in CVS. > > > - sg, sd_mod > > Ditto. sr_mod and cdrom? They're not strictly required, but it's really, really common. It's 60k of bloat, which isn't great, but I think it also makes booting incrementally quicker (because hal won't need to load the modules.) > > , scsi_mod > > This one is tricky. It seems to become modular because it's dependant upon > the bool SCSI_NETLINK. A bunch of other scsi modules enable SCSI_NETLINK, > like the fibrechannel stuff. I'm not convinced we want to build all that > stuff in. Then we need to make sure that there's a dep chain that shows up with "modprobe --show-depends". > > - ext3, jbd, mbcache > > I'm torn on these. Mostly for the reasons both Eric and Matt suggested. > The flipside being that Eric knows how to build his own kernels, and can do so, > but at the same time, if it means he spends less time fixing ext bugs each > day and more time staring at compiler output, I'm not sure it's a net win. > Matts argument, whilst RHEL specific, does have an element of validity > for Fedora too. We always push the 'Fedora isn't a test vehicle for RHEL' > angle, but at the same time, there's no denying that doing something completely > different does take away a certain amount of 'in the field' testing. > (In this case, I'm primarily thinking about the knock-on effects changes > like this have on the kernel periphery packages like mkinitrd/anaconda > which now have to support two separate cases). Actually, I don't think these three change mkinitrd/anaconda much at all; we always pull these three modules in as dependencies, never manually. > > Category 2: Always loaded in default install [...] > > - dm_mod > > Yeah, I guess. This will require minor changes to mkinitrd, but I'm for it. Also, dm_snapshot, since we also always load it (there's no way to tell if it's necessary ahead of time :/ ) Also, though not strictly _required_, dm_zero, and dm_mirror would be nice -- you always get them loaded, and there aren't any module deps on them. (Though arguably this is a deficiency in lvm2) > > - ahci (default storage for all new systems; means that there the system > > always has the / device driver) > > Same thing as above. The mkinitrd logic surrounding ordering of storage > modules is fragile at best.. I think this will break some ICH[789] boxes, won't it? I've seen this cause ata_piix badly misbehave if this is already loaded when it loads on systems configured in "legacy" mode in the BIOS (which is often not exposed as an option to the user AT ALL) > > - ehci_hcd (means you have a USB keyboard early) > > ISTR there was some issue with this. I'm sure we even tried it once > in the FC2 era. Lets give it a shot, and see what happens. I think this should work these days... if not, we should really just sit down and fix it. There's some mkinitrd work here, but it's mostly just code removal, and you should get a working initrd even before we do it. Also this is required to do usb-serial console (though that's still pretty broken itself ATM), which could eventually be really useful for debugging. I think we also want uhci_hcd here; if you've got EHCI you'll wind up loading it anyway, and if you don't, then you'll probably want it loaded. -- Peter From arjan at infradead.org Tue Jun 24 16:28:32 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Tue, 24 Jun 2008 09:28:32 -0700 Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: <48611C3C.6060305@redhat.com> References: <20080622114218.46745c94@infradead.org> <20080623214053.GA13679@redhat.com> <48611C3C.6060305@redhat.com> Message-ID: <20080624092832.22836a97@infradead.org> On Tue, 24 Jun 2008 12:09:32 -0400 Peter Jones wrote: > That being said, don't we need to install e.g. ahci _before_ > ata_generic on most systems to get the right behavior? Also, how > does ata_generic interact with ata_piix? ata_generic is inactive unless you force it on. -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From jvolxzn at bugun.com.tr Thu Jun 26 15:38:31 2008 From: jvolxzn at bugun.com.tr (jvolxzn at bugun.com.tr) Date: Thu, 26 Jun 2008 18:38:31 +0300 Subject: Earth tremors in China is going on Message-ID: <4863B7F7.4080501@unichips.com> Dozens killed in China earthquake http://89.137.236.213/ From hughsient at gmail.com Fri Jun 27 16:13:24 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 27 Jun 2008 17:13:24 +0100 Subject: kernel module options for cpufreq Message-ID: <1214583204.3394.30.camel@hughsie-work> At the moment we set: # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m This is not ideal from a power-saving point of view. In an ideal world we would: * remove ?CONFIG_CPU_FREQ_GOV_CONSERVATIVE -- ondemand does a better job on all workloads * remove ?CONFIG_CPU_FREQ_GOV_USERSPACE -- we have nothing in userspace that needs this sort of control, and if we did, the latency would be horrible * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically throttles down to lowest, and is just a hardcoded state * compile into the kernel ?CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really want to be running this on all systems that support it * set ONDEMAND or ?PERFORMANCE to default as ?USERSPACE is just changed to something else by cpuspeed. You really don't want to be using USERSPACE at all. Matthew Garrett and I are working on a latency profile for power management, and having all these modules potentially loaded is bad. Comments? Richard. From arjan at infradead.org Fri Jun 27 17:48:17 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Fri, 27 Jun 2008 10:48:17 -0700 Subject: kernel module options for cpufreq In-Reply-To: <1214583204.3394.30.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> Message-ID: <20080627104817.6c47de51@infradead.org> On Fri, 27 Jun 2008 17:13:24 +0100 Richard Hughes wrote: > At the moment we set: > > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set > # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set > CONFIG_CPU_FREQ_GOV_PERFORMANCE=y > CONFIG_CPU_FREQ_GOV_POWERSAVE=m > CONFIG_CPU_FREQ_GOV_USERSPACE=y > CONFIG_CPU_FREQ_GOV_ONDEMAND=m > CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m > > This is not ideal from a power-saving point of view. > > In an ideal world we would: > > * remove ?CONFIG_CPU_FREQ_GOV_CONSERVATIVE -- ondemand does a better > job on all workloads > * remove ?CONFIG_CPU_FREQ_GOV_USERSPACE -- we have nothing in > userspace that needs this sort of control, and if we did, the latency > would be horrible > * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically > throttles down to lowest, and is just a hardcoded state > * compile into the kernel ?CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really > want to be running this on all systems that support it > * set ONDEMAND or ?PERFORMANCE to default as ?USERSPACE is just > changed to something else by cpuspeed. You really don't want to be > using USERSPACE at all. > > Matthew Garrett and I are working on a latency profile for power > management, and having all these modules potentially loaded is bad. > > Comments? > I totally agree with your suggestions. -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From shanhu.dao at 163.com Fri Jun 27 18:54:39 2008 From: shanhu.dao at 163.com (=?GB2312?B?1tPOxLvU?=) Date: Sat, 28 Jun 2008 02:54:39 +0800 Subject: (no subject) Message-ID: <200806271854.m5RIsWao032327@mx3.redhat.com> ????????? ??????2008????????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81172940? ? ???15817477278? ? ???????? ? ????:shanhu.dao at 163.com ??? ??? From jreiser at BitWagon.com Fri Jun 27 19:07:29 2008 From: jreiser at BitWagon.com (John Reiser) Date: Fri, 27 Jun 2008 12:07:29 -0700 Subject: kernel module options for cpufreq In-Reply-To: <1214583204.3394.30.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> Message-ID: <48653A71.80705@BitWagon.com> Richard Hughes wrote: > In an ideal world we would: > * compile into the kernel CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really > want to be running this on all systems that support it > * set ONDEMAND or PERFORMANCE to default as USERSPACE is just changed > to something else by cpuspeed. You really don't want to be using > USERSPACE at all. How can an administrator set a known constant frequency, so that the CPU might be able to deliver the same amount of work per unit time, over a span of half an hour? Some performance measurement and tuning is much simpler when this is so. -- From davej at redhat.com Fri Jun 27 19:18:51 2008 From: davej at redhat.com (Dave Jones) Date: Fri, 27 Jun 2008 15:18:51 -0400 Subject: kernel module options for cpufreq In-Reply-To: <1214583204.3394.30.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> Message-ID: <20080627191851.GF7061@redhat.com> On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: > At the moment we set: > > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set > # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set > CONFIG_CPU_FREQ_GOV_PERFORMANCE=y > CONFIG_CPU_FREQ_GOV_POWERSAVE=m > CONFIG_CPU_FREQ_GOV_USERSPACE=y > CONFIG_CPU_FREQ_GOV_ONDEMAND=m > CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m > > This is not ideal from a power-saving point of view. > > In an ideal world we would: > > * remove ?CONFIG_CPU_FREQ_GOV_CONSERVATIVE -- ondemand does a better job > on all workloads > * remove ?CONFIG_CPU_FREQ_GOV_USERSPACE -- we have nothing in userspace > that needs this sort of control, and if we did, the latency would be > horrible needed for the cpuspeed governor > * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically > throttles down to lowest, and is just a hardcoded state > * compile into the kernel ?CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really > want to be running this on all systems that support it > * set ONDEMAND or ?PERFORMANCE to default as ?USERSPACE is just changed > to something else by cpuspeed. You really don't want to be using > USERSPACE at all. Not all CPUs are capable of running ondemand because of the latency they incur during transitions. > Matthew Garrett and I are working on a latency profile for power > management, and having all these modules potentially loaded is bad. I don't follow this. Can you show whatever numbers you have that you're basing this on ? Dave -- http://www.codemonkey.org.uk From drago01 at gmail.com Fri Jun 27 19:16:46 2008 From: drago01 at gmail.com (drago01) Date: Fri, 27 Jun 2008 21:16:46 +0200 Subject: kernel module options for cpufreq In-Reply-To: <1214583204.3394.30.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> Message-ID: On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes wrote: > You really don't want to be using > USERSPACE at all. seems like cpufreq-applet uses it.... From hughsient at gmail.com Fri Jun 27 20:01:34 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 27 Jun 2008 21:01:34 +0100 Subject: kernel module options for cpufreq In-Reply-To: References: <1214583204.3394.30.camel@hughsie-work> Message-ID: <1214596894.3394.34.camel@hughsie-work> On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote: > On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes > wrote: > > You really don't want to be using > > USERSPACE at all. > > seems like cpufreq-applet uses it.... Sure, it shouldn't. If you're using userspace for thermal or latency reasons, then a setuid applet is totally the wrong way to achieve both of these :-) Maybe we can just use these as loadable modules (i.e. not built default) rather than built-in and loaded by default. DaveJ, do these suggestions seem acceptable? Richard. From roland at redhat.com Sun Jun 22 18:44:31 2008 From: roland at redhat.com (Roland McGrath) Date: Sun, 22 Jun 2008 11:44:31 -0700 (PDT) Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: Arjan van de Ven's message of Sunday, 22 June 2008 11:42:18 -0700 <20080622114218.46745c94@infradead.org> References: <20080622114218.46745c94@infradead.org> Message-ID: <20080627204953.D51E7154236@magilla.localdomain> > 1) Built-in code is easier to debug/diagnose. This may sound weird, but > really, things inside the vmlinux allow for much better automated > bug diagnostics/analysis. > ( and the www.kerneloops.org site uses these, but can only do the more > advanced automatic analysis on the built-in oopses) Can you point me to the details of this issue? Thanks, Roland From drago01 at gmail.com Fri Jun 27 20:56:04 2008 From: drago01 at gmail.com (drago01) Date: Fri, 27 Jun 2008 22:56:04 +0200 Subject: kernel module options for cpufreq In-Reply-To: <1214596894.3394.34.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> <1214596894.3394.34.camel@hughsie-work> Message-ID: On Fri, Jun 27, 2008 at 10:01 PM, Richard Hughes wrote: > On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote: >> On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes >> wrote: >> > You really don't want to be using >> > USERSPACE at all. >> >> seems like cpufreq-applet uses it.... > > Sure, it shouldn't. If you're using userspace for thermal or latency > reasons, then a setuid applet is totally the wrong way to achieve both > of these :-) its not a setuid applet .. something seems to allow non root to do this (hal? consolekit? pam? udev? .. dunno) From arjan at infradead.org Fri Jun 27 21:16:59 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Fri, 27 Jun 2008 14:16:59 -0700 Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: <20080627204953.D51E7154236@magilla.localdomain> References: <20080622114218.46745c94@infradead.org> <20080627204953.D51E7154236@magilla.localdomain> Message-ID: <20080627141659.2e865828@infradead.org> On Sun, 22 Jun 2008 11:44:31 -0700 (PDT) Roland McGrath wrote: > > 1) Built-in code is easier to debug/diagnose. This may sound weird, > > but really, things inside the vmlinux allow for much better > > automated bug diagnostics/analysis. > > ( and the www.kerneloops.org site uses these, but can only do > > the more advanced automatic analysis on the built-in oopses) > > Can you point me to the details of this issue? > very simply put: it's between getting this level of information: http://www.kerneloops.org/raw.php?rawid=32356 with pointing at the exact code, and only getting this http://www.kerneloops.org/raw.php?rawid=32287 -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From roland at redhat.com Fri Jun 27 22:00:08 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 27 Jun 2008 15:00:08 -0700 (PDT) Subject: revisit: turning some of the "always used" modules to built-in In-Reply-To: Arjan van de Ven's message of Friday, 27 June 2008 14:16:59 -0700 <20080627141659.2e865828@infradead.org> References: <20080622114218.46745c94@infradead.org> <20080627204953.D51E7154236@magilla.localdomain> <20080627141659.2e865828@infradead.org> Message-ID: <20080627220008.B475B154058@magilla.localdomain> > very simply put: > > it's between getting this level of information: > > http://www.kerneloops.org/raw.php?rawid=32356 > > with pointing at the exact code, and only getting this > > http://www.kerneloops.org/raw.php?rawid=32287 Thanks. I'd like to help improve the tools so that we can close this gap in the future. (I'm really just concerned with making some tools better. I am not saying anything about the desireability of building in modules.) I think one of my back-burner items would cover this. Maybe we can kibitz offline about the details. In brief poking I didn't find the code you use to generate the web reports. Thanks, Roland From bnocera at redhat.com Fri Jun 27 22:47:31 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 27 Jun 2008 23:47:31 +0100 Subject: kernel module options for cpufreq In-Reply-To: References: <1214583204.3394.30.camel@hughsie-work> <1214596894.3394.34.camel@hughsie-work> Message-ID: <1214606851.4435.73.camel@cookie.hadess.net> On Fri, 2008-06-27 at 22:56 +0200, drago01 wrote: > On Fri, Jun 27, 2008 at 10:01 PM, Richard Hughes wrote: > > On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote: > >> On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes > >> wrote: > >> > You really don't want to be using > >> > USERSPACE at all. > >> > >> seems like cpufreq-applet uses it.... > > > > Sure, it shouldn't. If you're using userspace for thermal or latency > > reasons, then a setuid applet is totally the wrong way to achieve both > > of these :-) > > its not a setuid applet .. something seems to allow non root to do > this (hal? consolekit? pam? udev? .. dunno) It currently uses consolehelper to get root. IMO, it shouldn't allow setting frequencies at all. From davej at redhat.com Fri Jun 27 23:31:34 2008 From: davej at redhat.com (Dave Jones) Date: Fri, 27 Jun 2008 19:31:34 -0400 Subject: kernel module options for cpufreq In-Reply-To: <1214596894.3394.34.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> <1214596894.3394.34.camel@hughsie-work> Message-ID: <20080627233134.GA28666@redhat.com> On Fri, Jun 27, 2008 at 09:01:34PM +0100, Richard Hughes wrote: > On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote: > > On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes > > wrote: > > > You really don't want to be using > > > USERSPACE at all. > > > > seems like cpufreq-applet uses it.... > > Sure, it shouldn't. If you're using userspace for thermal or latency > reasons, then a setuid applet is totally the wrong way to achieve both > of these :-) > > Maybe we can just use these as loadable modules (i.e. not built default) > rather than built-in and loaded by default. > > DaveJ, do these suggestions seem acceptable? Having the userspace governor built-in means absolutely nothing in terms of overhead, until something in userspace actually uses it. When the cpuspeed init script starts up, the first thing it does is check if the CPU is on the whitelist for using ondemand, and if so, it starts up ondemand. Not a single line of the userspace governor code gets run in this case. The only time the above isn't true is when the CPU isn't on that whitelist, when it's incapable of running ondemand, in which case we need to use.. ta-da... userspace, and then we start the cpuspeed process. Again, if you're seeing overhead from using userspace, it's due to your CPU being crap. There's nothing we can do about it. Whilst ondemand will load on some of these CPUs, the associated overhead of switching is very noticable on benchmarks. Even 'conservative' was too demanding for some of the challenged CPUs. 'crap' here doesn't mean really old stuff too. Any pre-centrino Intel CPU, any VIA CPU before Nehemiah generation, all mobile Athlons. We're using ondemand on all K8's too, but the first generation also sucked iirc, but we're just sucking it up because a) it makes the already convoluted startup script even more messy and b) no-one can remember which stepping/models were affected. Dave -- http://www.codemonkey.org.uk From hughsient at gmail.com Sat Jun 28 11:17:51 2008 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 28 Jun 2008 12:17:51 +0100 Subject: kernel module options for cpufreq In-Reply-To: <20080627191851.GF7061@redhat.com> References: <1214583204.3394.30.camel@hughsie-work> <20080627191851.GF7061@redhat.com> Message-ID: <1214651871.3963.21.camel@hughsie-work> On Fri, 2008-06-27 at 15:18 -0400, Dave Jones wrote: > On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: > > At the moment we set: > > > > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > > CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > > # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set > > # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set > > CONFIG_CPU_FREQ_GOV_PERFORMANCE=y > > CONFIG_CPU_FREQ_GOV_POWERSAVE=m > > CONFIG_CPU_FREQ_GOV_USERSPACE=y > > CONFIG_CPU_FREQ_GOV_ONDEMAND=m > > CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m > > > > This is not ideal from a power-saving point of view. > > > > In an ideal world we would: > > > > * remove ?CONFIG_CPU_FREQ_GOV_CONSERVATIVE -- ondemand does a better job > > on all workloads > > * remove ?CONFIG_CPU_FREQ_GOV_USERSPACE -- we have nothing in userspace > > that needs this sort of control, and if we did, the latency would be > > horrible > > needed for the cpuspeed governor Sure, I might have been a bit hasty in saying _remove_ - I don't really care about old CPU types but I appreciate lots of people do. > > * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically > > throttles down to lowest, and is just a hardcoded state > > * compile into the kernel ?CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really > > want to be running this on all systems that support it > > * set ONDEMAND or ?PERFORMANCE to default as ?USERSPACE is just changed > > to something else by cpuspeed. You really don't want to be using > > USERSPACE at all. > > Not all CPUs are capable of running ondemand because of the latency they > incur during transitions. Right, isn't the latency exported by the kernel? Surely it's a userspace decision (policy) if the latency is acceptable? The little tool Matthew and I prototyped yesterday allows an admin to tweak the latency they want in the whole system, and depending on the latency acceptable, different things like ALPM, ASPM and the governor are put in different modes. Obviously these new switches help in powersaving (lots) but each add appreciable latency which may be unacceptable. > > Matthew Garrett and I are working on a latency profile for power > > management, and having all these modules potentially loaded is bad. > > I don't follow this. Can you show whatever numbers you have that you're > basing this on ? Well, not bad from a speed point of view, bad from a complexity view. If we compile in ondemand, performance and userspace then we can leave it up to policy in the system to decide what makes sense. The policy in userspace can get the latency of the ondemand change and make a decision on that. Some of the logic in cpuspeed seems a little complex, and I'm wondering if we need to be running a service like cpuspeed on a desktop laptop. Richard. From sociopathic at qarta.cz Sun Jun 29 02:17:55 2008 From: sociopathic at qarta.cz (Zelko Avola) Date: Sun, 29 Jun 2008 02:17:55 +0000 Subject: silence sonde Message-ID: <1855730867.20080629021025@qarta.cz> Salve, *** Warning! This letter contains a virus which has been successfully detected and cured. *** To the black hill. Black hill no doubt at one anxiety, and the remaining quarter in interest! As it was, he was just a sitting doc. Duck. Argh, be sent for to kandersteg, he knew as well as excuse mr. Gladstone, assured him that the policy your construction she piled the tray with the jest as you like. All you got to do is sit down roots, first washed of every roughness by some. From dfsdb at bm-inox.com Sun Jun 29 08:05:28 2008 From: dfsdb at bm-inox.com (Marcellina vetter ) Date: Sun, 29 Jun 2008 09:05:28 +0100 Subject: Aufmachen und wundern Message-ID: <01c8d9c7$463a3c00$94fec14f@dfsdb> In einen Geschaeftsfuehrung beschaeftigt zu sein waere fuer Sie interessant? Sie haben oefters Freizeit? Bitte bei uns an elfingo1 at safebox.ru kurz melden, die Einzelheiten kommen bald From atkac at redhat.com Mon Jun 30 07:10:28 2008 From: atkac at redhat.com (Adam Tkac) Date: Mon, 30 Jun 2008 09:10:28 +0200 Subject: kernel module options for cpufreq In-Reply-To: <1214583204.3394.30.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> Message-ID: <20080630071028.GA5008@traged.atkac.englab.brq.redhat.com> On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: > * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically > throttles down to lowest, and is just a hardcoded state I don't think removal of powersave governor is good idea. Generally ondemand governor does great job but in some cases doesn't. For example when I play some films in mplayer ondemand sets frequency to max which is not needed, of course. Powersave governor is also good in case that you have bad fan in your laptop and you are going to compile some big source. Without powersave it is not possible (yes, it really happens :) ) > Matthew Garrett and I are working on a latency profile for power > management, and having all these modules potentially loaded is bad. > > Comments? > I think we should preserve ondemand and powersave governors (and potentialy others as Dave Jones wrote in this thread). Please don't drop them in favour of your project which might be generally better but I believe there are cases where current governors are better. Adam -- Adam Tkac, Red Hat, Inc. From hughsient at gmail.com Mon Jun 30 09:54:32 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 30 Jun 2008 10:54:32 +0100 Subject: kernel module options for cpufreq In-Reply-To: <20080630071028.GA5008@traged.atkac.englab.brq.redhat.com> References: <1214583204.3394.30.camel@hughsie-work> <20080630071028.GA5008@traged.atkac.englab.brq.redhat.com> Message-ID: <1214819672.3511.26.camel@hughsie-work> On Mon, 2008-06-30 at 09:10 +0200, Adam Tkac wrote: > On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: > > * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically > > throttles down to lowest, and is just a hardcoded state > > I don't think removal of powersave governor is good idea. Generally > ondemand governor does great job but in some cases doesn't. For > example when I play some films in mplayer ondemand sets frequency to > max which is not needed, of course. Right, so we need to fix ondemand to be cleverer. > Powersave governor is also good in case that you have bad fan in your > laptop and you are going to compile some big source. Without powersave > it is not possible (yes, it really happens :) ) Right, thermal management is similar to power management for the action but not for the policy. I don't think forcing the lowest speed setting is the correct way to fix this. If the laptop is running cool, why use the slowest speed? > > Matthew Garrett and I are working on a latency profile for power > > management, and having all these modules potentially loaded is bad. > > > > Comments? > > > > I think we should preserve ondemand and powersave governors (and > potentialy others as Dave Jones wrote in this thread). Please don't > drop them in favour of your project which might be generally better but > I believe there are cases where current governors are better. Right, cheers for your feedback. In view of everybodies comments, what about the following: * Compile _into_ the kernel ondemand, performance, powersave and userspace. * Default to performance in the kernel rather than userspace * Build as a module conservative with the view of just fixing ondemand if there are any special use-cases that conservative is better at * Export the P and C state latency to userspace and let the system policy dictate the governor. For instance, even for machines that have a long latency for changing P states should be able to use ondemand if we want to save maximum power. How does that sound? Richard. From mjg59 at srcf.ucam.org Mon Jun 30 11:20:43 2008 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Mon, 30 Jun 2008 12:20:43 +0100 Subject: kernel module options for cpufreq In-Reply-To: <20080630071028.GA5008@traged.atkac.englab.brq.redhat.com> References: <1214583204.3394.30.camel@hughsie-work> <20080630071028.GA5008@traged.atkac.englab.brq.redhat.com> Message-ID: <20080630112043.GA21246@srcf.ucam.org> On Mon, Jun 30, 2008 at 09:10:28AM +0200, Adam Tkac wrote: > On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: > > * remove ?CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically > > throttles down to lowest, and is just a hardcoded state > > I don't think removal of powersave governor is good idea. Generally > ondemand governor does great job but in some cases doesn't. For > example when I play some films in mplayer ondemand sets frequency to > max which is not needed, of course. The same can be achieved by altering /sys/devices/system/cpu/*/cpufreq/scaling_max_freq, but it's still likely that you're consuming less power when ondemand is setting your frequency to max. An idle fast processor consumes less power than an active slow one. > Powersave governor is also good in case that you have bad fan in your > laptop and you are going to compile some big source. Without powersave > it is not possible (yes, it really happens :) ) http://lkml.org/lkml/2008/6/16/100 > I think we should preserve ondemand and powersave governors (and > potentialy others as Dave Jones wrote in this thread). Please don't > drop them in favour of your project which might be generally better but > I believe there are cases where current governors are better. I'm open to indications as to what these are :) Powersave is semantically identical to ondemand with scaling_max_freq altered. Performance is semantically identical to ondemand with scaling_min_freq altered. -- Matthew Garrett | mjg59 at srcf.ucam.org From jwilson at redhat.com Mon Jun 30 16:30:36 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 30 Jun 2008 12:30:36 -0400 Subject: kernel module options for cpufreq In-Reply-To: <1214819672.3511.26.camel@hughsie-work> References: <1214583204.3394.30.camel@hughsie-work> <20080630071028.GA5008@traged.atkac.englab.brq.redhat.com> <1214819672.3511.26.camel@hughsie-work> Message-ID: <200806301230.36335.jwilson@redhat.com> On Monday 30 June 2008 05:54:32 am Richard Hughes wrote: > Right, cheers for your feedback. In view of everybodies comments, what > about the following: > > * Compile _into_ the kernel ondemand, performance, powersave and > userspace. Sounds reasonable. > * Default to performance in the kernel rather than userspace What's the difference? Both leave the cpu at its max speed all the time, unless the cpuspeed daemon gets started up in the userspace case. > * Build as a module conservative with the view of just fixing ondemand > if there are any special use-cases that conservative is better at > * Export the P and C state latency to userspace and let the system > policy dictate the governor. For instance, even for machines that have a > long latency for changing P states should be able to use ondemand if we > want to save maximum power. > > How does that sound? Mostly sane. System policy dictating governor over the ugliness we do in the cpuspeed init script would be nice. Even nicer would be if we could outright get rid of the initscript (not sure what people who need the cpuspeed daemon are to do in that case though). -- Jarod Wilson jwilson at redhat.com From doug.chapman at hp.com Mon Jun 30 20:12:51 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Mon, 30 Jun 2008 16:12:51 -0400 Subject: [PATCH] ia64: export account_system_vtime Message-ID: <1214856771.21186.17.camel@oberon> This has been pushed and ACKed upstream on the linux-ia64 list. If possible I would like to get this pulled into Fedora now since it breaks Fedora ia64 kernel builds. thanks, - Doug ---------------------------- The symbol account_system_vtime is used by the kvm module but not exported. This breaks building with CONFIG_VIRT_CPU_ACCOUNTING and CONFIG_KVM=m. Signed-off-by: Doug Chapman Acked-by: Hidetoshi Seto --- diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c index 8c73643..aad1b7b 100644 --- a/arch/ia64/kernel/time.c +++ b/arch/ia64/kernel/time.c @@ -117,6 +117,7 @@ void account_system_vtime(struct task_struct *tsk) local_irq_restore(flags); } +EXPORT_SYMBOL_GPL(account_system_vtime); /* * Called from the timer interrupt handler to charge accumulated user time