[RFC PATCH] Disable alsa snd-pcsp driver
Because ... why would you want to use this? Ever? Bill ? diff ? kern.diff ? linux-2.6.28.tar.bz2 ? patch-2.6.29-rc8-git6.bz2 ? patch-2.6.29-rc8.bz2 Index: config-generic === RCS file: /cvs/extras/rpms/kernel/devel/config-generic,v retrieving revision 1.314 diff -u -r1.314 config-generic --- config-generic 28 Jul 2009 13:35:42 - 1.314 +++ config-generic 29 Jul 2009 14:52:04 - @@ -2659,7 +2659,7 @@ CONFIG_SND_NM256=m CONFIG_SND_OXYGEN=m CONFIG_SND_RME32=m -CONFIG_SND_PCSP=m +# CONFIG_SND_PCSP is not set CONFIG_SND_PCXHR=m CONFIG_SND_RIPTIDE=m CONFIG_SND_RME96=m ___ 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
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. Bill ___ 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
Dave Jones (da...@redhat.com) said: Oh, I thought that proposal got shot down. The proposal to have the baseline be i686 + SSE2 was shot down; bare i686 was approved. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[PATCH] build a 'full' package on i686
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 @@ -249,9 +248,9 @@ %define with_perf 0 %endif -# no need to build headers again for these arches, -# they can just use i586 and ppc64 headers -%ifarch i686 ppc64iseries +# no need to build headers again for this arch, +# they can just use ppc64 headers +%ifarch ppc64iseries %define with_headers 0 %endif ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
Thorsten Leemhuis (fed...@leemhuis.info) said: Yes -- all that have kernel.i686 installed now would get the new kernel.i686 later (the one with PAE). But the latter will not boot on all machines where the curret kernel.i686 works. If there is no kernel.i686 (because it is named kernel-PAE.i686), then yum/anaconda will automatically install kernel.i586, which is what should happen to make sure all system still boot after updating. But maybe some yum/anaconda plugin/magic could automatically select the best kernel on update. Not sure, but something like that might be needed for Live-CD-Installs anyway We could invent a new rpm arch. This may not be practical, though. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
Thorsten Leemhuis (fed...@leemhuis.info) said: I don't see how this is a problem. Getting rid of the suffix -PAE afaics would solve exactly the problem that now is just exposed to more people (or might make solving it a lot easier afaics). Well, the problem is that you'd have to define a way that the now PAE-ful kernel.i686 is not installed on some i686 boxes. That gets a lot more complicated. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: module-init-tools v3.6 released
Jon Masters (j...@redhat.com) said: This works fine, but means that, if we upgrade module-init-tools and there is a binary format change, then the system will be slow booting before depmod has been re-run again. I'm thinking about just doing a depmod -a on upgrade in such cases in the future...is there a problem with that idea? Given the (presumable) infreqeuency of file format updates, especially compared to kernel updates, I wouldn't necessarily bother with it. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: crash with iwl3945/iwlagn; fix is in 2.6.28, can it be provided to 2.6.27?
Pete Zaitcev (zait...@redhat.com) said: Intel has produced a patch, and John Linville has applied this to the 2.6.28 kernel (available from koji), but it now sounds like 2.6.28 might not make it out soon, or ever. Can this fix be applied to the 2.6.27 branch? Maybe the -stable team will pick it, so we'd get it automatically? We should still add it in the meantime (there are other dups in bugzilla, such as #480701) - it's very common hardware, and at least when I was seeing it I was repeatedly getting hard panics requiring reboot within 1-2 minutes of the wireless interface being enabled. Bill ___ 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?
Dave Jones (da...@redhat.com) said: 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 anaconda-devel-list, actually. But I could have sworn we already did this. Bill ___ 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?
Avi Kivity (a...@redhat.com) said: 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. Sure, I had a T40 that had 1.5GB of memory in it, and it could have taken more. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[PATCH] build in microcode driver on x86
It doesn't really gain anything from being static, aside from requiring odd udev rules and/or init scripts to load it. Bill ? diff ? kernel-2.6.27 ? linux-2.6.26.tar.bz2 ? linux-2.6.27.tar.bz2 ? patch-2.6.27-rc7-git3.bz2 ? patch-2.6.27-rc7.bz2 ? patch-2.6.28-rc9-git1.bz2 ? patch-2.6.28-rc9.bz2 Index: config-x86-generic === RCS file: /cvs/extras/rpms/kernel/devel/config-x86-generic,v retrieving revision 1.60 diff -u -r1.60 config-x86-generic --- config-x86-generic 13 Jan 2009 21:22:54 - 1.60 +++ config-x86-generic 14 Jan 2009 18:16:20 - @@ -64,7 +64,7 @@ CONFIG_I8K=m CONFIG_SONYPI=m CONFIG_SONYPI_COMPAT=y -CONFIG_MICROCODE=m +CONFIG_MICROCODE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_EDD=m Index: config-x86_64-generic === RCS file: /cvs/extras/rpms/kernel/devel/config-x86_64-generic,v retrieving revision 1.63 diff -u -r1.63 config-x86_64-generic --- config-x86_64-generic 13 Jan 2009 21:22:54 - 1.63 +++ config-x86_64-generic 14 Jan 2009 18:16:20 - @@ -18,7 +18,7 @@ # CONFIG_IA32_AOUT is not set # CONFIG_IOMMU_DEBUG is not set CONFIG_DEBUG_RODATA=y -CONFIG_MICROCODE=m +CONFIG_MICROCODE=y CONFIG_SWIOTLB=y CONFIG_CALGARY_IOMMU=y CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] build in microcode driver on x86
Dave Jones (da...@redhat.com) said: On Wed, Jan 14, 2009 at 01:17:38PM -0500, Bill Nottingham wrote: It doesn't really gain anything from being static, aside from requiring odd udev rules and/or init scripts to load it. We had this discussion yesterday on irc, but I never really got this in my head. It works ok with microcode.dat, but what happens if Intel release an update in /lib/firmware/intel-ucode/$f-$m-$s format ? The driver will do a request_firmware, but if we build the driver in, we'll be in the initrd, where that file won't exist. To make it work, we'll either have to.. - have the firmware in the initramfs or - pretend the request_firmware didn't happen, and have the initscript continue to do the microcode_ctl Which direction are we moving in ? AIUI, the driver's firmware request will get kicked off again when udev triggers all the normal coldplug events. So, that should be handled OK. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] build in microcode driver on x86
Adam Jackson (a...@redhat.com) said: Do we have any way of querying the kernel for firmware requests it will itself make? I don't think we do, let alone the ability to notice pattern matches like f/m/s. There's the MODULE_FIRMWARE tag, but it obviously doesn't handle runtime-generated firmware names. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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. Bill ___ 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!
Jon Masters ([EMAIL PROTECTED]) said: Really? Do you have actual stats for the number (percentage) of Fedora users that *actually* need to update their modules (as opposed to following some blindly ridiculous message-board advice...) Nope. I'm just taking the viewpoint that users shouldn't be artificially restricted from doing so. I know this isn't the case right now ... come back when there's actual data and a usage case. proposed modules being built-in are fairly harmless, but I'm raising this now before users can't build their own graphics drivers or whatever else they would like to add to their system, based on choice. Linux is not about choice. Giving users the choice between 3 versions of a driver, or ten different desktops, or three different printing systems only means that *you've* made the choice to have your OS fail. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide patches.
Dave Jones ([EMAIL PROTECTED]) said: linux-2.6-defaults-fat-utf8.patch Drop? Isn't this a local choice similar to the later ones? 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? Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
(no subject)
Subject: Re: de-modularising for the win! Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.5.18 (2008-05-17) Jeremy Katz ([EMAIL PROTECTED]) said: On Thu, 2008-09-18 at 16:13 -0700, Bill Nottingham wrote: - killing the initrd for that general 90% case can be a big win Ermm, the general 90% (or some large-ish generalizing percentage) are set up to use LVM. Which then requires an initrd. Yes, but ... LVM is overkill, in general. (That's another discussion.) On further consideration, though, the biggest issue with kicking out the initrd is getting the policy lodaed. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
de-modularising for the win!
See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Bill ? patch-2.6.27-rc1-git2.bz2 ? patch-2.6.27-rc1.bz2 Index: config-generic === RCS file: /cvs/extras/rpms/kernel/devel/config-generic,v retrieving revision 1.166 diff -u -r1.166 config-generic --- config-generic 9 Sep 2008 06:16:19 - 1.166 +++ config-generic 18 Sep 2008 19:12:12 - @@ -333,7 +333,7 @@ CONFIG_CISS_SCSI_TAPE=y CONFIG_BLK_DEV_DAC960=m CONFIG_BLK_DEV_UMEM=m -CONFIG_BLK_DEV_LOOP=m +CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y @@ -427,7 +427,7 @@ # # SCSI device support # -CONFIG_SCSI=m +CONFIG_SCSI=y CONFIG_SCSI_ENCLOSURE=m CONFIG_SCSI_PROC_FS=y @@ -448,7 +448,7 @@ CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m -CONFIG_BLK_DEV_SR=m +CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y CONFIG_CHR_DEV_SCH=m @@ -508,11 +508,11 @@ CONFIG_ATA=y CONFIG_ATA_SFF=y -CONFIG_ATA_PIIX=m +CONFIG_ATA_PIIX=y CONFIG_ATA_ACPI=y CONFIG_BLK_DEV_SX8=m CONFIG_PDC_ADMA=m -CONFIG_SATA_AHCI=m +CONFIG_SATA_AHCI=y CONFIG_SATA_INIC162X=m CONFIG_SATA_MV=m CONFIG_SATA_NV=m @@ -636,7 +636,7 @@ CONFIG_MD_RAID5_RESHAPE=y CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m -CONFIG_BLK_DEV_DM=m +CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=m CONFIG_DM_DEBUG=y # CONFIG_DM_DELAY is not set @@ -790,7 +790,7 @@ CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m -CONFIG_NETFILTER_XTABLES=m +CONFIG_NETFILTER_XTABLES=y CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m @@ -808,7 +808,7 @@ CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m -CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m +CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m @@ -841,7 +841,7 @@ # # IP: Netfilter Configuration # -CONFIG_NF_CONNTRACK_ENABLED=m +CONFIG_NF_CONNTRACK_ENABLED=y CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y @@ -857,8 +857,8 @@ CONFIG_NF_CONNTRACK_SANE=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m -CONFIG_NF_CONNTRACK_IPV4=m -CONFIG_NF_CONNTRACK_IPV6=m +CONFIG_NF_CONNTRACK_IPV4=y +CONFIG_NF_CONNTRACK_IPV6=y CONFIG_NF_NAT=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_CT_PROTO_DCCP=m @@ -1284,7 +1284,7 @@ CONFIG_WLAN_80211=y # CONFIG_PCMCIA_RAYCS is not set -CONFIG_MAC80211=m +CONFIG_MAC80211=y CONFIG_MAC80211_QOS=y CONFIG_MAC80211_RC_DEFAULT_PID=y # CONFIG_MAC80211_RC_DEFAULT_SIMPLE is not set @@ -1299,7 +1299,7 @@ # CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT is not set # CONFIG_MAC80211_DEBUG is not set -CONFIG_IEEE80211=m +CONFIG_IEEE80211=y CONFIG_IEEE80211_DEBUG=y CONFIG_IEEE80211_CRYPT_WEP=m CONFIG_IEEE80211_CRYPT_CCMP=m @@ -2461,17 +2461,17 @@ # # Advanced Linux Sound Architecture # -CONFIG_SND=m +CONFIG_SND=y CONFIG_SND_VERBOSE_PROCFS=y -CONFIG_SND_SEQUENCER=m +CONFIG_SND_SEQUENCER=y CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y CONFIG_SND_OSSEMUL=y -CONFIG_SND_MIXER_OSS=m -CONFIG_SND_PCM_OSS=m +CONFIG_SND_MIXER_OSS=y +CONFIG_SND_PCM_OSS=y CONFIG_SND_PCM_OSS_PLUGINS=y -CONFIG_SND_RTCTIMER=m +CONFIG_SND_RTCTIMER=y CONFIG_SND_DYNAMIC_MINORS=y # CONFIG_SND_SUPPORT_OLD_API is not set @@ -2528,7 +2528,7 @@ CONFIG_SND_ES1968=m CONFIG_SND_FM801=m CONFIG_SND_FM801_TEA575X_BOOL=y -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 CONFIG_SND_INTEL8X0M=m CONFIG_SND_KORG1212=m CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL=y @@ -2886,7 +2886,7 @@ CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y -CONFIG_EXT3_FS=m +CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y @@ -3199,6 +3199,7 @@ # CONFIG_CRYPTO=y CONFIG_CRYPTO_HW=y +CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_MANAGER=m # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_AES=m Index: config-x86-generic === RCS file: /cvs/extras/rpms/kernel/devel/config-x86-generic,v retrieving revision 1.47 diff -u -r1.47 config-x86-generic --- config-x86-generic 27 Jul 2008 07:22:15 - 1.47 +++ config-x86-generic 18 Sep 2008 19:12:12 - @@ -127,12 +127,12 @@ CONFIG_X86_MPPARSE=y CONFIG_ACPI=y -CONFIG_ACPI_AC=m +CONFIG_ACPI_AC=y # CONFIG_ACPI_ASUS is not set CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_SYSFS_POWER=y -CONFIG_ACPI_BATTERY=m -CONFIG_ACPI_BAY=m +CONFIG_ACPI_BATTERY=y +CONFIG_ACPI_BAY=y CONFIG_ACPI_BLACKLIST_YEAR=1999
Re: de-modularising for the win!
Tom spot Callaway ([EMAIL PROTECTED]) said: 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? Well, that option doesn't appear to actually do anything, considering the fact that it's set to 'm' now and the scsi core isn't actually modular. So we may be able to ignore that one. Bill ___ 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!
[1] Or someone can dig up the patches for dynamic loop allocation and finish them off :-) Already exists. Try 'mknod loop23 ; losetup ...'... Bill ___ 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!
Chris Snook ([EMAIL PROTECTED]) said: See various and sundry plumber's conf discussions. Links please? Not sure where things are being posted. Summary: - modules are wasteful (you lose a good chunk of code size savings in page round up) - modules are slow (well, modprobe is) - for the modules that are used by 90% of machines, what's the point of having them static? - killing the initrd for that general 90% case can be a big win Comments? (The netfilter stuff needs further investigation.) -CONFIG_BLK_DEV_LOOP=m +CONFIG_BLK_DEV_LOOP=y -CONFIG_SCSI=m +CONFIG_SCSI=y -CONFIG_BLK_DEV_SR=m +CONFIG_BLK_DEV_SR=y -CONFIG_ATA_PIIX=m +CONFIG_ATA_PIIX=y -CONFIG_SATA_AHCI=m +CONFIG_SATA_AHCI=y -CONFIG_BLK_DEV_DM=m +CONFIG_BLK_DEV_DM=y If this is going to make it easier to do fancy things in the initrd, I'm all for it. If it's just a TLB thing, I don't think it's worth it. Fancy things by not having the initrd. -CONFIG_MAC80211=m +CONFIG_MAC80211=y -CONFIG_IEEE80211=m +CONFIG_IEEE80211=y Won't this make it harder for people to test experimental wireless drivers? Unless the vendors start opening specs, we're going to have a perpetual need to play around in this area with each new hardware rev. How so? There's one version shared among all the in-tree modules. If you're developing the kernel, you're already rebuilding, so you can do whatever. -CONFIG_SND=m +CONFIG_SND=y -CONFIG_SND_SEQUENCER=m +CONFIG_SND_SEQUENCER=y -CONFIG_SND_MIXER_OSS=m -CONFIG_SND_PCM_OSS=m +CONFIG_SND_MIXER_OSS=y +CONFIG_SND_PCM_OSS=y -CONFIG_SND_RTCTIMER=m +CONFIG_SND_RTCTIMER=y -CONFIG_SND_HDA_INTEL=m +CONFIG_SND_HDA_INTEL=y -CONFIG_SND_INTEL8X0=m +CONFIG_SND_INTEL8X0=y For the love of god, no. We have lots of sound problems that require modprobe magic to troubleshoot and work around. Fix the [EMAIL PROTECTED] driver, then! (FWIW, the only sound problems I've seen recently is that the volume restore scripts got broken.) This will require people to rebuild their kernel just to test sound fixes, which will scare away an awful lot of testers and inconvenience the rest. How often are we shipping random source patches to Fedora users, who would have to install kernel-devel and kernel-source anyway, causing them to download just as much data as a new test kernel? Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[PATCH] be less annoying on boot
As long as we're printing mostly useless messages on every boot regardless of debug level, make them 5% more amusing. Signed-off-by: Bill Nottingham [EMAIL PROTECTED] --- linux-2.6.26.noarch/arch/x86/kernel/head64.c.foo2008-08-01 15:44:28.0 -0400 +++ linux-2.6.26.noarch/arch/x86/kernel/head64.c2008-08-01 15:46:53.0 -0400 @@ -109,11 +109,11 @@ early_printk(Kernel alive\n); x86_64_init_pda(); - early_printk(Kernel really alive\n); + early_printk(Kernel really alive! It's alive! IT'S ALIVE!\n); x86_64_start_reservations(real_mode_data); } void __init x86_64_start_reservations(char *real_mode_data) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
Jarod Wilson ([EMAIL PROTECTED]) said: Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. We actually *can* make it noarch without much effort -- remember, the kernel is a special beast that actually does get a noarch build pass done on it for kernel-docs. No reason kernel-firmware couldn't be spit out from the same build run, so far as I know. Well, it means you may end up including various firmwares on architectures where they're irrelevant. But as long as you're willing to take the installed space hit, it's not a huge deal. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
Matt Domsch ([EMAIL PROTECTED]) said: https://bugzilla.redhat.com/show_bug.cgi?id=433121 DKMS would like to have the opportunity to run it's auto-rebuilder/installer after a new kernel RPM has been installed, without having to wait for a system restart to run it. Likewise, when a kernel RPM is removed, it would like to be able to run to remove modules managed by it. Use triggers - this functionality already exists without kernel-specific infrastructure. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
Matt Domsch ([EMAIL PROTECTED]) said: Use triggers - this functionality already exists without kernel-specific infrastructure. a) LSB suggests triggers are evil. Then triggers must be the right answer. b) triggers don't tell me the version of the package that got installed that caused the trigger, which is what I need to know. Hm, I wonder if this can be added to RPM. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
Jason L Tibbitts III ([EMAIL PROTECTED]) said: MD == Matt Domsch [EMAIL PROTECTED] writes: MD [...] there's no ordering guarantee between the two such that we MD know kernel-devel is always installed before kernel. It should be possible to have kernel-devel have Requires(post): kernel or use some other type of fine-grained dependency to guarantee some sort of ordering. Is that good enough? It should be easily implementable. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: UVESAFB in kernel 2.6.24
Mark ([EMAIL PROTECTED]) said: Why wouldn't it be a module like (most) other framebuffers? Well.. vesafb is also enabled with 'y' and because uvesafb is it's successor it seems logical to me that it also gets enabled with 'y' (not as a module but build in). Perhaps a good idea for fedora to add a anaconda installer option that allows you to set the boot resolution or add the option in the firstboot. AFAIK, we don't ship the tools for uvesafb, so it's a little late for it to be a successor. How does it execute them if it's built-in, anyway? Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: UVESAFB in kernel 2.6.24
Mark ([EMAIL PROTECTED]) said: AFAIK, we don't ship the tools for uvesafb, so it's a little late for it to be a successor. How does it execute them if it's built-in, anyway? uvesafb just got included in the 2.6.24 which isn't even final yet so it's not 'late'.. more early than late. Sorry, meant 'too early', without the userspace part. To execute.. Quote from [1]: add video=uvesafb:1024x768-32,mtrr:3,ywrap (or similar) to your kernel command line Right, but how does that work if built-in static? Is it relying on initialization order vs. initramfs unpacking to find its userspace component? Is it just spinning waiting for userspace? About the question: But who wwould maintain the v86d userspace code package if we enabled the driver? I'm willing to give it a shot with the help of someone that has experience in making spec files. (i have the links to the (old) handbooks.. just not the experience) [1] http://dev.gentoo.org/~spock/projects/uvesafb/ This includes Yet Another Pasted In Copy of x86emu and lrmi. Ick. We really need to get a single libx86 in the distro and have things using it. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: -vanilla builds.
Jason L Tibbitts III ([EMAIL PROTECTED]) said: DJ == Dave Jones [EMAIL PROTECTED] writes: DJ I think we ended up settling on putting them on DJ people.fedoraproject.org. Given the 150MB quota, this probably DJ means... Actually all it means is that you need to ask for more space. Sort of. Adding debuginfo + all arches means that each vanilla build could end up taking up over a gigabyte. There are limits to how much space we can ask for. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?]
Bill Nottingham ([EMAIL PROTECTED]) said: Here you go; sorts them into two piles (networking and block), and expands the symbol list to catch some of the missing modules such as ahci and some of the wireless drivers. ... committed. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?]
Jeremy Katz ([EMAIL PROTECTED]) said: Depends on how many copies of the qlogic driver there are ;-) RHEL live CDs? What's that? (Actually, I lied - drivers/block + drivers/scsi is 1.3M compressed.) I mean, I guess I can just do manual twiddling to rule out things that aren't under drivers/ata with the livecd. I'm not _that_ tied to having the two separated out if that's the real kicker here OK. I'll tweak the stuff in the spec and send it here for comments. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?]
Jeremy Katz ([EMAIL PROTECTED]) said: If it's done at runtime, you can handle whatever kernel you happen to get, even if it's not one of ours. There are plenty of constraints we have around kernel configuration. Asking for a file to be shipped with the kernel which tells us a little bit about what modules were configured just doesn't seem that out there In that case, I strongly suggest combining the libata and scsi lists into a single list for block devices - I doubt the 1M savings on the livecd is really worth splitting hairs here. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
aic7xxx_old
Isn't it about time for this to die? Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Who decides what drivers go on the install disk?
Chuck Ebbert ([EMAIL PROTECTED]) said: The arcmsr driver is in-kernel but you can't install to a system using it for the main disk controller: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647 Ditto for the uli526x network driver, network installs are impossible on systems using that: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165 The kernel has the drivers available, but people are reporting these as kernel bugs... module-info in the anaconda package. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Removing atomic.h from Fedora kernel headers
Chuck Ebbert ([EMAIL PROTECTED]) said: Why do we explicitly remove atomic.h from our kernel header package? IIRC, the reasoning was because the operations weren't actually atomic when used from userspace; ergo, it was a bad idea to provide them. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: atop?
Axel Thimm ([EMAIL PROTECTED]) said: Would it make sense to add these patches to Fedora's kernel? http://www.atcomputing.nl/Tools/atop This could help in the area of extending laptop battery life by detecting unneccessary disk access. The first step is to have some disk I/O to process mapping. These patches: a) aren't upstream b) change the format of /proc/stat c) change process accounting in an incompatible way So... no. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: atop?
Axel Thimm ([EMAIL PROTECTED]) said: These patches: a) aren't upstream b) change the format of /proc/stat c) change process accounting in an incompatible way So... no. OK, fair enough (I wasn't aware of b) and c)). Any other way then to achive the stated goals? I haven't tried, but blktrace? Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
