Re: drop SECURITY_FILE_CAPABILITIES? (fwd)
On Wed, Nov 11, 2009 at 09:52:02AM -0500, Adam Jackson wrote: On Tue, 2009-11-10 at 18:00 -0500, Dave Jones wrote: On Wed, Nov 11, 2009 at 09:56:57AM +1100, James Morris wrote: How might this affect the Fedora kernel? We set it =y, so it wouldn't affect us if I understand correctly. Also, I'm not sure that anything in userspace is actually using this feature yet anyway. google codesearch to the rescue: http://google.com/codesearch?hl=ensa=Nfilter=0q=prctl.*PR_CAPBSET_DROP afaik, that prctl is available regardless of the option being set. I meant I don't think anything we ship is using the file capabilities, which is a way of marking executable files with the caps they need instead of having them be setuid. (I'm not even sure what tool we would use to set those capabilities, or if we ship it) Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: drop SECURITY_FILE_CAPABILITIES? (fwd)
On Wed, Nov 11, 2009 at 09:56:57AM +1100, James Morris wrote: How might this affect the Fedora kernel? We set it =y, so it wouldn't affect us if I understand correctly. Also, I'm not sure that anything in userspace is actually using this feature yet anyway. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] update f12 fcoe related kernel code
On Tue, Sep 15, 2009 at 01:05:53PM -0500, Mike Christie wrote: Hi, Sorry for the large patch. I was not sure how I should do this. I am trying to update the fcoe related (fcoe, libfc, ixgbe, fnic and dcb) kernel code that is going into fedora 12. The attached patch updates the fedora 12 kernel to what is in the SCSI maintainer and network maintainer's trees for 2.6.32-rc1. For scsi this is the scsi-misc tree http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=summary and for networking this is the net-next tree http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=summary. This scares me. We're shipping 2.6.31 because we can't justify the risk of shipping rc code in a final release. With huge amounts of change like this, we're essentially doing the same thing. What justification is there for this ? (If the answer involves the acronym 'RHEL' there are better ways than shoving it into Fedora at the last minute) Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: CONFIG_CC_OPTIMIZE_FOR_SIZE?
On Thu, Sep 03, 2009 at 01:01:55PM -0300, Arnaldo Carvalho de Melo wrote: Em Thu, Sep 03, 2009 at 11:48:42AM -0400, Aristeu Rozanski escreveu: Hi, does anyone know why CONFIG_CC_OPTIMIZE_FOR_SIZE is enabled in fedora kernel? I thought that option was useful for embedded systems only. IIRC because it makes the kernel faster :-) The reduced icache pressure makes it a win. As a bonus some non-performance-sensitive code (like the acpi interpretor) gets a _lot_ smaller on-disk. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Recompile kernel without SMP
On Mon, Aug 17, 2009 at 08:17:29PM -0400, Paul Grinberg wrote: Josh, I have a good reason for that. I use Cisco VPN client for Linux, and it does not work with SMP kernel. Have you tried the vpnc package ? The binary cisco module has an hurrendous track record of problems with the Fedora kernel, as it seemingly makes assumptions about networking internals that constantly change upstream, leading to all sorts of horrible corruption bugs. vpnc isn't perfect, but for many cisco setups, it's adequate, and does all the complicated stuff in userspace. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] build a 'full' package on i686
On Mon, Jul 20, 2009 at 10:12:06AM -0400, Bill Nottingham wrote: Dave Jones (da...@redhat.com) said: +# We only build -PAE on 686. %ifarch i686 -%define with_up 0 %define with_pae 1 %else %define with_pae 0 The naming of 'with_up' is subtle here. With this change, we'll try building a '686' kernel as well as a '686-PAE'. That was the intent, as the i586 package would be going away. Oh, I thought that proposal got shot down. We're really dropping support for all those old systems? I'm ok with it if it's been approved, but want to be sure before I start gutting the kernel of 586isms. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] build a 'full' package on i686
On Fri, Jul 17, 2009 at 01:01:54PM -0400, Bill Nottingham wrote: This is needed for the i686-by-default feature. Bill Index: kernel.spec === RCS file: /cvs/extras/rpms/kernel/devel/kernel.spec,v retrieving revision 1.1634 diff -u -r1.1634 kernel.spec --- kernel.spec 17 Jul 2009 02:07:24 - 1.1634 +++ kernel.spec 17 Jul 2009 17:01:15 - @@ -195,9 +195,8 @@ %endif %define debuginfodir /usr/lib/debug -# We only build -PAE for 686 as of Fedora 11. +# We only build -PAE on 686. %ifarch i686 -%define with_up 0 %define with_pae 1 %else %define with_pae 0 The naming of 'with_up' is subtle here. With this change, we'll try building a '686' kernel as well as a '686-PAE'. (which no longer exists, in favour of using the 586 kernel) Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fw: Kernel Loading Sequence
On Sun, Jul 12, 2009 at 01:43:36PM +0200, drago01 wrote: On Sun, Jul 12, 2009 at 1:32 PM, Ahmad Al-Yamanahmad221...@yahoo.com wrote: Thank you, I adjusted the config file as you recommended and the messages are gone. Where should I report this lockdep? Depends on which kernel / patches do you use. If it is a vanilla tarball then upstream (lkml / bugzilla.kernel.org) if you are using the fedora kernel bugzilla.redhat.com It's already fixed in 2.6.31rc2 Fedora 11 will pick it up when we rebase, it's not a critical patch. Rawhide is already fixed. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: ia64 no longer should set CONFIG_SYSFS_DEPRECATED=y
On Wed, Apr 22, 2009 at 04:33:22PM -0400, Doug Chapman wrote: Back in the F9 timeframe we had recommended that CONFIG_SYSFS_DEPRECATED=y be set for the ia64 config. It appears that recent anaconda changes no longer work at all with that set. Can we get this removed? It was set only for ia64 so it will have no affect on other arches. Done. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] FC11: fix rh#491625 (Unable to run RHEL-5 Xen within KVM guest)
On Wed, Apr 08, 2009 at 07:00:15PM -0300, Marcelo Tosatti wrote: Following adds a fix for $subject. Please review. Looks fine to me, as long as it's been tested. Don't have commit access yet so unable to commit myself. https://fedoraproject.org/wiki/Kernel#Contributing_to_the_Fedora_kernel has all the details. We can hook you up. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Alpha platform support for kernel package (WAS: Re: [pkgdb] kernel: oliver has requested commit)
On Wed, Mar 11, 2009 at 09:52:44AM +0100, Oliver Falk wrote: Oliver Falk wrote: Hi! Changed the subject, as happens that I oversee the mails :-( And this subject is more descriptive, isn't it? Kyle McMartin wrote: [ ... ] This all looks fine to me. May I interpret this as a *GO*? :-) Sorry to have been so blunt, but I'm fairly new to Fedora, so I didn't know you were actually working on stuff, and not just someone asking for random commit access. Don't worry. I didn't get this wrong. I can understand you where worrying. If I'd be in your position, I would react differently. I wouldn't worry too much about the linux-2.6- namespace for patches, I'd prefer if they were just alpha-$patch.patch. davej, thoughts? Whatever you prefer. Let me know, so I start working on this today... Did I miss the answer to my mail!? Sorry, I was on vacation, and it fell off my radar when I got back. Looked ok to commit to me though iirc. I've no really preference on patch naming. If you want to do alpha-*, go ahead. but don't feel that you have to. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [pkgdb] kernel: oliver has requested commit
On Thu, Feb 26, 2009 at 11:46:08AM -0600, Jason L Tibbitts III wrote: KM == Kyle McMartin k...@infradead.org writes: KM Uh, who are you again? Oliver Falk, works on the Alpha port if I'm not mistaken. I'm not averse to adding him to committers, but I'd like to see the patches go by fedora-kernel-list first. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Module request: IB700_WDT (IB700 watchdog timer)
On Wed, Feb 25, 2009 at 07:53:08PM +, Richard W.M. Jones wrote: On Wed, Feb 25, 2009 at 01:19:21PM -0500, Dave Jones wrote: On Wed, Feb 25, 2009 at 04:13:22PM +, Richard W.M. Jones wrote: I assume this is the right place to request drivers for the Fedora kernel? I'd like to request that the in-tree IB700 watchdog driver be enabled. The config option is IB700_WDT. looks like it already is ? $ grep IB700 config-* config-generic:CONFIG_IB700_WDT=m I don't understand the way the config files get generated fully, but in current Rawhide CVS I see: $ grep IB700 config* config-generic:# CONFIG_IB700_WDT is not set config-x86-generic:CONFIG_IB700_WDT=m I replied to your mail before I noticed another mail that showed Kyle turned it on earlier today. He added it to config-generic, which is what my grep turned up. I moved it to x86-generic, as it seems pointless turning it on on other architectures given it's for a SBC. The driver doesn't seem to be built even on x86, eg in this build from today: Yeah, no builds have been done today yet. It'll be in the next one that goes out. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 06:07:13AM -0500, Prarit Bhargava wrote: Dave Jones wrote: 2. Will we eventually rename kernel-PAE.686 to kernel.686? I don't think we can, otherwise someone with non-PAE 686's who does an update will suddenly find themselves unable to boot. Hi Dave, I was thinking about this for a little while. Can't we do this instead: 1. move kernel-PAE.686 config options to kernel.686 (I'm going to refer to this as the new kernel.686) 2. kill kernel-PAE.686 3. modify the spec file for the new kernel.686 to obsolete kernel-PAE.686 ? I'm probably missing something obvious but having PAE in there seems strange to me. It's still the same upgrade problem. Someone will be going from 'kernel' with no PAE to 'kernel' with PAE, and on a CPU without PAE, that means they can't boot any more. In that situation they need to go 'kernel'(i686) to 'kernel'(i586) which aparently the tools already handle. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 12:23:51PM -0500, Jon Masters wrote: On Fri, 2009-02-06 at 11:39 -0500, Dave Jones wrote: It's still the same upgrade problem. Someone will be going from 'kernel' with no PAE to 'kernel' with PAE, and on a CPU without PAE, that means they can't boot any more. In that situation they need to go 'kernel'(i686) to 'kernel'(i586) which aparently the tools already handle. I'm missing something... Is there really that much additional work that we can't keep the UP/SMP kernel around for the time being? ?? We haven't shipped a UP x86 kernel in about 3 years. If PAE were default installed in F11 for everyone and it were publicly announced that support for non-PAE was dying in F12 Part of the problem with that idea is that the Pentium M laptops without PAE aren't that old. This might upset quite a few people. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 12:34:04PM -0500, Prarit Bhargava wrote: Given the other information coming through (about dynamic kernel PAE enable), should we really being doing this right now? it's vaporware. Why not wait for the dynamic PAE stuff to settle upstream and then make the change? no-one seems to actually be doing anything. Then we can properly (IMO) drop kernel-PAE.686 and stick with kernel.686. What happens if we postpone this until F12? I bet nothing will have changed. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 12:38:56PM -0500, Prarit Bhargava wrote: dynamic PAE ? Uh -- I can see how that is confusing :) Sorry, let me make another attempt at that. What I should have said was that there are patches floating around to make PAE dynamically selectable -- I think the example that was referenced was the smp alternatives code. The idea has been floated, but no patches ever happened afaik. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 01:01:43PM -0500, Jon Masters wrote: Not quite though from what I hear (trying to reconcile what Thorsten said). But perhaps he was solely complaining that most people would run PAE and thus have to type kmod-crud-PAE. The kmod thing is a non-argument afaics. If you currently use kernel-686, you'll be running kernel-586 in F11, so you have 'kmod-foo' to go with it. If you currently use kernel-686-PAE, you'll be running the _same_ thing in F11. The only possible change, is that with anaconda recognising PAE and installing the PAE kernel by default, more people will be running it. So it's just exposing it to more people. I don't see how this is a problem. said to Prarit that I'd kill off the PAE kernel and find out who complains about having a 32GB i686 non-x86_64 system around...but that's just my Friday sense of humo[u]r. PAE also gets you NX support, so it's not just a 4G thing. (Which means you won't need to run the nasty execshield segment limit hacks -- One more nail in execshields coffin) Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
arch fun.
As per the discussion in #fedora-meeting today,
we're killing off kernel-i686, and just shipping..
* kernel.i586
* kernel-PAE.686
Patch below seems to dtrt.. comments?
Looking at the generated config files, the biggest difference
seems to be that kernel-PAE enables Xen and all it's related
dependancies.
Dave
Index: Makefile.config
===
RCS file: /cvs/pkgs/rpms/kernel/devel/Makefile.config,v
retrieving revision 1.69
diff -u -p -r1.69 Makefile.config
--- Makefile.config 26 Jan 2009 07:19:13 - 1.69
+++ Makefile.config 5 Feb 2009 20:09:20 -
@@ -6,7 +6,7 @@ CFG = kernel-$(VERSION)
CONFIGFILES= \
$(CFG)-i586.config \
- $(CFG)-i686.config $(CFG)-i686-PAE.config \
+ $(CFG)-i686-PAE.config \
$(CFG)-i686-debug.config $(CFG)-i686-PAEdebug.config \
$(CFG)-x86_64.config $(CFG)-x86_64-debug.config \
$(CFG)-s390x.config $(CFG)-arm.config \
@@ -63,9 +63,6 @@ temp-s390-generic: config-s390x temp-gen
temp-ia64-generic: config-ia64-generic temp-generic
perl merge.pl $^ $@
-kernel-$(VERSION)-i686.config: config-i686 temp-x86-generic
- perl merge.pl $^ i386 $@
-
kernel-$(VERSION)-i686-debug.config: config-i686 temp-x86-debug-generic
perl merge.pl $^ i386 $@
Index: config-i586
===
RCS file: /cvs/pkgs/rpms/kernel/devel/config-i586,v
retrieving revision 1.5
diff -u -p -r1.5 config-i586
--- config-i586 14 Feb 2008 19:56:06 - 1.5
+++ config-i586 5 Feb 2009 20:09:20 -
@@ -6,4 +6,3 @@ CONFIG_HIGHMEM4G=y
CONFIG_X86_POWERNOW_K6=m
-# CONFIG_KVM is not set
Index: config-i686
===
RCS file: config-i686
diff -N config-i686
--- config-i686 12 Jul 2007 19:15:37 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,8 +0,0 @@
-CONFIG_M686=y
-# CONFIG_NOHIGHMEM is not set
-CONFIG_HIGHMEM4G=y
-# CONFIG_HIGHMEM64G is not set
-
-CONFIG_CRYPTO_DEV_PADLOCK=m
-CONFIG_CRYPTO_DEV_PADLOCK_AES=m
-CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
Index: config-x86-generic
===
RCS file: /cvs/pkgs/rpms/kernel/devel/config-x86-generic,v
retrieving revision 1.63
diff -u -p -r1.63 config-x86-generic
--- config-x86-generic 30 Jan 2009 00:08:01 - 1.63
+++ config-x86-generic 5 Feb 2009 20:09:20 -
@@ -205,9 +205,9 @@ CONFIG_NVRAM=y
CONFIG_IBM_ASM=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_TWOFISH_586=m
-# CONFIG_CRYPTO_DEV_PADLOCK is not set
-# CONFIG_CRYPTO_DEV_PADLOCK_AES is not set
-# CONFIG_CRYPTO_DEV_PADLOCK_SHA is not set
+CONFIG_CRYPTO_DEV_PADLOCK=m
+CONFIG_CRYPTO_DEV_PADLOCK_AES=m
+CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_GENERIC_ISA_DMA=y
CONFIG_SCHED_SMT=y
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.1263
diff -u -p -r1.1263 kernel.spec
--- kernel.spec 5 Feb 2009 18:55:52 - 1.1263
+++ kernel.spec 5 Feb 2009 20:09:20 -
@@ -241,6 +241,11 @@ Summary: The Linux kernel
%define with_kdump 0
#endif
+# We only build -PAE for 686 as of Fedora 11.
+%ifarch i686
+%define with_up 0
+%endif
+
# don't do debug builds on anything but i686 and x86_64
%ifnarch i686 x86_64
%define with_debug 0
@@ -522,8 +527,7 @@ Source24: config-rhel-generic
Source30: config-x86-generic
Source31: config-i586
-Source32: config-i686
-Source33: config-i686-PAE
+Source32: config-i686-PAE
Source40: config-x86_64-generic
@@ -1477,7 +1481,9 @@ mkdir -p $RPM_BUILD_ROOT/boot
cd linux-%{kversion}.%{_target_cpu}
%if %{with_debug}
+%ifnarch i686
BuildKernel %make_target %kernel_image debug
+%endif
%if %{with_pae}
BuildKernel %make_target %kernel_image PAEdebug
%endif
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Thu, Feb 05, 2009 at 03:11:40PM -0500, Dave Jones wrote: As per the discussion in #fedora-meeting today, we're killing off kernel-i686, and just shipping.. * kernel.i586 * kernel-PAE.686 Patch below seems to dtrt.. comments? Looking at the generated config files, the biggest difference seems to be that kernel-PAE enables Xen and all it's related dependancies. Better version of the Makefile.config with changes Josh pointed out.. Dave Index: Makefile.config === RCS file: /cvs/pkgs/rpms/kernel/devel/Makefile.config,v retrieving revision 1.69 diff -u -p -r1.69 Makefile.config --- Makefile.config 26 Jan 2009 07:19:13 - 1.69 +++ Makefile.config 5 Feb 2009 20:27:40 - @@ -5,9 +5,8 @@ CFG= kernel-$(VERSION) CONFIGFILES= \ - $(CFG)-i586.config \ - $(CFG)-i686.config $(CFG)-i686-PAE.config \ - $(CFG)-i686-debug.config $(CFG)-i686-PAEdebug.config \ + $(CFG)-i586.config $(CFG)-i586-debug.config \ + $(CFG)-i686-PAE.config $(CFG)-i686-PAEdebug.config \ $(CFG)-x86_64.config $(CFG)-x86_64-debug.config \ $(CFG)-s390x.config $(CFG)-arm.config \ $(CFG)-ppc.config $(CFG)-ppc-smp.config \ @@ -63,12 +62,6 @@ temp-s390-generic: config-s390x temp-gen temp-ia64-generic: config-ia64-generic temp-generic perl merge.pl $^ $@ -kernel-$(VERSION)-i686.config: config-i686 temp-x86-generic - perl merge.pl $^ i386 $@ - -kernel-$(VERSION)-i686-debug.config: config-i686 temp-x86-debug-generic - perl merge.pl $^ i386 $@ - kernel-$(VERSION)-i686-PAE.config: config-i686-PAE temp-x86-generic perl merge.pl $^ i386 $@ @@ -78,6 +71,9 @@ kernel-$(VERSION)-i686-PAEdebug.config: kernel-$(VERSION)-i586.config: config-i586 temp-x86-generic perl merge.pl $^ i386 $@ +kernel-$(VERSION)-i586-debug.config: config-i586 temp-x86-debug-generic + perl merge.pl $^ i386 $@ + kernel-$(VERSION)-x86_64.config: /dev/null temp-x86_64-generic perl merge.pl $^ x86_64 $@ -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Thu, Feb 05, 2009 at 03:22:55PM -0500, Prarit Bhargava wrote: Two quick questions Dave. 1. This is for F11? yes 2. Will we eventually rename kernel-PAE.686 to kernel.686? I don't think we can, otherwise someone with non-PAE 686's who does an update will suddenly find themselves unable to boot. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Thu, Feb 05, 2009 at 12:23:07PM -0800, Roland McGrath wrote:
Patch below seems to dtrt.. comments?
Why kill the configs, instead of just changing the spec settings?
@@ -1477,7 +1481,9 @@ mkdir -p $RPM_BUILD_ROOT/boot
cd linux-%{kversion}.%{_target_cpu}
%if %{with_debug}
+%ifnarch i686
BuildKernel %make_target %kernel_image debug
+%endif
%if %{with_pae}
BuildKernel %make_target %kernel_image PAEdebug
%endif
Why not %if !%{with_up} here?
that works too.
Dave
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Switching Fedora to pae kernel by default?
On Mon, Jan 19, 2009 at 03:49:20PM +0200, Avi Kivity wrote: This probably comes up once in a while, thought I'd raise it again. I'd like to suggest switching the default kernel to -PAE on machines that support it, for the following reasons: - many machines have 4GB+ these days, even desktops - NX is only available with -PAE, improves security - kvm is significantly faster on AMD when PAE is selected (since we don't support NPT on non-PAE) What's needed to set this by default is changes in anaconda. They have their own list at anaconda-l...@redhat.com Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Switching Fedora to pae kernel by default?
On Mon, Jan 19, 2009 at 11:24:14AM -0700, Pete Zaitcev wrote: On Mon, 19 Jan 2009 19:31:12 +0200, Avi Kivity a...@redhat.com wrote: Are Pentium Ms (really the memory that comes with them) actually capable of running recent Fedoras? I'm talking desktop, not I'm-using-my-laptop-as-a-firewall-just-because-I-can. If only it were laptops. I think they still sell systems like this: [zait...@mallorn ~]$ more /proc/cpuinfo processor: 0 vendor_id: CentaurHauls cpu family : 6 model: 7 model name : VIA Samuel 2 The samuel 2 stopped being made ~5 years ago. VIA have been PAE capable since the Nehemiah generation. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] build in microcode driver on x86
On Wed, Jan 14, 2009 at 01:17:38PM -0500, Bill Nottingham wrote: It doesn't really gain anything from being static, aside from requiring odd udev rules and/or init scripts to load it. We had this discussion yesterday on irc, but I never really got this in my head. It works ok with microcode.dat, but what happens if Intel release an update in /lib/firmware/intel-ucode/$f-$m-$s format ? The driver will do a request_firmware, but if we build the driver in, we'll be in the initrd, where that file won't exist. To make it work, we'll either have to.. - have the firmware in the initramfs or - pretend the request_firmware didn't happen, and have the initscript continue to do the microcode_ctl Which direction are we moving in ? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: config changes
On Tue, Jan 13, 2009 at 09:55:27PM +0100, Gerd Hoffmann wrote: Bill Nottingham wrote: Here's some proposed config changes. Jumping on the wagon ;) Can we enable CONFIG_DMAR please? This turns on the IOMMU on intel boxes, using VT-d. Called DMA Remapping in intel speak, this is where the config option name comes from. Advantages: (1) 32bit PCI devices can DMA to memory above 4G, thus the need for swiotlb (i.e. bounce buffers) is gone. (2) It allows kvm to pass through PCI devices to guests securely. The last time we tried this, it blew up a lot due to broken BIOSes. Maybe it's been improved enough to tolerate them, so we can probably give it a spin in rawhide for a while to see what happens. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Custom Kernel USB Boot Problem
On Fri, Jan 09, 2009 at 08:32:25AM -0800, Ahmad Al-Yaman wrote: Hi everyone, I'm building a custom kernel optimized for the Eee PC netbook. The kernel works without problems when installed on the main SSD but when I tried installing it on a USB flash disk, or SD card, and booted, I got the following error: Unable to access resume device (UUID=UUID) mount: error mounting /dev/root on /sysroot as ext3: No such file or directory I'm assuming there are some packages necessary to boot from USB devices that need to be included in the kernel config which I didn't include. Can anyone give me an idea what those packages might be? some random guesses.. mkinitrd probably doesn't support booting off of the mmc device. or if it does, perhaps the mmc modules are missing from the initrd. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Enabling drivers in staging tree in rawhide
On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote: Related: I raised the staging problem already in https://bugzilla.redhat.com/show_bug.cgi?id=477927 as rawhide contained the at76 driver as separate patch http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/linux-2.6-at76.patch?view=markup -- but the same driver (with two small changes) also was part of the upstream kernel since October/2.6.28-rc as one of the staging drivers: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99e06e372378c5833a0c60274b645dfb2e4a4b08 (for more details see bug). That sounds wrong to me, as - it's duplicated work - the at76 staging driver from upstream taints the kernel; the driver from our patch doesn't. The wireless stuff, I've pretty much deferred to the wireless maintainer, John Linville. I don't know the backstory behind at76, but it's been lingering for quite a while, and it would be nice to see it go away yes. I'm not clear on why this is going through -staging instead of wireless-dev either. The ralink wireless drivers for example would hopefully make the newer EEE PC model would out of the box. Does it make sense to enable the drivers in staging tree by default and bring more exposure to them atleast via rawhide if not in general releases? +1 to the I think providing hardware support in rawhide and then removing it before release would be somewhat user-hostile. comment from mjg59. IOW: Either enable or disable them. I'm unsure myself what to do but I tend to say that disabling the whole staging drivers might be the best for Fedora (Greg calls himself as maintainer of crap for a good reason). @Davej, Cebbert and Kylem: What's your position on this? I don't think we can make a carte-blanche statement to say no we won't do this ever. The quality of the drivers that end up there are going to vary, and for some, if it's for a piece of hardware that's really popular, it may make sense to enable it. As long as doing so doesn't cause us headaches down the line. I'm not overly against the idea of enabling something with the caveat that we have someone responsible for working on it, with the goal of getting it out of staging, and dealing with bugs etc. Not unlike the same reasoning for us adding various not-yet-upstream drivers to the Fedora kernel really. But it's really going to be a case-by-case thing I think. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: /proc/sys/fs/epoll/max_user_instances=128 considered harmful
On Wed, Jan 07, 2009 at 03:18:12PM +, Joe Orton wrote: The F10 kernel has /proc/sys/fs/epoll/max_user_instances set to 128 by default. Apache httpd uses one epoll fd (instance) per child process, so this sets a hard limit on 128 children (i.e. 100 concurrent clients) out of the box. 1) shouldn't this be an rlimit so that we can bump it appropriately in the parent as root? possibly. It's a question better asked on linux-kernel really. This does sound like a better change to me than forcing the sysctl change on everyone. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Problem booting F10 from 3ware 9650SE controller
On Mon, Dec 08, 2008 at 11:28:09AM -0700, Ted Sume Nzuonkwelle wrote: Hi, I just installed Fedora 10 on a 9650SE raid controller with a Raid 1 configuration. The installation was successful. I have not been able to boot yet. Looks like initrd cannot access swap event though it loads 3w-9xxx properly. details follow. The first boot attempt complained that the resume device did not exist, so i booted into rescue, but none of the partitions were mounted. Then i booted into rescue again, and mounted /, modified fstab by replacing labels, UUIDs, with corresponding partition names.../dev/sda[1-9]. Then i rebooted into rescue and all partitions were mounted and i was able to chroot /mnt/sysimage, and then regenerated initrd so it picks up changes in fstab. When i try to boot the system again from disk i get the following error. sda: Setting up hotplug Creating block device nodes Creating character device nodes Loading 3w-9xxx module Loading shpchp module Unable to access resume device (/dev/sda2) Creating root device mount: error mounting /dev/root on /sysroot as ext3, No such file or directory sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 --- This was my first attempt at installing and booting from a raid controller. Any thoughts.?? There have been a few similar reports to this in bugzilla. I think mkinitrd isn't waiting long enough for the device to settle before it tries to mount it. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: execshield rebase
On Thu, Dec 04, 2008 at 02:05:03PM -0800, Roland McGrath wrote: I've been thinking for a while execshield.patch could be split into two or three cleaner patches. Some of those might even be upstreamable as config options or something. It really isn't that big a patch at this point. I tried back in July when I got the diff down to under a thousand lines. Linus wasn't really enthusiastic. http://www.codemonkey.org.uk/junk/linus-es.txt has the interesting bits.. The get_wchan bit that he mentions definitly should be factored out. It's completely unrelated to the NX-emulation. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Allow debug kernels for ppc64
On Tue, Oct 21, 2008 at 08:57:27AM -0400, Josh Boyer wrote: While I'm certainly not advocating for building them normally, it would be handy to actually be able to build a debug kernel for ppc64 from time to time. I had to make the following changes for this to work (outside of adding ppc64 to the arch list for debug kernels in kernel.spec). Anyone have a problem with me committing this? That bit is fine, as it won't build it without the specfile fragment. If the ppc64 builders weren't so damned slow, I'd have no problem with enabling it along with the x86 ones. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
patch naming scheme.
For a while, diffs in the Fedora kernel have followed the form linux-2.6-*.patch Then, we started seeing some git snapshots show up as git-*.diff and lately, everything seems to have gone bananas, with no particular scheme at all.. nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc. Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else. So, what are peoples thoughts on this? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch naming scheme.
On Fri, Oct 10, 2008 at 03:14:42PM -0400, Adam Jackson wrote: In the X server I try to keep the original version the patch was against in the name, to give some idea of how old a patch is. Admittedly this is less useful with the kernel because you guys have ridiculous version numbers, but even just being able to see the difference between linux-2.6.9-foo.patch and linux-2.6.27-bar.patch might be useful. Way back when, we used to do that. But that kind of loses its meaning too. For stuff that's never going upstream, you end up with linux-2.6.5-execshield And for other patches older than 1 version, why aren't they upstream again? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch naming scheme.
On Fri, Oct 10, 2008 at 05:55:50PM -0400, Jarod Wilson wrote: On Friday 10 October 2008 17:27:00 Chris Snook wrote: Dave Jones wrote: For a while, diffs in the Fedora kernel have followed the form linux-2.6-*.patch Then, we started seeing some git snapshots show up as git-*.diff and lately, everything seems to have gone bananas, with no particular scheme at all.. nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc. Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else. So, what are peoples thoughts on this? Dave If we'd prefix them with the source package name, in this case kernel, it would make it a lot easier to find things in /usr/src/redhat/SOURCES when we've got SRPMs from different packages installed. We should probably avoid using names that refer to a specific upstream version, because the name becomes misleading once we rebase. When there's a suitable upstream patch name, like the names Andrew Morton uses in -mm, we should probably use those (perhaps prepended with kernel-) to make it clear what it corresponds to upstream. Yeah, I'd be happy with pkgname-tree id-description.patch, omitting the tree id portion if there isn't one, or some variant thereof. Being able to do an 'ls kernel*.patch' is definitely useful. kernel-* is sacred. Tab completion ftw. :) Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch naming scheme.
On Fri, Oct 10, 2008 at 08:43:34PM -0500, Eric Sandeen wrote: As an aside - but maybe relevant - how much description / lineage / whatever should go into the spec file comments vs. into the TODO file? The TODO is pretty free form, put whatever you want in there. Pointers to upstream discussion (if any exists) is a good start, as is any other info on its upstream progress. The specfile - One liners are fine. Think about the sort of thing that goes in the git shortlog upstream. If bugzillas exist, referencing them with (#123456) at the end seems to be the standard way of mentioning them. I don't want to get beurocratic about all this (hey, it's Fedora, not RHEL :) so I'm not going to be imposing any kind of enforcement on the above. Just go with what feels 'right'. General rule of thumb: Some info is better than no info. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: turning on -fno-inline-functions-called-once
On Mon, Oct 06, 2008 at 02:56:04PM -0400, Steve Dickson wrote: A while back, I believe back during the last FUDCon in Raleigh I talked with kylem and davej about turning off the inline-functions-called-once which inlines functions that are only called once. Turning off this optimization would allow SystemTap to work much better, especially in the NFS code... Kyle/Dave (or anybody else) remember if anything came out from that conversation? I forgot all about that conversation. Is there any reason we should not remove this optimization? I'd be really surprised if it's actually even measurable on modern CPUs. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Fri, Oct 03, 2008 at 11:25:49AM -0400, Peter Jones wrote: Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Also, please add these, since they're nearly always loaded (patch is on top of yours): I think this makes sense to do now as a stop-gap, but one day, I hope we can get to a situation where we do modprobe of such things based on a config file instead of always doing it. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Fri, Oct 03, 2008 at 01:25:50PM -0400, Bill Nottingham wrote: Dave Jones ([EMAIL PROTECTED]) said: On Fri, Oct 03, 2008 at 11:25:49AM -0400, Peter Jones wrote: Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Also, please add these, since they're nearly always loaded (patch is on top of yours): I think this makes sense to do now as a stop-gap, but one day, I hope we can get to a situation where we do modprobe of such things based on a config file instead of always doing it. Ideally the DM layer would be able to request_module() the map type whenever necessary. Wherever possible, yes that would be even better. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide patches.
On Mon, Sep 29, 2008 at 06:59:00PM +0100, Matthew Garrett wrote: On Mon, Sep 29, 2008 at 10:47:05AM -0700, Roland McGrath wrote: linux-2.6-acpi-video-dos.patch linux-2.6-defaults-acpi-video.patch These are policy decisions. Probably not going usptream. Can they be turned into upstream config options? They're already runtime settable, so it's primarily a convenience thing - they're the sensible defaults given our userland. I think Rolands point was that if we had for eg CONFIG_ACPI_VIDEO_DEFAULT we'd get to carry one less patch. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
IA64 ATA patch.
We've had this in Fedora since 2007/02/27
Can anyone recall why? and more importantly, why it isn't upstream?
Dave
--- linux-2.6.20/arch/ia64/kernel/quirks.c 1969-12-31 19:00:00.0
-0500
+++ linux-2.6.20_fix/arch/ia64/kernel/quirks.c 2007-02-13 13:56:34.0
-0500
@@ -0,0 +1,45 @@
+/*
+ * This file contains work-arounds for ia64 platform bugs.
+ */
+#include linux/pci.h
+
+/*
+ * quirk_intel_ide_controller: If an ide/ata controller is
+ * at legacy mode, BIOS might initiates BAR(bar 0~3 and 5)
+ * with incorrect value. This quirk will reset the incorrect
+ * value to 0.
+ */
+static void __devinit quirk_intel_ide_controller(struct pci_dev *dev)
+{
+ unsigned int pos;
+ struct resource *res;
+ int fixed = 0;
+ u8 tmp8;
+
+ if ((dev-class 8) != PCI_CLASS_STORAGE_IDE)
+ return;
+
+ /* TODO: What if one channel is in native mode ... */
+ pci_read_config_byte(dev, PCI_CLASS_PROG, tmp8);
+ if ((tmp8 5) == 5)
+ return;
+
+ for( pos = 0; pos 6; pos ++ ) {
+ res = dev-resource[pos];
+ if (!(res-flags (IORESOURCE_IO | IORESOURCE_MEM)))
+ continue;
+
+ if (!res-start res-end) {
+ res-start = res-end = 0;
+ res-flags = 0;
+ fixed = 1;
+ }
+ }
+ if (fixed)
+ printk(KERN_WARNING
+ PCI device %s: BIOS resource configuration fixed.\n,
+ pci_name(dev));
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_11,
quirk_intel_ide_controller);
+
--- linux-2.6.21.noarch/arch/ia64/kernel/Makefile~ 2007-05-27
23:23:36.0 -0400
+++ linux-2.6.21.noarch/arch/ia64/kernel/Makefile 2007-05-27
23:23:48.0 -0400
@@ -33,6 +33,7 @@ obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_IA64_UNCACHED_ALLOCATOR) += uncached.o
obj-$(CONFIG_AUDIT)+= audit.o
obj-$(CONFIG_PCI_MSI) += msi_ia64.o
+obj-$(CONFIG_PCI) += quirks.o
mca_recovery-y += mca_drv.o mca_drv_asm.o
obj-$(CONFIG_IA64_MC_ERR_INJECT)+= err_inject.o
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
rawhide patches.
I just sifted through what we had in rawhide, after noticing that ls *.patch was starting to scroll my terminal (which is never a good sign). In doing so, I found a bunch of patches that weren't applied any more that we forgot to remove, and a bunch that were applied that shouldn't have been. Sifting through the remnants gave me a list that I've added to cvs as the file 'TODO' in devel. Hopefully we can keep this up to date as patches are introduced/removed. At the least it should serve as reasoning for why the hell we're carrying some patches for years (some of the CVS changelogs are pretty crappy, including some from yours truly). Here's what it looks like today.. Dave drm-modesetting-i915.patch drm-modesetting-radeon.patch linux-2.6-export-shmem-bits-for-gem.patch Intel/Radeon kernel mode-setting. Won't go upstream for a while. drm-nouveau.patch Nouveau DRM driver. Won't go upstream until ABI confirmed. linux-2.6-acpi-clear-wake-status.patch linux-2.6-acpi-video-dos.patch linux-2.6-defaults-acpi-video.patch linux-2.6-input-dell-keyboard-keyup.patch linux-2.6-eeepc-laptop-update.patch mjg59 ACPI/laptop bits. Upstreamable for 2.6.28 ? linux-2.6-at76.patch linux-2.6-iwlwifi-use-dma_alloc_coherent.patch linux-2.6-wireless.patch linux-2.6-wireless-pending.patch Linville. Wireless bits. Most should be upstream for 2.6.28 linux-2.6-ata-quirk.patch IA64 oddness. Query sent to f-k-l linux-2.6-build-nonintconfig.patch linux-2.6-debug-nmi-timeout.patch linux-2.6-debug-spinlock-taint.patch linux-2.6-debug-taint-vm.patch linux-2.6-debug-vm-would-have-oomkilled.patch linux-2.6-scsi-cpqarray-set-master.patch linux-2.6-usb-ehci-hcd-respect-nousb.patch Push for 2.6.28 linux-2.6-compile-fixes.patch linux-2.6-hotfixes.patch Empty linux-2.6-crash-driver.patch Not upstreamable. linux-2.6-debug-always-inline-kzalloc.patch Sent upstream Sep 25 2008 linux-2.6-debug-sizeof-structs.patch Fedora local debug stuff. linux-2.6-default-mmf_dump_elf_headers.patch linux-2.6-utrace.patch linux-2.6-x86-tracehook.patch Roland magick utrace linux-2.6-defaults-fat-utf8.patch Drop? linux-2.6-defaults-pci_no_msi.patch linux-2.6-input-kill-stupid-messages.patch linux-2.6-x86-tune-generic.patch Fedora local choices uninteresting to upstream linux-2.6-e1000e-add-support-for-82567LM-3-and-82567LF-3-ICH10D-parts.patch linux-2.6-e1000e-add-support-for-new-82574L-part.patch linux-2.6-e1000e-add-support-for-the-82567LM-4-device.patch linux-2.6-e1000-ich9.patch linux-2.6-firewire-git-update.patch linux-2.6-netdev-atl2.patch Should go upstream for .28 linux-2.6-efika-not-chrp.patch linux-2.6-g5-therm-shutdown.patch linux-2.6-imac-transparent-bridge.patch linux-2.6-ps3-ehci-iso.patch linux-2.6-ps3-legacy-bootloader-hack.patch linux-2.6-ps3-storage-alias.patch linux-2.6-vio-modalias.patch ppc bits. dwmw2. linux-2.6-execshield.patch linux-2.6-xen-execshield-add-xen-specific-load_user_cs_desc.patch linux-2.6-xen-execshield-fix-endless-gpf-fault-loop.patch linux-2.6-xen-execshield-only-define-load_user_cs_desc-on-32-bit.patch Not interesting to upstream. linux-2.6-lirc.patch jarod working on upstreaming linux-2.6-merge-efifb-imacfb.patch pjones. merge for 2.6.28 ? linux-2.6-nfs-client-mounts-hang.patch SteveD. Sent ping on Sep 25 to find out status. linux-2.6-net-silence-noisy-printks.patch linux-2.6-piix3-silence-quirk.patch linux-2.6-quiet-iommu.patch linux-2.6-silence-acpi-blacklist.patch linux-2.6-silence-fbcon-logo.patch linux-2.6-silence-noise.patch Fedora local 'hush' patches. linux-2.6-selinux-mprotect-checks.patch linux-2.6-sparc-selinux-mprotect-checks.patch Not upstreamable. linux-2.6-serial-460800.patch Probably not upstreamable. http://marc.theaimsgroup.com/?l=linux-kernelm=112687270832687w=2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126403 http://lkml.org/lkml/2006/8/2/208 linux-2.6-squashfs.patch Sigh. Who the hell knows when this will go upstream. linux-2.6-sysrq-c.patch Que? -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide patches.
On Thu, Sep 25, 2008 at 03:07:04PM -0400, Bill Nottingham wrote: Dave Jones ([EMAIL PROTECTED]) said: linux-2.6-defaults-fat-utf8.patch Drop? Isn't this a local choice similar to the later ones? The problem is this is a who do we want to screw over patch. Some people have disks which aren't UTF8, and get crazy moon language instead of their expected charset. linux-2.6-net-silence-noisy-printks.patch linux-2.6-piix3-silence-quirk.patch linux-2.6-quiet-iommu.patch linux-2.6-silence-acpi-blacklist.patch linux-2.6-silence-fbcon-logo.patch linux-2.6-silence-noise.patch Fedora local 'hush' patches. Speaking of 'hush' patches - .. ALSA sound/pci/hda/hda_intel.c:1404: azx_pcm_prepare: bufsize=0x1, format=0x4011 ALSA sound/pci/hda/hda_codec.c:716: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011 .. Is this a config option, or do we need to patch this stuff out? Probably one of the many ALSA debug options. CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y CONFIG_SND_DEBUG_DETECT=y CONFIG_SND_DEBUG_VERBOSE=y CONFIG_SND_PCM_XRUN_DEBUG=y Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: chcorefilter
On Thu, Sep 25, 2008 at 05:32:50PM -0700, Roland McGrath wrote: Content-Description: message body text The /proc/PID/coredump_filter mechanism makes it easy to tweak the per-process setting to control ELF core dump style details. This setting is per-process (per-mm) and inherited by children. But as a user, the /proc interface is insane. It prints a magical hex value (without a leading 0x, to make it sneaky), which you'll be damn lucky to figure out from reading Documentation/filesystems/proc.txt. Then you get to set it to another such magical value, which is in decimal unless you add a leading 0x (cat /proc/x/coredump_filter /proc/y/coredump_filter does not copy the setting, go team). I have kicking around this half-assed bash script that I don't care to bother making really presentable. Where should it live? In the upstream kernel's scripts/? (Then noone would ever see it for sure.) In util-linux-ng? Or what? Someone want to take it off my hands? either util-linux or procps is my suggestion. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Fri, Sep 19, 2008 at 08:02:47AM -0400, Josh Boyer wrote: -CONFIG_IEEE80211=m +CONFIG_IEEE80211=y CONFIG_IEEE80211_DEBUG=y CONFIG_IEEE80211_CRYPT_WEP=m CONFIG_IEEE80211_CRYPT_CCMP=m Do we have a way to _not_ do this on secondary architectures? the per-arch config fragments will always override options in config-generic, so yes. -CONFIG_SND_HDA_INTEL=m +CONFIG_SND_HDA_INTEL=y CONFIG_SND_HDA_HWDEP=y CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y @@ -2545,7 +2545,7 @@ CONFIG_SND_HIFIER=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m -CONFIG_SND_INTEL8X0=m +CONFIG_SND_INTEL8X0=y See... like these two. Not going to be in any ppc box, ever. Why include them in the generic kernel config? I think they should be moved to config-x86-generic.config instead. They got dumped in config-generic instead of duping them in config-x86[64] and config-ia64, but yeah, could do. if the options don't exist on an arch though it's competely benign regardless of what they get set to. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 05:14:14PM -0400, Tom spot Callaway wrote: On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Fly on the wall here, but wouldn't demodularizing the SCSI stack cause problems down the road for RHEL, for third party SCSI/FC drivers? if a vendor is shipping their own scsi_mod or other part of the scsi layer to replace modules we ship, they may be DOING IT WRONG. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 04:27:50PM -0500, Matt Domsch wrote: This _is_ Fedora we're talking about, not RHEL, right? :-) /me has had to replace way too many kernel modules from RHEL, which can't be done if it's built-in. The thing is, Dell or any other vendor having to ship their own module is to me a sign of a failing in the RHEL process that we can't get fastpath pre-next-U release packages out fast enough. THAT should be fixed rather than holding back Fedora (or even RHEL, as it would be a shame that it couldn't take advantage of these wins) Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) looks like some of the lower-hanging fruit. definite room for further expansion. how well will mkinitrd cope when modules it always loads don't exist any more? any nasty hardcoded bits there? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote: On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: See various and sundry plumber's conf discussions. If we build in the loop module, we need to bump the default of number of loopdevs[1] to keep things happier for live images. Right now, we just set maxloop in modprobe.conf does it not appear configurable in sysfs someplace? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 07:49:33PM -0400, Jeremy Katz wrote: On Thu, 2008-09-18 at 19:47 -0400, Dave Jones wrote: On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote: On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: See various and sundry plumber's conf discussions. If we build in the loop module, we need to bump the default of number of loopdevs[1] to keep things happier for live images. Right now, we just set maxloop in modprobe.conf does it not appear configurable in sysfs someplace? Unless something has changed from when I looked last, no. The devices are statically allocated on module(/built-in) load and that's as many as you get. ok, should be easy enough hack in anyway. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFC: split changelog out of spec
On Mon, Aug 18, 2008 at 01:13:26PM -0400, Jarod Wilson wrote:
Hey all,
Been toying with the idea of splitting the changelog out of the kernel spec
itself, to reduce the size of the spec file. Basically, instead of
%changelog
followed by all the entries, it'd be %include %{SOURCE1}, which is a file
'fedora-kernel-changelog', which carries all the usual changelog entries.
Its
reasonably trivial to implement, though my current hack-around for 'make
clog'
complains about me redefining the clog target. Is shaving 800+ lines out of
the spec file (only to put them in another file) worth the hassle though?
Probably not until we move away from CVS to an SCM that doesn't suck.
It'd be nice if 'make build' slurped the changelog out of the SCM.
Dave
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: perfmon2 on fedora kernels
On Thu, Jul 31, 2008 at 02:26:10PM -0400, Chuck Ebbert wrote: We could put it in fedora but it's not upstream and nobody can say when or if it will go in. After the long drawn out pain that utrace has been, I'm somewhat reluctant. Especially for something that's providing additional userspace interfaces that aren't upstream. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: git11 new config items
On Thu, Jul 24, 2008 at 02:31:04AM -0700, Roland McGrath wrote: I added these to config-generic to keep building with -git11. I have no idea if these are the right settings. +# CONFIG_MFD_TC6393XB is not set +# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set +CONFIG_DMADEVICES=y +CONFIG_INTEL_IOATDMA=m +# CONFIG_DMATEST is not set All ok, except that CONFIG_INTEL_IOATDMA is already in config-x86[64].config I just nuked the dupe. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel-vanilla-2.6.26-137.fc10
On Mon, Jul 14, 2008 at 01:03:39PM -0700, Roland McGrath wrote: BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/ for a kernel-vanilla build I did of 2.6.26. This gives a baseline for regression testing any problems to see if they are caused by some Fedora patches (e.g. utrace) or are also upstream. I think koji scratch only stays around for a couple of days. Maybe there is a better place to put these. put them on roland.fedoraproject.org ? Was there ever a plan to put kernel-vanilla rpms up for public consumption on a regular basis? There was. The question largely came down to 'where do we host them?'. The best answer right now does seem to be $personal.fedoraproject.org I think it's worth doing this on a semi-regular basis. Probably not for every -git, but at least for every -rc and point release. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel-vanilla-2.6.26-137.fc10
On Mon, Jul 14, 2008 at 04:28:50PM -0400, Josh Boyer wrote: On Mon, 2008-07-14 at 16:12 -0400, Dave Jones wrote: On Mon, Jul 14, 2008 at 01:03:39PM -0700, Roland McGrath wrote: BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/ for a kernel-vanilla build I did of 2.6.26. This gives a baseline for regression testing any problems to see if they are caused by some Fedora patches (e.g. utrace) or are also upstream. I think koji scratch only stays around for a couple of days. Maybe there is a better place to put these. put them on roland.fedoraproject.org ? Was there ever a plan to put kernel-vanilla rpms up for public consumption on a regular basis? There was. The question largely came down to 'where do we host them?'. The best answer right now does seem to be $personal.fedoraproject.org I think it's worth doing this on a semi-regular basis. Probably not for every -git, but at least for every -rc and point release. I'd be more than happy to host them on my fedorapeople page. I don't have anything else there. I really don't mind who does it, and takes care of the building/uploading of them (it can mostly be automated anyway). I've not got around to doing it myself due to well, everything else. It's probably best if someone other than the usual suspects (me, kyle, chuck) did it anyway, so we can keep doing what we do normally.. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Enabling PARAVIRT stuff in Fedora kernels
On Tue, Jul 08, 2008 at 09:28:43PM -0700, Roland Dreier wrote: And actually the options I'm really hoping for are KVM_GUEST and KVM_CLOCK -- sorry for my confusion and sloppy grep for VIRT. Umm, they're also all enabled. $ grep KVM /boot/config-2.6.26-0.115.rc9.git2.fc10.x86_64 CONFIG_HAVE_KVM=y CONFIG_KVM=m CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m CONFIG_KVM_TRACE=y $ grep PARAVIRT /boot/config-2.6.26-0.115.rc9.git2.fc10.x86_64 # CONFIG_PARAVIRT_GUEST is not set Ah, yeah. See my note about x86-64 in the other mail. I'll flip it on tomorrow, and we'll see if it builds now.. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel module options for cpufreq
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 [EMAIL PROTECTED] 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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: revisit: turning some of the always used modules to built-in
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
rawhide / F10
Now that rawhide has opened up again for F10, I've moved CVS forward to 2.6.26-rc2-git5. In doing so, there were the usual ton of rejects, some of the trivial ones I fixed up, but some of the larger patches (especially the git tree snapshots) failed so much that it was easier to just disable them until their owners can find time to update them. Here's what's disabled so far: utrace assorted ppc patches selinux deferred contexts wireless at76 linux-2.6-smarter-relatime.patch atl2 drm/nouveau/modesetting uvcvideo efifb/imacfb merging lirc Execshield may need some more attention. I got it building locally, but it hasn't been boot tested at all yet, and touching that thing always makes me nervous. Oh, and the usual debugging-and-then-some config options are all back on. Now to try and get it to survive a trip through koji ... Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: OT - High amount of spam on this list
On Tue, Mar 25, 2008 at 03:33:24PM -0400, Dave Jones wrote: On Tue, Mar 25, 2008 at 12:18:38PM -0700, Andrew Farris wrote: Rui Tiago Cação Matos wrote: Hi, Is it just me that is receiving a lot of spam on this list? Other fedora lists I'm subscribed to don't seem to suffer from this. Can anyone have a look at it? No its actually going to the whole list, I get it too and they are in the archive if you go look for them. I'm on 4 redhat lists and this is the only one I get spam on though, and it comes from various people so its not just one compromised machine. I only see one spam message every couple days, so its not really that bad, but less spam is always a good thing. I've not seen anything make to to my inbox from the list that hasn't been caught by spamassassin. The posting rules to the list aren't as restricted as they are to other lists, as it's already been really useful to Cc: upstream developers (who aren't necessarily on the list) into discussions here, without having to go approve messages for every post. I just added some more taboo subjects to the mailman filter, so that might catch some of those that are slipping through. I just tweaked it some more, apologies for the last few that made it through. This time for sure.. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Add SELinux permissive domains to fedora kernels
On Mon, Mar 31, 2008 at 02:07:44PM -0400, Eric Paris wrote: I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=32021b669089eb9b264e6b26af4d9a47eb50d4f1 http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=70d212ebfdd5e39a9d4fb0f8f7ea5c38486f6b04 http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=559dbbc87d0a5d2eb88bbbea5f2b66ee2dfd55d6 Only the third patch is truly interesting. A permissive domain is a new concept in which a sysadmin can say that a given domain is free to do anything it wants. Lets say a user seriously customized httpd and they want httpd to just be allowed to run wild while still keeping enforcing for everything else in the system. With the kernel patch I want to commit and the userspace changes dan has already pushed this week they just need a simple policy which says permissive httpd_t and all their httpd_t denials become allows! One of the upstream patches adds a BUG_ON() but I'm still a teensy bit scared of it so in the F9 patch I'll probably make it a WARN_ON since it isn't really deadly to the kernel... anyway. Chances of regression here are very very low. I would just jam this in myself but we are getting really late and I wanted people to be able to tell me no before I did it. If noone strongly objects quickly expect to see a commit message early this week It is indeed, very late. I'm concerned by just how much busted stuff we have[*], so shovelling in more features after the feature freeze is making me wince. From a quick look at the patches, this is a fairly small amount of code that's changing, that looks harmless. What userspace changes are necessary for this? Are they in place already? We'll pick this up anyway in 2-3 months as an F9 update when we rebase to 2.6.26, so I guess the userspace bits will have to be done at some point, but I'd rather we spent effort beating what we have already into shape than forward planning right now. (That said, selinux is pretty solid from a kernel pov. Still some warts in policy, but Dan is nailing those pretty quickly as usual). I dunno. Dave [*] The top kerneloops.org regressions right now are all in code that's been added to Fedora that isn't upstream (yet). This is not a good sign. -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: WebCam drivers ...
On Sat, Mar 29, 2008 at 08:42:22AM +0200, Clinton Lee Taylor wrote: Greetings Hans de Goede ... I can't comment on the code, but I, and I'm sure many others welcome any effort to improve the WebCam drivers in Fedora. Many thanks. I have three USB WebCam's myself - 05a9:a511 OmniVision Technologies, Inc. OV511+ WebCam (Creative ) This one has been working for many years now with the ov511 module. - 05a9:8519 OmniVision Technologies, Inc. OV519 WebCam (D-Link) This one probably works with the out of tree variant of the same driver. (For some reason, the author stopped updating the kernel.org variant) http://ovcam.org/ov511/ (Note it may need some work to run on the latest versions of the kernel) - 046d:08c2 Logitech, Inc. should be supported by the uvcvideo module. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: OT - High amount of spam on this list
On Tue, Mar 25, 2008 at 12:18:38PM -0700, Andrew Farris wrote: Rui Tiago Cação Matos wrote: Hi, Is it just me that is receiving a lot of spam on this list? Other fedora lists I'm subscribed to don't seem to suffer from this. Can anyone have a look at it? No its actually going to the whole list, I get it too and they are in the archive if you go look for them. I'm on 4 redhat lists and this is the only one I get spam on though, and it comes from various people so its not just one compromised machine. I only see one spam message every couple days, so its not really that bad, but less spam is always a good thing. I've not seen anything make to to my inbox from the list that hasn't been caught by spamassassin. The posting rules to the list aren't as restricted as they are to other lists, as it's already been really useful to Cc: upstream developers (who aren't necessarily on the list) into discussions here, without having to go approve messages for every post. I just added some more taboo subjects to the mailman filter, so that might catch some of those that are slipping through. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
shared /boot support. bz 197065
I took a stab at bz 197065 and arrived at the patch below.
Would appreciate some eyeballs before I commit from people
familiar with the macro goo in the specfile. (Hi Roland!)
Aparently pm-utils will need a change to cope with the changed
filename, but I think that should be the limit of the damage.
(oprofile will need to append the archname on the end of System.map-$ver
filenames, but they're user-passed anyway, and not coded anywhere afaik
Hmm. Not sure about Systemtap).
Comments?
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.521
diff -u -p -r1.521 kernel.spec
--- kernel.spec 21 Mar 2008 15:27:16 - 1.521
+++ kernel.spec 24 Mar 2008 19:20:58 -
@@ -1268,15 +1268,15 @@ BuildKernel() {
mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/%{image_install_path}
%endif
mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
-install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
-install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
-touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img
+install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch}
+install -m 644 System.map
$RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch}
+touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}
if [ -f arch/$Arch/boot/zImage.stub ]; then
cp arch/$Arch/boot/zImage.stub
$RPM_BUILD_ROOT/%{image_install_path}/zImage.stub-$KernelVer || :
fi
$CopyKernel $KernelImage \
- $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
-chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
+
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer.%{_arch}
+chmod 755
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer.%{_arch}
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
KERNELRELEASE=$KernelVer
@@ -1570,7 +1570,7 @@ fi\
#
%define kernel_variant_posttrans(s:r:v:) \
%{expand:%%posttrans %{?-v*}}\
-/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*} || exit $?\
+/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*}.%{_arch} || exit $?\
%{nil}
#
@@ -1587,7 +1587,7 @@ if [ `uname -i` == x86_64 -o `uname -i
[ -f /etc/sysconfig/kernel ]; then\
/bin/sed -i -e 's/^DEFAULTKERNEL=%{-s*}$/DEFAULTKERNEL=%{-r*}/'
/etc/sysconfig/kernel || exit $?\
fi}\
-/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod
--install %{?1} %{KVERREL}%{?-v*} || exit $?\
+/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod
--install %{?1} %{KVERREL}%{?-v*}.%{_arch} || exit $?\
#if [ -x /sbin/weak-modules ]\
#then\
#/sbin/weak-modules --add-kernel %{KVERREL}%{?-v*} || exit $?\
@@ -1600,7 +1600,7 @@ fi}\
#
%define kernel_variant_preun() \
%{expand:%%preun %{?1}}\
-/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}%{?1} || exit $?\
+/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}%{?1}.%{_arch}
|| exit $?\
#if [ -x /sbin/weak-modules ]\
#then\
#/sbin/weak-modules --remove-kernel %{KVERREL}%{?1} || exit $?\
@@ -1668,10 +1668,9 @@ fi
%if %{1}\
%{expand:%%files %{?2}}\
%defattr(-,root,root)\
-/%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?2}\
-/boot/System.map-%{KVERREL}%{?2}\
-#/boot/symvers-%{KVERREL}%{?2}.gz\
-/boot/config-%{KVERREL}%{?2}\
+/%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?2}.%{_arch}\
+/boot/System.map-%{KVERREL}%{?2}.%{_arch}\
+/boot/config-%{KVERREL}%{?2}.%{_arch}\
%{?-a:%{-a*}}\
%dir /lib/modules/%{KVERREL}%{?2}\
/lib/modules/%{KVERREL}%{?2}/kernel\
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Mon, Mar 24, 2008 at 03:46:44PM -0400, Kyle McMartin wrote: On Mon, Mar 24, 2008 at 03:38:38PM -0400, Jeremy Katz wrote: On Mon, 2008-03-24 at 15:32 -0400, Dave Jones wrote: I took a stab at bz 197065 and arrived at the patch below. Would appreciate some eyeballs before I commit from people familiar with the macro goo in the specfile. (Hi Roland!) Aparently pm-utils will need a change to cope with the changed filename, but I think that should be the limit of the damage. (oprofile will need to append the archname on the end of System.map-$ver filenames, but they're user-passed anyway, and not coded anywhere afaik Hmm. Not sure about Systemtap). I have this sinking suspicion that more things depend on the filenames, although I'm not coming up with what at the moment... We could use systemtap to run for a while with this set and watch to see if anything boinks the wrong file? I'm running a tree-wide grep right now, and it's already picked up anaconda, bootchart, booty apt. I expect kexec-tools, and yum will probably be in the list too. I'm starting to wonder if this is worth it for such a small use-case. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: vfat filesystem fix breaks rpm kernel install on ia64
On Fri, Feb 29, 2008 at 10:16:00AM -0600, Matt Domsch wrote:
On Thu, Feb 28, 2008 at 10:00:32PM -0500, Doug Chapman wrote:
Actually I came up with what I think is a cleaner fix for this. Since
the default file permission on files on vfat are 755 anyway if the
kernel is mode 755 rpm doesn't complain.
Anybody have thoughts on this specfile change? I build this as a
scratch build on our ia64 koji server and it installs cleanly.
- Doug
*** kernel.spec.bad2008-02-28 19:58:55.0 -0500
--- kernel.spec2008-02-28 21:39:57.0 -0500
*** BuildKernel() {
*** 1301,1306
--- 1301,1310
$CopyKernel $KernelImage \
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
+ %ifarch ia64
+ chmod 755
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
+ %endif
+
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
KERNELRELEASE=$KernelVer
%ifarch %{vdso_arches}
There are systems with EFI32 and EFI64 out there, that aren't ia64,
but that will likewise be dropping files into a vfat file system.
I don't see any problem in unconditionally doing the chmod. Anyone else?
Dave
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: vfat filesystem fix breaks rpm kernel install on ia64
On Fri, Feb 29, 2008 at 01:23:02PM -0500, Doug Chapman wrote:
+ chmod 755
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
There are systems with EFI32 and EFI64 out there, that aren't ia64,
but that will likewise be dropping files into a vfat file system.
I don't see any problem in unconditionally doing the chmod. Anyone else?
I can't actually think of any reason this would break on other
platforms. I added the %ifarch ia64 just in case because I really
don't want to be that ia64 guy who breaks everyone else's stuff.
I just committed the change to devel. We'll see tomorrow, but I'll be
really surprised if anything at all cares that the vmlinuz grew an x bit.
Dave
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rpms/kernel/devel kernel.spec,1.445,1.446
On Thu, Feb 21, 2008 at 01:08:19PM -0500, Peter Jones wrote: Author: pjones Update of /cvs/extras/rpms/kernel/devel In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30850 Modified Files: kernel.spec Log Message: * Thu Feb 21 2008 Peter Jones [EMAIL PROTECTED] - Require newer mkinitrd version. Bah. Given rawhide has been perpetually fscked for months on end, a lot of us have been running the F9 kernel on F8. This change breaks that unless we --nodeps. Any chance you can backport that mkinitrd to F8 ? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Disable CONFIG_ACPI_SYSFS_POWER?
On Mon, Feb 18, 2008 at 11:25:40AM -0500, Kyle McMartin wrote: On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote: On 02/16/2008 06:53 AM, drago01 wrote: Hi, I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build directly) on my laptop. Hal detects two batteries because it looks in sysfs and in procfs for the battery info. I tryed to apply the patch from the hal-list which causes hal to not look in procfs but in sysfs only when the sysfs info is available. The problem with this is that the info in sysfs is broken (capcity 3.0 Wh etc while the procfs info is correct 45Wh). I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs info already provides this data for userspace and does not report broken values. We should be enabling either one or the other, not both. my logic was people could be running rawhide kernels on old userspace (i do this, for instance.) actually that's a really good point, given how bad rawhide has been lately at being installable. I do the same thing btw (f9 kernel on f8) because of this, and hadn't picked up on this breakage because my laptop runs f8 kernel. For Fedora 9 maybe it should be the sysfs interface if it works. i don't really see a harm in having both. I imagine that eventually someone upstream will make the decision a no-brainer by removing the proc stuff. Not shipping it does mean that nothing new will start depending on it. (Unlikely I know, but still...) For 8 it should be only procfs to be backwards compatible. I'll do that. agreed, don't want to tempt fate on f8... ACK. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Disable CONFIG_ACPI_SYSFS_POWER?
On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote: On 02/16/2008 06:53 AM, drago01 wrote: Hi, I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build directly) on my laptop. Hal detects two batteries because it looks in sysfs and in procfs for the battery info. I tryed to apply the patch from the hal-list which causes hal to not look in procfs but in sysfs only when the sysfs info is available. The problem with this is that the info in sysfs is broken (capcity 3.0 Wh etc while the procfs info is correct 45Wh). I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs info already provides this data for userspace and does not report broken values. We should be enabling either one or the other, not both. For Fedora 9 maybe it should be the sysfs interface if it works. For 8 it should be only procfs to be backwards compatible. I'll do that. Yeah, you need a new enough hal aparently, which I guess f8 didn't have. F9 should be safe to be using just the sysfs stuff. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: enable CONFIG_SECURITY_MMAP_MIN_ADDR
On Thu, Feb 14, 2008 at 12:29:18PM -0500, Eric Paris wrote: My (minimal) testing of wine indicated that it did try to make use of mapping the low pages but it still worked when it couldn't map them Hmm. Graceful fallback is good, but I wonder if it's now using a slower path or something. I guess I should bring it up with the wine community to get a better understanding of exactly why they are trying to map those pages and how it handles those failures (in my case it handled them quite nicely) Well lets set it to 0 across all archs, and see if anything else stops working. Hopefully this is the extent of the breakage. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
rawhide -debug
A discussion came up at LCA about the fact that we have debugging 'always on' in rawhide kernel builds, and that it causes some people pain, because anyone wanting to do performance testing for eg needs to rebuild their kernel without all the debugging bits. An idea that was tossed around was to do something similar to what we do in release builds, and offer separate debug/nodebug builds. But instead of how we do it in releases, do the opposite, and have a -nodebug build, whilst keeping the regular kernel debug-turned-on to maximise coverage testing. Downside being that we have one extra flavor to build each day. (more disk space used, more buildsys time etc). Another option is that we do something like turning debug on/off periodically (though this idea wasn't well recieved, unless it was really easy to determine if a debug-enabled kernel was running. Some people want to run automated perf-tests) comments? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide -debug
On Wed, Feb 13, 2008 at 11:53:34PM +, Christopher Brown wrote: I'm a newbie in this but http://fedoraproject.org/wiki/KernelCommonProblems indicates slab debugging can be disabled using: slub_debug=- Is this true and if so does this affect things at all? The barrier to getting a debug variant is pretty low so I'm really not fussed either way. This only recently became a runtime thing, but there's still a bunch of performance impacting options that aren't runtime selectable (like lockdep for example). Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: selinux patch
On Mon, Feb 11, 2008 at 09:32:29AM -0500, Stephen Smalley wrote: Could the patch below (already in Linus' git tree for 2.6.25) be added to the rawhide kernel? It is to support polyinstantiation by XACE/XSELinux. fwiw, rawhide should be moving to .25rc1-git sometime this week. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: importing 2.6.25-rc1
On Mon, Feb 11, 2008 at 12:53:40PM -0500, Kyle McMartin wrote: M linux-2.6-e1000-corrupt-eeprom-checksum.patch somewhat upstream... i merged-ish it, upstream version needs you to reset the mac address with ip which is kind of loss. why has nobody root-caused this failure yet? :/ I spoke with DaveM about this at LCA. Aparently we don't need it anymore. M linux-2.6-devmem.patch fixed rejects... maybe needs merging upstream needs to be dropped in favour of the version arjan is pushing upstream (might be too late for .25, but probable .26 material) Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: GFS2/Rawhide
On Fri, Jan 25, 2008 at 10:20:49AM +, Steven Whitehouse wrote: Hi, Could someone take the GFS2 patch for F-8 and add it to rawhide as well please. We need to continue to support this patch for the time being, although it does look like this issue might be solved in the not too distant future by moving the lm_interface shim into GFS (duplicating it) so hopefully this might be the last version of Fedora that requires this patch. The name of the patch in F-8 is linux-2.6-gfs-locking-exports.patch I removed it because it seems that we're no longer building gfs1 for rawhide anyway, and I don't think I've heard of a single Fedora user actually using it in a long time. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFC: Minor specfile rework for rawhide
On Mon, Jan 21, 2008 at 11:20:17PM -0500, Jarod Wilson wrote: Christopher Brown wrote: On 21/01/2008, Adam Jackson [EMAIL PROTECTED] wrote: http://people.freedesktop.org/~ajax/kernel-autopatch.patch Based on something I did for the xserver specfile. Essentially this makes it so you only have to name the patches once, in the order you want to apply them, which makes it both easier to work with and harder to forget things. I've tried to make this as friendly and robust as possible, including bailing out appropriately when faced with a bad patch, and explicitly naming patches that fail to apply right at the end of build output. Feedback would be appreciated, even if it's of the form no, that's gross. First glance says oh hell yeah, check it in. The magic to only apply linux-2.6-compile-fixes.patch if there's something in the file disappeared, but other than that it looks ok to me too. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFC: Minor specfile rework for rawhide
On Tue, Jan 22, 2008 at 01:47:09PM -0500, Chuck Ebbert wrote: On 01/21/2008 05:22 PM, Adam Jackson wrote: http://people.freedesktop.org/~ajax/kernel-autopatch.patch Using the below script, based on what you suggested, we can add lines like this to specify patch options: Patch101: a.patch PATCH101_OPTS=-R -F2 And this to skip a patch: Patch101: a.patch PATCH101_OPTS=SKIP With this change I'd say go for it. The amount of voodoo in the kernel spec file is both scary, and awesome at the same time. I love it :) Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
debuginfo ppc.
So I got wondering why PowerPC debuginfos are so much bigger than x86. -rw-rw-r-- 1 davej davej 30739918 2007-12-11 20:58 kernel-debuginfo-common-2.6.24-0.56.rc3.git3.fc9.i686.rpm -rw-rw-r-- 1 davej davej 82997941 2007-12-11 21:02 kernel-debuginfo-common-2.6.24-0.56.rc3.git3.fc9.ppc64.rpm -rw-rw-r-- 1 davej davej 70527491 2007-12-11 21:08 kernel-debuginfo-common-2.6.24-0.56.rc3.git3.fc9.ppc.rpm -rw-rw-r-- 1 davej davej 29881807 2007-12-11 21:06 kernel-debuginfo-common-2.6.24-0.56.rc3.git3.fc9.x86_64.rpm I browsed a few of the internals, and it looks like the ppc variant includes a complete source tree in /usr/src/debug Any reason for ppc being different? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Precision 490 Reboot Hang
On Thu, Dec 06, 2007 at 04:33:56PM -0500, Thomas J. Baker wrote: I've got a Precision 490 that hangs at reboot unless I use reboot=bios on the kernel command line. A bug filed against the kernel should include what other information? dmidecode output. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Getting rid of sysprof-kmod
On Sun, Dec 02, 2007 at 01:02:23AM +0100, Gianluca Sforna wrote: Hi, I just finished removing the sysprof-kmod package from CVS as mandated by the new guidelines for F9 and above. I am now seeking some help to understand what is needed to have again the kernel module required for proper operations of the sysprof package. Upstream sources are at: http://www.daimi.au.dk/~sandmann/sysprof/ The upstream kernel is likely to eventually get support for perfmon2 integrated, but this could really use more work. It's been in -mm for a while. If there's anything that sysprof can do that perfmon can't (which would be surprising given perfmons featuritis) it would useful to talk with the perfmon developers so we can eventually arrive at an upstreamed solution and not have to worry about integrating out-of-tree patches. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Getting rid of sysprof-kmod
On Sun, Dec 02, 2007 at 02:04:01AM -0500, David Zeuthen wrote: Upstream sources are at: http://www.daimi.au.dk/~sandmann/sysprof/ The upstream kernel is likely to eventually get support for perfmon2 integrated, but this could really use more work. It's been in -mm for a while. If there's anything that sysprof can do that perfmon can't (which would be surprising given perfmons featuritis) it would useful to talk with the perfmon developers so we can eventually arrive at an upstreamed solution and not have to worry about integrating out-of-tree patches. Until that happens can we please carry the patch in the Fedora kernel? IIRC it's not invasive at all. And it's really annoying not being able to use sysprof. Thanks. The problem is I really hate adding patches that provide new user interfaces. It's easy enough to add it, but it'll be a 'fedora-ism' that doesn't work in any other distro, or with an upstream kernel. And what happens if someone starts building more things on top of the sysprof exports? It's the same reason patches that add syscalls get vetoed. We don't want to be in a situation where it appears we're locking users into running our distro/kernel. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: i686 build on x86_64 fails
On Wed, Nov 28, 2007 at 12:29:28AM -0800, Pete Zaitcev wrote: Just FYI, I found that it's not possible to build an i686 kernel on x86_64 (in 2.6.23.1-42.fc8), because this happens: + gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=generic -fasynchronous-unwind-tables -o scripts/modsign/mod-extract scripts/modsign/mod-extract.c In file included from /usr/include/features.h:359, from /usr/include/stdio.h:28, from scripts/modsign/mod-extract.c:12: /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory It's not important why stubs-32.h does not exist in glibc-headers. The problem is using -m32 for a host executable, because the kernel.spec has this: gcc $RPM_OPT_FLAGS -o scripts/modsign/mod-extract scripts/modsign/mod-extract.c I suspect that hardcoding gcc -O would work just dandily, but on the other hand it's unclear if we want to bother fixing it. Thoughts? Just nuke the line completely, and turn off module signing. (It's already gone in devel/) Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rpms/kernel/devel kernel.spec,1.251,1.252 config-generic,1.42,1.43
On Mon, Nov 26, 2007 at 07:37:34AM -0500, David Woodhouse wrote: -# CONFIG_LIBERTAS is not set - +CONFIG_LIBERTAS=m +CONFIG_LIBERTAS_USB=m +CONFIG_LIBERTAS_CS=m +CONFIG_LIBERTAS_SDIO=m +CONFIG_LIBERTAS_DEBUG=y This is probably better placed in a per-arch override rather than building it everywhere no? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rpms/kernel/devel kernel.spec,1.251,1.252 config-generic,1.42,1.43
On Mon, Nov 26, 2007 at 12:52:43PM -0500, Dave Jones wrote: On Mon, Nov 26, 2007 at 07:37:34AM -0500, David Woodhouse wrote: -# CONFIG_LIBERTAS is not set - +CONFIG_LIBERTAS=m +CONFIG_LIBERTAS_USB=m +CONFIG_LIBERTAS_CS=m +CONFIG_LIBERTAS_SDIO=m +CONFIG_LIBERTAS_DEBUG=y This is probably better placed in a per-arch override rather than building it everywhere no? That's my point, do we /want/ to build it everywhere? Is it likely to show up on ia64, sparc64, ppc64 etc etc? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: vanilla/ changes in devel.
On Thu, Nov 15, 2007 at 02:53:45PM -0500, Dave Jones wrote: I just checked something into devel/ that changes how we 'make prep'. Before, under kernel-2.6.23/ we had a vanilla dir and a fedora-patched dir called linux-2.6.23.noarch The vanilla dir used to be just the unpacked tarball. With the change I just checked in, that dir is now patched up to the latest upstream (ie, 2.6.24rc2-git5 right now). This speeds up subsequent make preps quite a bit as the -rc's increase in size. The downside (and reason for this heads up) is that anyone with an existing checkout will find that make prep will now fail to apply patches as the specfile expects vanilla in the new form. rm -rf kernel-2.6.23 and make prep again, and it'll all just work out. I tweaked this some more. I found that I'd have had to have done that rm -rf every day when I rebased, which is less than fun. So now the 'vanilla' dir has the version postfixed to it. The downside is that this means that the kernel-2.6.23/ dir will get a bit cluttered over time with lots of symlink'd trees in your local checkouts, but it will dtrt. There's room for a further optimisation which I'm too lazy to do right now, and that's to have a separate vanilla-$ver dir for both the -rc and the -git if present. This way rebasing to a new -git will use the previous vanilla-rc tree if present instead of regenerating it from scratch. the %prep is also getting a bit messy with all of this hackery, so I'll probably end up cleaning it all up when I get around to doing that optimisation. Seems to work right now though. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: sparse 0.4.1
On Wed, Nov 14, 2007 at 01:20:13PM -0800, Roland McGrath wrote: Dave asked me to ping when sparse got updated. 0.4.1 is built, [78] updates should get pushed RSN. This presumably works with the kernel source again. Cool, I'll reeanble it. I can't do rawhide builds right now due to breakage in curl preventing 'make upload' from working. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: install System.map in kernel-devel
On Tue, Oct 23, 2007 at 06:26:21PM -0400, Chuck Ebbert wrote: On 10/23/2007 09:05 AM, Roland McGrath wrote: The systemtap folks are interested in having System.map installed by kernel-devel, not just by the kernel rpm itself. This makes it possible to do more preparations off-line for a kernel other than an installed one. Without objection, I'll check this in on all branches. Are the addresses in System.map accurate? On the F7 2.6.23 kernel, I had to subtract 0x40 and add 0x100 to the address in an oops message to get an address to use with eu-addr2line. Relocatable kernel is another thing that really screws with this. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
F8 branched.
CVS has now been branched. For stuff going into F-8, make sure it gets committed to the F-8/ branch. devel/ will move on towards tracking 2.6.24 soon. I'll commit something to devel/ today to make this clear and reduce opportunity for screwups, but I'm not going to spend a huge amount of time fixing it up/tracking -git just yet, whilst we still have opportunity to make F-8 suck less. http://fedoraproject.org/wiki/Releases/8/Schedule shows that we have until the 17th as the absolute latest to get fixes in. Typically I like to take the day prior to the freeze as the 'last patch day', to give a day of breathing room for any last minute screwups, (given that rawhide on the 17th will be the build from the 16th). [There's nearly always something that needs a last minute change, but lets not rely on the fact that there'll be a build on the 17th] So if you're sitting on anything for F-8, please have it merged up by Tuesday. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFE: Switch usbhid.pb_fnmode to 2 for Macbook Pro users
On Thu, Sep 27, 2007 at 09:11:38PM +0100, Christopher Brown wrote: Hello, It would appear Macbook Pro users need to additionally press the fn key to make F1 - F10 work as expected under Linux. Therefore to switch to a vt they have to perform a wierd kind of hand twister to get it to work as it now requires Ctrl+Alt+Fn+F1. Macbook user Alexey Kuznetsov wrote to me and said: To solve this problem i send echo 2 to /sys/module/hid/parameters/pb_fnmode every time on boot. But i this is a good idea to set this feature by default for all fedora 7 users. I solve it by small startup service here is ti: #!/bin/bash # # chkconfig: 12345 90 01 # description: fix apple fn keys . /etc/init.d/functions echo 2/sys/module/hid/parameters/pb_fnmode action Starting the Mac Function keys fix: to which I replied: ... you can also just add: options usbhid pb_fnmode=2 to modprobe.conf and I think: usbhid.pb_fnmode=2 being added to the kernel parameters as well. I will post an RFE to the fedora-kernel list. Is it possible to enable this by default - the green lizards seem to have done so: https://bugzilla.novell.com/show_bug.cgi?id=220266 I wonder why its not the default already. Seems Novell didn't push that change upstream in the last year either. I'd suggest bringing this up on the [EMAIL PROTECTED] list. Perhaps someone responsible for the hid code will be able to give you an answer as to why this change hasn't happened. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
IRC.
I've created a #fedora-kernel channel on freenode in response to the large number of /msg's I continue to get which really should be going to a wider audience. I expect it to be low-traffic, but it may be a worthwhile experiment to see if it helps any for triage, coordination etc. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: IRC.
On Fri, Sep 21, 2007 at 04:23:57PM +0100, Christopher Brown wrote: On 21/09/2007, Dave Jones [EMAIL PROTECTED] wrote: I've created a #fedora-kernel channel on freenode in response to the large number of /msg's I continue to get which really should be going to a wider audience. I expect it to be low-traffic, but it may be a worthwhile experiment to see if it helps any for triage, coordination etc. Is there any value is punting out a message to fedora-test to get more people on the case with triaging? Yeah, can't hurt. I'm getting to the point now where bugs aren't so old any more therefore people remember why they filed, can still replicate the bug so the process rate is slowing somewhat. When you say /msg do you mean people in IRC or bugzilla emails about bug status changes. People. Is it worth setting up a bugzilla monitor to show status changes to kernel bugs? There's always #fedorabot (though that shows bug changes to all packages). Perhaps we could get whoever controls it to join #fedora-kernel too if it can be trained to only talk about kernel bugs, though I'm not sure if it'll be annoying or not. Opinions? Also, is it worth setting mailman to change the reply-to address so it goes to the list rather than the poster a-la -devel and -test? I try to stay out of that argument as much as possible, as it seems have vocal proponents/opponents on both sides, and tbh, I don't think there's a way that'll please everyone. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Enabling Secure Computing (SECCOMP)
On Wed, Sep 19, 2007 at 03:48:57PM -0400, Jarod Wilson wrote: Chuck Ebbert wrote: We have a bug report requesting that we enable SECCOMP: https://bugzilla.redhat.com/show_bug.cgi?id=295841 I suggest we enable it in Fedora 8 but leave it disabled in F7. That way we're not changing a config item in a stable release, and we don't have to carry patches to lower the feature's overhead and make its API match 2.6.23's. Saw that one too. Turning it on just in F8 sounds sane to me. The reasons against it in the past were that it slowed down the common case (people who aren't using the feature) I don't know if this is still a relevant objection, Ingo? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
-vanilla builds.
I'd like to move forward on us getting vanilla builds out for testers.
There are a couple things worth thinking about, which I'd like other
peoples thoughts on.
* The location of the binaries - I think we ended up settling
on putting them on people.fedoraproject.org.
Given the 150MB quota, this probably means...
- no -debuginfo packages. (not a huge deal)
- probably just x86/x86-64 to begin with.
- probably no non-debug variants (ie, same model
as rawhide, with debug 'always on'
- worth doing PAE and non-PAE ? just one? which?
* how/where to building them.
AFAIK, it isn't possible to pass switches like --with-vanilla
to koji, so the two options are..
- build vanilla as part of the regular build
(not a great idea, it already takes hours to build
a complete set of kernels).
- I kick off a bunch of rpmbuilds locally and push them
by hand. (scriptable at least, so not such a big deal).
I think this is the best option.
* frequency of updates.
I don't think it's really worthwhile doing daily builds.
Doing at least one per -rc is probably a good target,
with perhaps a -rcN-git build periodically if the next
-rc is taking a while to land.
* dependancies.
This is the only remaining technical puzzle I think.
I'd like the vanilla rpms to install on FC6, F7, and rawhide.
Doing separate builds per distro is just going to kill me.
The only thing stopping this from working is requires: lines
like ..
%define kernel_prereq fileutils, module-init-tools, initscripts =
%8.11.1-1, mkinitrd = 6.0.9-7
I'm thinking perhaps something like..
%if ! %{with_vanilla}
%define kernel_prereq fileutils, module-init-tools, initscripts =
%8.11.1-1, mkinitrd = 6.0.9-7
%else
%define kernel_prereq fileutils, module-init-tools, initscripts, mkinitrd
%endif
might do the trick.
However for some cases, those versioned dependancies are there for a reason,
and I'm
not entirely sure what to do about them. I'd rather not have to
build non-kernel packages for the vanilla repo too.
Ideas ?
Ideally I'd like to get to a state where these are built
by a cronjob on my desktop that checks for a new rc,
and uploads new updates whilst I sleep^Wdo something else.
Dave
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
bugzilla triage.
The current state of bugzilla for the kernel is pretty depressing. Counting in all the bugs we never fixed for FC5 (a lot of which are probably still valid for everything through to rawhide), there are around 1600 open bugs. In an attempt to disperse some of the 'triage' type work to volunteers, I've started a page at http://fedoraproject.org/wiki/KernelBugTriage with some simple things that people can do to help out. Any additions/improvements welcomed. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: -vanilla builds.
On Thu, Aug 30, 2007 at 06:52:41AM +0200, Thorsten Leemhuis wrote: On 29.08.2007 21:05, Dave Jones wrote: I'd like to move forward on us getting vanilla builds out for testers. I'm willing to help here if there is anything I can do. There are a couple things worth thinking about, which I'd like other peoples thoughts on. * The location of the binaries - I think we ended up settling on putting them on people.fedoraproject.org. My vote is still to ship them in the proper repos -- an idea lot of people liked in last weeks discussion here. But people feared the space requirements. But that's a problem on p.f.o as well afaics. Nearly everyone else I've talked to about this seems to be against that idea for whatever reasons. * how/where to building them. AFAIK, it isn't possible to pass switches like --with-vanilla to koji, so the two options are.. - build vanilla as part of the regular build (not a great idea, it already takes hours to build a complete set of kernels). How about a different package kernel-vanilla in CVS that can be build independently of the normal build? This means committing rebases to 1 place, which sounds like losing. It doesn't really bring any advantages either afaics. [...] * dependancies. This is the only remaining technical puzzle I think. I'd like the vanilla rpms to install on FC6, F7, and rawhide. Doing separate builds per distro is just going to kill me. But often needed, as people otherwise often can't build kernel modules theirselfs, as GCC doesn't match (it does currently iirc, but often there are different major versions of gcc in the different distros. 3rd party modules for kernel-vanilla brings up an interesting question. For bugs found in kernel-vanilla, I want *everything* to go to linux-kernel or bugzilla.kernel.org. If reports there contain any out-of-tree modules, they'll get closed out no questions asked. AFAIAC, 3rd party modules are even less supportable on -vanilla than they are on the regular fedora kernel. For the minority that can't live without 3rd party modules, they can build their own kernels, because building a full set of kernels for each distro is time consuming enough that I only want to do this once. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: The NFS nosharecache patch in F7 is broken
On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote: If people try mounting several exports from the same filesystem, it fails with confusing error messages if the mount options are different for some of the mount points. Adding nosharecache to the mount options fixes that, but people with working setups suddenly find they need this new option to use a setup that used to work without it. Should we just revert that patch? Adding steved to cc (I don't think he's on the list). Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: MSI and MMCONFIG, again...
On Thu, Aug 09, 2007 at 03:36:54PM -0400, Chuck Ebbert wrote: On 08/08/2007 10:50 PM, Dave Jones wrote: On Wed, Aug 08, 2007 at 01:41:57PM -0400, Chuck Ebbert wrote: On 08/08/2007 01:28 PM, Prarit Bhargava wrote: We are still hitting problems with MSI (and probably mmconfig) with kernel 2.6.22: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249469 Should we just go back to disabling these by default? Chuck -- how long have we had this re-enabled? What about (groan) doing quirks for msi/mmconfig? They were re-enabled with the new 2.6.22 kernels for Fedora 6 and 7. And there are quirks in there now, I guess the list just isn't complete (and probably never can be.) Weren't there other newer devices that need MSI on ? Some of the infiniband stuff maybe? As painful as it is, additional quirks would be the best all-round solution I think. I think it would be best to turn MSI off in FC6, where it's already been off for a long time anyway. Might be useful to do that as a comparison too. If a bug goes away on FC6, and sticks around on later releases, whilst we're on the same codebase, we should be able to spot MSI failures a little easier. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: pre-release kernel release tag
On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote: I propose we change the release format for snapshot kernels. Now we get e.g.: kernel-2.6.23-0.89.rc2.git2.fc8 and I suggest instead: kernel-2.6.23-0.rc2.git2.89.fc8 That is, put the spec file version number last, not first. This way, when we forget to reset fedora_cvs_origin after a rebase, we don't have to wait for the next kernel version to do it, just the next gitN. Is it that big a deal? I intended to only reset the origin after each point release, so it doesn't really buy us anything being able to change this with every -git. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: pre-release kernel release tag
On Thu, Aug 09, 2007 at 02:24:44PM -0700, Roland McGrath wrote: On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote: I propose we change the release format for snapshot kernels. Now we get e.g.: kernel-2.6.23-0.89.rc2.git2.fc8 and I suggest instead: kernel-2.6.23-0.rc2.git2.89.fc8 That is, put the spec file version number last, not first. This way, when we forget to reset fedora_cvs_origin after a rebase, we don't have to wait for the next kernel version to do it, just the next gitN. Is it that big a deal? I intended to only reset the origin after each point release, so it doesn't really buy us anything being able to change this with every -git. It's not a big deal, it's only numbers. The motivation was that it didn't get reset when we went from 2.6.22 to 2.6.23, and after one build hits rawhide, it's too late. For rawhide, I don't think it really matters too much. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
