tagged for 2.6.32
So we're moving to 2.6.32 across F-11 F-12, as such I've tagged the old kernels on those branches. F-11 2.6.30 is on branch private-fedora-11-2_6_30 F-12 2.6.31 is on branch private-fedora-12-2_6_31 The devel/ sources from 2.6.32 are on private-rawhide-2_6_32. Kyle. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [ppc64] newer gcc breaks kernel build?
On Thu, Sep 17, 2009 at 09:31:52PM +0200, Jakub Jelinek wrote: I've noticed the dot in front of the symbol, is kernel using still the for years deprecated oldish ppc64 ABI instead of the new one (i.e. uses -mcall-aixdesc instead of not using this option at all)? Maybe it is broken only in that case. arch/powerpc/Makefile: CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=none -mcall-aixdesc Seems to... :/ Would a workaround be to switch ppc64 back to -O2 until ld is fixed? Sure, at -O2 those aren't emitted. Groovy, I just kicked off a build with CC_OPTIMIZE_FOR_SIZE unset on ppc64, and it seems to have made it farther. Thanks! Kyle Jakub ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Radeon driver broken in 2.6.31-0.125.4.2.rc5.git2.fc11
On Sat, Aug 15, 2009 at 03:32:43PM -0700, Markus Kesaromous wrote: Date: Sat, 15 Aug 2009 15:23:46 -0600 From: zait...@redhat.com To: remotes...@live.com CC: fedora-kernel-list@redhat.com Subject: Re: Radeon driver broken in 2.6.31-0.125.4.2.rc5.git2.fc11 On Sat, 15 Aug 2009 14:15:50 -0700, Markus Kesaromous wrote: But in 2.6.31-0.125.4.2.rc5.git2, X is unable to start. Using the F12 kernel on F-11 is unsupported. You get to keep both pieces. regards, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RFC PATCH] Disable alsa snd-pcsp driver
On Wed, Jul 29, 2009 at 11:33:08AM -0400, Adam Jackson wrote: On Wed, 2009-07-29 at 10:53 -0400, Bill Nottingham wrote: Because ... why would you want to use this? Ever? @mezcalero people who enable that module in the kernel deserve to suffer Kill it kill it kill it. Just for that comment, I think we'll make it =y. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH 0/3] iwl3945 driver fixes for Fedora 11 (2.6.29)
On Thu, Jul 23, 2009 at 01:31:47PM -0400, John W. Linville wrote: On Thu, Jul 23, 2009 at 04:35:39PM +0200, Stanislaw Gruszka wrote: Due to backport of patch linux-2.6-iwl3945-report-killswitch-changes-even-if-the-interface-is-down.patch we have bunch of iwl3945 bugs (race conditions) that are not reproducible on vanilla 2.6.29. These patches address them (at least some of them). Looks good to me. I think Kyle agreed to merge them into Fedora kernels. Thanks! Applied. (sorry John, I've got k...@redhat but not ky...@redhat.) cheers, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] NFS V4 - Dynamic Pseudo Root
On Tue, Jul 07, 2009 at 01:41:11PM -0400, Steve Dickson wrote: I would like to apply the following patch to the rawhide kernel that will make exports for NFS v4 mount work just list exports for v3 and v2 mounts. In a nutshell, for NFS v4 mounts to work like v3/2 mounts the '/ *(ro,fsid=0)' entry has to be added to the /etc/exports file. This patch eliminates the need for that entry. The history, reasoning and evolution of this patch can be found at: http://linux-nfs.org/pipermail/nfsv4/2009-June/010724.html This seems fairly sensible to me. Feel free to apply it where appropriate. regards, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
rebases, releases, and rejects, oh my!
Last night, I committed the rebase of devel/ to 2.6.31-git, which will likely, for a variety of reasons, not the least of which is because F-12 is a short cycle, be what F-12 eventually releases with. The following tags now exist: F-11, private-fedora-11-2_6_29 which contains a snapshot of the 2.6.29 tree. The tag will move to whatever the latest state is when we rebase to 2.6.30... devel, private-fedora-12-2_6_30 which contained the 2.6.30 state immediately before I committed 2.6.31-git. Until we rebase F-11, which should happen soon(ish) if you have anything pressing for F-11 2.6.30, please commit it to the devel/ 2.6.30 tag and drop a note here. Thanks, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: f11 ppc64 woes
On Sun, Jun 07, 2009 at 12:57:06PM +0100, David Woodhouse wrote: On Sun, 7 Jun 2009, Josh Boyer wrote: On Sun, Jun 07, 2009 at 09:28:25AM +0100, David Woodhouse wrote: On Sat, 2009-06-06 at 16:13 +0100, David Woodhouse wrote: I blame yaboot... Fixed in yaboot-1.3.14-13 (thanks to benh for pointing out the problem). We missed the boat to get that in F11 GA, right? Pretty sure. Jesse is getting on a plane today, and we release Tuesday. 0-day update it seems. Though that isn't going to help the installer any. We might have to recommend yum updating or pre-upgrade for the machines this impacted. Or 'netboot' with the zImage, which can be done from the CD. Precisely where in the release kernel does the 4MiB corruption happen? drivers/scsi/scsi_transport_iscsi.c, which is unconditionally hit (via iscsi_tcp) by anaconda. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] Bring F11's btrfs uptodate with mainline
On Mon, May 11, 2009 at 04:55:33PM -0400, Josef Bacik wrote: Hello, This patch needs to replace the current 2 btrfs patches that are being carried for F11. All of the scary things in this patch are currently in F11 in the form of the two patches we are already carrying, this patch just brings us up to date with mainline, which has a bunch of fixes and performance tweaks. Thanks, You forgot to attach it. :) cheers, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.29.1-102.fc11 --with vanilla broken
On Tue, Apr 28, 2009 at 10:27:38AM -0700, Roland McGrath wrote: You should always specify an arch. make prep uses noarch and generally works fine. You can just ignore the strange assembler messages in the 'make configs' phase and the .config files come out fine, in my experience. The strange messages are just annoying Makefile detritus because of running ARCH=ia64, they're nothing to be concerned with, and not relevant to anything but actually building the kernel on ia64. (See also arch/ia64/Makefile $GAS_STATUS and $KBUILD_CPPFLAGS) cheers, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.29.1-102.fc11 --with vanilla broken
On Wed, Apr 22, 2009 at 06:18:07PM -0400, Chuck Anderson wrote:
if ! egrep ^Patch[0-9]+: $patch\$ %{_specdir}/%{name}.spec ; then
if [ ${patch:0:10} != patch-2.6. ] ; then
echo ERROR: Patch $patch not listed as a source patch in specfile
exit 1
fi
fi 2/dev/null
Why is it checking for patch-2.6.* in the patch file name? I
removed that entire block of code and --with vanilla now works. What
is the expected behavior of that block of code?
Urgh. Yeah, this was added to check that ApplyPatch patches are also
listed in the srpm (if they aren't, then obviously we'll ftbfs... this
lets 'make prep' catch it.)
This rule should probably be updated to use an $specdir/exclude file or
something.
regards, Kyle
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
early branched for F-11
Just a quick note, we've early branched for F-11... The 2.6.29 based tree for F-11 is located in the F-11/ subdirectory... Make sure you cvs up the common/ dir as well. devel/ has been updated for -git7 and will continue to move towards 2.6.30. regards, Kyle ___ 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 Thu, Mar 12, 2009 at 04:11:37PM +0100, Oliver Falk wrote: I didn't want to do it directly in private-fedora-9-2_6_27-branch with my first shot. I hope that's OK with? This way it's in CVS and I can build from it for testing. Now that I've seen it builds fine, I can go on and approach the 'real' tag... Sure, sounds good to me. cheers, Kyle ___ 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.1311,1.1312
On Thu, Feb 19, 2009 at 09:53:57AM -0500, Bill Nottingham wrote: The compose process (for rawhide/updates) only pulls the latest build for each source package; ergo, this won't work as far as havong -docs always available to install. Well, that's broken. But honestly I suspect nobody actually cares. And if they do, I'm sure the F-10 package is still installable. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[PATCH] drm: disable gem on i8xx
In an IRC conversation, you mentioned that GEM was not to be used on 8xx yet... But there didn't seem to be anything explicitly disabling this. Add code to turn off GEM on i8xx series chips. This didn't turn out to be the problem with X on my i830, but at least it kills the lockdep warning. Should this go upstream as well? Signed-off-by: Kyle McMartin k...@redhat.com --- diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index cc0adb4..9303063 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1108,8 +1108,8 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) /* don't enable GEM on PAE - needs agp + set_memory_* interface fixes */ dev_priv-has_gem = 0; #else - /* enable GEM by default */ - dev_priv-has_gem = 1; + /* enable GEM by default, except on I8xx */ + dev_priv-has_gem = !IS_I8XX(dev) ? 1 : 0; #endif i915_gem_load(dev); diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a70bf77..84664fe 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -750,6 +750,9 @@ extern int i915_wait_ring(struct drm_device * dev, int n, const char *caller); #define IS_I855(dev) ((dev)-pci_device == 0x3582) #define IS_I865G(dev) ((dev)-pci_device == 0x2572) +#define IS_I8XX(dev) (IS_I830(dev) || IS_845G(dev) || IS_I85X(dev) || \ + IS_I855(dev) || IS_I865G(dev)) + #define IS_I915G(dev) ((dev)-pci_device == 0x2582 || (dev)-pci_device == 0x258a) #define IS_I915GM(dev) ((dev)-pci_device == 0x2592) #define IS_I945G(dev) ((dev)-pci_device == 0x2772) ___ 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 08:47:41PM +0100, Thorsten Leemhuis wrote: 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). And it would make documentation a whole lot easier, making Fedora easier to use. But whatever. You guys on IRC made clearly indicated you option reg. kmod so I don't think it's worth arguing further. This doesn't make Fedora easier to use. It makes fedora + random external packages easier to use. Tough. ___ 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 03:11:37PM -0500, Bill Nottingham wrote: 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. yum-appropriate-kernel-plugin.py that grovels /proc/cpuinfo? ___ 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.1254, 1.1255 linux-2.6-compile-fixes.patch, 1.188, 1.189 sata_sil-build-break-fix.patch, 1.1, NONE
On Sun, Feb 01, 2009 at 05:36:31AM +, Chuck Ebbert wrote: Fold sata_sil build fix into compile-fixes.patch Patch can be dropped, alternate fix is in -rc3-git. regards, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Package: kernel-2.6.29-0.59.rc2.git3.fc11 Tag: dist-f11 Status: failed Built by: markmc
On Wed, Jan 28, 2009 at 09:31:47AM +, Mark McLoughlin wrote: Hey, I enabled CONFIG_PCI_STUB (#482792), but the build failed on ppc: drivers/gpu/drm/nouveau/nouveau_state.c: In function 'nouveau_load': drivers/gpu/drm/nouveau/nouveau_state.c:487: error: implicit declaration of function '___swab32' make[4]: *** [drivers/gpu/drm/nouveau/nouveau_state.o] Error 1 fixt. ___ 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?
On Wed, Jan 28, 2009 at 10:30:27AM -0500, John W. Linville wrote: On Wed, Jan 28, 2009 at 10:20:03AM -0500, Bill Nottingham wrote: 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. IIRC, it will take some porting for 2.6.27. Is there an F-10-2_6_27 fork somewhere? I started this last night, so I could submit it to stable... The F10 2.6.27 branch is private-fedora-10-2_6_27. cheers, Kyle ___ 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?
On Wed, Jan 28, 2009 at 12:53:12PM -0500, Kyle McMartin wrote: I started this last night, so I could submit it to stable... Forgot to mention this here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1089515 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel: only build kernel-headers on ARM
On Fri, Jan 23, 2009 at 10:06:41AM +0530, Kedar Sovani wrote: I applied it, but there wasn't enough in config-arm to make it build. Rather than just ignore it, I filled in some of the blanks that seemed relevant. I have no idea what your specific machtype is, but I assumed the versatile thingy so I turned things on/off as Kconfig help text seemed to indicate were for this platform. Here's a diff, shout or plz send a diff against devel/config-arm if anything seems out of place to you folks. cheers, Kyle Index: config-arm === RCS file: /cvs/pkgs/rpms/kernel/devel/config-arm,v retrieving revision 1.1 diff -u -p -r1.1 config-arm --- config-arm 26 Jan 2009 07:19:13 - 1.1 +++ config-arm 26 Jan 2009 20:23:45 - @@ -5,6 +5,31 @@ CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_ARCH_VERSATILE=y +CONFIG_ARCH_VERSATILE_PB=y +CONFIG_MACH_VERSATILE_AB=y + +# CONFIG_CPU_ICACHE_DISABLE is not set +# CONFIG_CPU_DCACHE_DISABLE is not set +# CONFIG_CPU_DCACHE_WRITETHROUGH is not set +# CONFIG_CPU_CACHE_ROUND_ROBIN is not set + +CONFIG_ZBOOT_ROM_TEXT=0 +CONFIG_ZBOOT_ROM_BSS=0 + +# CONFIG_XIP_KERNEL is not set + +CONFIG_ATAGS_PROC=y + +# CONFIG_FPE_NWFPE is not set +CONFIG_FPE_FASTFPE=y +CONFIG_VFP=y + +CONFIG_PM=y +# CONFIG_PM_DEBUG is not set +# CONFIG_PM_TRACE is not set +CONFIG_SUSPEND=y +# CONFIG_PM_TEST_SUSPEND is not set +CONFIG_APM_EMULATION=y CONFIG_ARM_THUMB=y @@ -13,3 +38,56 @@ CONFIG_OABI_COMPAT=y CONFIG_CMDLINE=console=ttyAM0,115200 root=/dev/sda1 rootdelay=20 +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y + +# CONFIG_CPU_IDLE is not set + +CONFIG_LEDS=y +CONFIG_LEDS_CPU=y + +CONFIG_MTD_AFS_PARTS=y +CONFIG_MTD_ARM_INTEGRATOR=y +CONFIG_MTD_IMPA7=y + +CONFIG_AX88796=m +CONFIG_AX88796_93CX6=y +CONFIG_SMC91X=m +CONFIG_DM9000=m +CONFIG_DM9000_DEBUGLEVEL=4 +# CONFIG_DM9000_FORCE_SIMPLE_PHY_POLL is not set +CONFIG_SMC911X=m +CONFIG_SMSC911X=m + +CONFIG_SERIO_AMBAKMI=m + +CONFIG_SERIAL_AMBA_PL011=y +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y + +CONFIG_I2C_VERSATILE=y + +CONFIG_THERMAL=y + +# CONFIG_MFD_T7L66XB is not set +# CONFIG_MFD_TC6387XB is not set + +CONFIG_FB_ARMCLCD=m + +CONFIG_SND_ARM=y +CONFIG_SND_ARMAACI=m + +CONFIG_USB_MUSB_HDRC=m +# CONFIG_MUSB_PIO_ONLY is not set +CONFIG_USB_TUSB6010=y +# CONFIG_USB_MUSB_DEBUG is not set + +CONFIG_MMC_ARMMMCI=m + +CONFIG_RTC_DRV_PL030=m +CONFIG_RTC_DRV_PL031=m + +# CONFIG_SGI_IOC4 is not set + +# CONFIG_DEBUG_USER is not set +# CONFIG_DEBUG_ERRORS is not set +# CONFIG_DEBUG_LL is not set ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel: only build kernel-headers on ARM
On Thu, Jan 22, 2009 at 10:42:02AM +0530, Kedar Sovani wrote:
Since kernels for different ARM CPUs differ wildly, and since
embedded folks tend to provide their own kernels, this patch makes
the Fedora kernel package only build kernel-headers when built for
ARM.
Signed-off-by: Lennert Buytenhek buyt...@marvell.com
Signed-off-by: Kedar Sovani ked...@marvell.com
Groovy! Just one comment that jwb brought up:
+%ifarch %{arm}
+%define nobuildarches i386 s390 sparc %{arm}
I assume the %arm is defined by rpm to expand to the arm5
bits? Is this in upstream rpm now?
regards, Kyle
___
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 Tue, Jan 20, 2009 at 11:06:17AM +0200, Avi Kivity wrote: Eric Paris wrote: I've got a P3 (Coppermine) with 256M memory running F10. My significant other took it with her to Antarctica (Well F9 has been to Antarctica but it'll be F10 in Antarctica next month). You can only run one app at a time and have to be patient, but it's perfectly usable (and noone cares if this laptop is lost, stolen or destroyed [aside from her being pissed she lost all her research data]). I wouldn't/couldn't to use it as a daily machine, so while I'm in favor of -PAE default, F10 is usable on such small machines. I don't care if old machines need some bit twiddling to get to work, but we aren't dead yet :) By F12 you'll be down to zero apps at the same time, and slow... We can keep the non-PAE kernel, but as non-default in recognition that technology has moved on. Look, I'm sorry if I'm just not thinking big picture enough here, but what exactly is the use case for a PAE kernel these days? The compat code in x86_64 should be more than good enough for the apps that require an i686 chroot. I just don't see the status quo as doing any real harm, as the only generations of CPU that benefit are really P4 (which aren't worth the electricity used to power them) or Core (One) Duo (which didn't exist for a particularly long time...) Neither of which actually supported more than 3GB of RAM on their northbridges except for the Xeon chipsets anyway. I have no idea what the installer and livecd do, but to me, it would seem to be a waste of space to carry two sets of installable kernels on the discs, when one would do. That said again, I'm suprised we aren't installing i586 kernels by default... Odd. I think the ideal solution here is to support x86_64 kernel, i686 userspace more actively. What, honestly, are the odds of someone with a bunch of P4 Xeons these days with 32GB of ram running Fedora? Are there really enough of them that it's worth caring? ;-) Of course, take what I say with a grain of salt. I don't particularly care at all, I'm just trying to play the pragmatist. Another question is what's the perf penalty of going to PAE on a 2GB of ram machine versus the vanilla HIGHMEM4G config? The only argument I really buy into is the NX one, honestly... What about a yum plugin that recommends a kernel that the user could override? I'll poke at it this afternoon (hey, I've always wanted to learn python...) cheers, Kyle ___ 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 Tue, Jan 20, 2009 at 07:28:10PM +0200, Avi Kivity wrote: Users won't be running yum. They're running that applet thing. Which just shells out to yum... ;-) ___ 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:23:26AM -0500, Bill Nottingham wrote: 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. Unless we keep the non-PAE i586 kernel around as a fallback, we're not going to be able to boot on a whole raft of crappy i386 chips (original Pentium M most notably...) regards, Kyle ___ 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: BTW, does anyone know if the Geode in OLPC XO has PAE? The PAE bit in %cr4 is listed as reserved in the geode databook the olpc site links to, so my guess is no. :\ regards, Kyle ___ 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 01:36:08PM -0500, Neil Horman wrote: Absolutely, I've got a Thinkpad T42 here that does just fine on fedora 10. Unless of course, I try to load a PAE enabled kernel on it. I've not looked into it at all, but this thread got me thinking, is there any particular reason that we can't merge the pae and non-pae kernels using the same alternatives approach we used to merge smp up? I looked into this several years ago, it's actually fairly gnarly since depending on PAE we set up the swapper page tables differently, and other ugly differences. I should resurrect the patch set, though I think rationalizing it with the Xen merge might be more pain than it's worth... last time I looked at it there was a ridiculous amount of rejects. It was pretty close to booting (though I had to hack the bootloader to get a PAE enable bit so people without the bit could turn it off.) regards, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
applypatch.sh script
I dislike looking at those
C=`wc -l ..`
if [ -gt ... ]
things in the spec-file...
How about something like this?
? prep2.log
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.1218
diff -u -p -r1.1218 kernel.spec
--- kernel.spec 15 Jan 2009 07:41:04 - 1.1218
+++ kernel.spec 15 Jan 2009 08:16:29 -
@@ -862,19 +862,12 @@ exit 1
%endif
%endif
-patch_command='patch -p1 -F1 -s'
ApplyPatch()
{
local patch=$1
shift
- if [ ! -f $RPM_SOURCE_DIR/$patch ]; then
-exit 1;
- fi
- case $patch in
- *.bz2) bunzip2 $RPM_SOURCE_DIR/$patch | $patch_command ${1+$@} ;;
- *.gz) gunzip $RPM_SOURCE_DIR/$patch | $patch_command ${1+$@} ;;
- *) $patch_command ${1+$@} $RPM_SOURCE_DIR/$patch ;;
- esac
+
+ $RPM_SOURCE_DIR/scripts/applypatch.sh $RPM_SOURCE_DIR/$patch ${1+$@}
}
# First we unpack the kernel tarball.
@@ -998,18 +991,12 @@ ApplyPatch linux-2.6-makefile-after_link
#
# misc small stuff to make things compile
#
-C=$(wc -l $RPM_SOURCE_DIR/linux-2.6-compile-fixes.patch | awk '{print $1}')
-if [ $C -gt 10 ]; then
ApplyPatch linux-2.6-compile-fixes.patch
-fi
%if !%{nopatches}
# revert patches from upstream that conflict or that we get via other means
-C=$(wc -l $RPM_SOURCE_DIR/linux-2.6-upstream-reverts.patch | awk '{print $1}')
-if [ $C -gt 10 ]; then
ApplyPatch linux-2.6-upstream-reverts.patch -R
-fi
#ApplyPatch git-cpufreq.patch
@@ -1151,10 +1138,7 @@ ApplyPatch linux-2.6-net-tulip-interrupt
# linux1394 git patches
#ApplyPatch linux-2.6-firewire-git-update.patch
-C=$(wc -l $RPM_SOURCE_DIR/linux-2.6-firewire-git-pending.patch | awk '{print
$1}')
-if [ $C -gt 10 ]; then
ApplyPatch linux-2.6-firewire-git-pending.patch
-fi
# silence the ACPI blacklist code
ApplyPatch linux-2.6-silence-acpi-blacklist.patch
Index: scripts/applypatch.sh
===
RCS file: scripts/applypatch.sh
diff -N scripts/applypatch.sh
--- /dev/null 1 Jan 1970 00:00:00 -
+++ scripts/applypatch.sh 15 Jan 2009 08:16:29 -
@@ -0,0 +1,28 @@
+#!/bin/bash
+
+patch=$1
+shift
+
+# echo applying $patch
+
+if [ ! -f $patch ]; then
+ echo applypatch: $patch was missing!;
+ exit 1;
+fi
+
+# ignore empty patches, culls the ugly wc -l checks we had
+# around applypatch formerly...
+if [[ `diffstat $patch | grep 0 files changed` ]]; then
+ echo applypatch: $patch is empty;
+ exit 0;
+fi
+
+patchcmd='patch -p1 -F1 -s'
+
+case $patch in
+ *.bz2) bunzip2 $patch | $patchcmd ${1+$@} ;;
+ *.gz) gunzip $patch | $patchcmd ${1+$@} ;;
+ *) $patchcmd ${1+$@} $patch ;;
+esac
+
+# echo
___
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 10:21:52PM +0100, Gerd Hoffmann wrote: Dave Jones wrote: 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. Do you have bug numbers at hand? Searching for CONFIG_DMAR gives me Zarro Boogs found. 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. Well, it works for me. Single test box only though. As the machine in question actually has memory above 4G it is a nice speedup for kernel builds (sys time going down from ~15min to ~5min). I've just enabled it (and GFX_WA and FLOPPY_WA on x86_64.) (I'm suprised it's x86_64 only, surely virtualization enabled i386 could benefit from DMA protection?) ___ 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 01:39:13PM -0800, Chris Wright wrote: * Dave Jones (da...@redhat.com) wrote: 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. Upstream was still broken as recently as Friday for bad BIOSes (x200s in this case). Wonder if opt-in via cmdline would be helpful? A patch from Dirk Hohndel fixes this (looks like it got merged Sundayish, after floating around linux-pci for a week.) AFAIK, at least. regards, Kyle ___ 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 02:47:18PM -0800, Chris Wright wrote: * Kyle McMartin (k...@infradead.org) wrote: On Tue, Jan 13, 2009 at 01:39:13PM -0800, Chris Wright wrote: Upstream was still broken as recently as Friday for bad BIOSes (x200s in this case). Wonder if opt-in via cmdline would be helpful? A patch from Dirk Hohndel fixes this (looks like it got merged Sundayish, after floating around linux-pci for a week.) AFAIK, at least. Yeah, that's the case I was referring to. Mostly thinking that any feature like VT-d relying on BIOS will have some time to get defensive enough for all the ways BIOS can screw up the feature. No doubt it's going to end up like MSI. :( regards, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: A really big kernel (in a dead weight)
On Wed, Jan 07, 2009 at 11:20:20PM -0700, Michal Jaegermann wrote: I tried to install kernel-2.6.29-0.12.rc0.git7.fc11.x86_64. Its rpm package is quite reasonable 24M in size. Only rpm started to complain about insufficient space on /. A check with 'rpm -qip ...' revealed that the package claims to expand to 1035938542 bytes. Around 1 gig! Unpacking this in some other place revealed that indeed lib/modules/2.6.29-0.12.rc0.git7.fc11.x86_64/ eats 997M of disk. Only this is heavily padded with null bytes. With 'cp -a --sparse=always ...' aplied to that tree a target drops in size to 76M. More than a thirteenfold reduction. It is true that the same operation performed on lib/modules/2.6.29-0.9.rc0.git4.fc11.x86_64 reduces that from 188M to 78M, which is still quite a lot, but what 2.6.29-0.12.rc0.git7.fc11 is doing seems to be somewhat excessive. Is this is a side effect of some changes in a build process? Something seems to be a tad pushy. That module fattening surely adds a lot of extra time to kernel installation scripts but other than that a kernel for which modules were made sparse boots as any other one. The latest updates caused other serious and so far mysterious breakage, and in particular haldaemon does not run for me anymore, but that does look like a kernel dependent. Hitting up fedora-kernel-list would be helpful. ;-) Any idea which revision this was introduced in? If not, I'll start poking koji. cheers, Kyle ___ 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? Gopher it. regards, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.27 kernel for F-9?
On Fri, Oct 17, 2008 at 08:03:39AM -0400, Josh Boyer wrote: On Fri, Oct 17, 2008 at 06:33:49AM -0400, Jon Masters wrote: Hi, Anyone planning to respin the F-9 kernel with a .27 base? Webcams! :) I'd recommend waiting until at least the first batch of -stable patches is released. We're going to wait until F-8 is EOL before doing that in F-9. ___ 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:06:57PM -0400, Peter Jones wrote: -rwxr--r-- 1 root root 25K 2008-09-23 21:38 dm-mirror.ko -rwxr--r-- 1 root root 25K 2008-09-23 21:38 dm-snapshot.ko -rwxr--r-- 1 root root 7.0K 2008-09-23 21:38 dm-zero.ko 57kB or so max. But at the same time, these are loaded on nearly every Fedora system, and loaded as modules they're taking up at least 64kB . Groovy. Didn't mean it specifically for this case, but just in general it would be good to see the size increase we're going to be looking at. regards, Kyle ___ 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 Wed, Oct 01, 2008 at 06:34:18PM -0400, Chuck Ebbert wrote: On Tue, 30 Sep 2008 11:10:35 +0200 Thorsten Leemhuis [EMAIL PROTECTED] wrote: The alsa-project is a good example. Say you purchase a new motherboard and it has a brand new audio codec that is not yet supported by the in-kernel drivers. You report that to the alsa-project and they develop code to support that codec; a few days or weeks later they might tell you to download alsa-driver-1.0.18-alpha1.tar.bz and compile that for testing. If certain sound drivers (say snd-hda-intel) or the soundcore are compiled into the kernel (like planed for Fedora) then you will often be forced to recompile the whole kernel to test the new driver. That's a whole lot more complicated then compiling just the alsa-drivers, which is not that hard to do these days with current Fedora kernels. I've got to agree, for ALSA who provide a turnkey package that lets people test the latest drivers. Our users do compile that package and report back whether it fixes their problems. We probably shouldn't build any sound drivers in so they can keep doing that. Heh, we come back to this again... Why can't we do a debug/nodebug style split for rawhide's built-in-ness? For release we do what's best for the silent (core sound modules built in, drivers not, since they're pigs.) majority... regards, Kyle ___ 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 Tue, Sep 30, 2008 at 01:34:33AM -0700, Arjan van de Ven wrote: for certain types of choices the answer is going to be oh now you need to compile your own kernel; there's just too many config options for that not to be the case. Of course for the normal, common scenarios that's not the right answer, but I would like to replace core component FOO it's perfectly fine. Users don't replace their AHCI driver much (and if they do, even today, they're likely to just build their own whole kernel, or use a rawhide kernel rpm) In the RHEL world the rules are a bit different due to the really long release cycles (even for hw support updates), but on Fedora if you are capable of backporting a driver you can also build your own kernel or use an rpm provided. if a user is rebuilding their libata subsystem and replacing the modules, or replacing their alsa modules, or whatnot, they've already voided the i'd like to help you implied contract in open source, so they should just go run and support their own kernel. every patch in the fedora kernel has this implicit i take responsibility if this breaks property. of course, we're talking about /fedora/ here, not rhel. obviously the support reqiurements are vastly different for rhel. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH]: Backport KVM Intel MSR fix
On Wed, Sep 17, 2008 at 05:21:45PM +0200, Chris Lalancette wrote: Looks fine... Appliedinated. ___ 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.847,1.848
On Tue, Aug 05, 2008 at 05:48:04AM +, Dave Jones wrote: +cp -a acpi config keys linux math-emu media mtd net pcmcia rdma rxrpc scsi sound video drm asm-generic $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include +if [ -f asm ]; then + cp -a `readlink asm` $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include fi This looks like it will DTRT thing in both cases. Cool. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware --without vdso_install build options
On Tue, Aug 05, 2008 at 11:01:17AM -0400, Jarod Wilson wrote: On Tuesday 05 August 2008 09:24:10 Steve Dickson wrote: Chuck Ebbert wrote: Steve Dickson wrote: Now that devel kernels rpms require the kernel-firmware rpm, it makes sense to me that one should be able to build both of them at the same time. So this patch adds the --with firmware build option which will allow kernel-firmware rpms to built with kernel rpms. This patch also adds the --without vdso_install build option which stop the VDSO binaries from being installed. This cuts down the overall build time especially when you build over NFS like I do.. Signed-Off-By: Steve Dickson [EMAIL PROTECTED] With one small change we can still support --without firmware. That way the default behavior can be overridden in either case. See below... Sure.. that works... Is there an ETA for these two changes? I don't quite follow how the firmware change is supposed to work... The firmware is currently supposed to be a noarch package, and it gets built in the same pass as the kernel-docs sub-package, so it *shouldn't* be built in the same pass as the kernel. Is this flag to simply override that and build the firmware as an arch-specific package for simplified one-off builds? You bring up a pretty good point here Jarod, what happens with firmware for arch-specific drivers? The Makefile rules will have to be written in such a way that it gets built into the package despite the CONFIG_* symbol being unset on the build arch. r, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel-2.6.27-0.215.rc1.git4.fc10.i686 oops and no X :(
On Tue, Aug 05, 2008 at 12:37:32PM -0700, Antonio Olivares wrote: Dear fellow testers, New kernel oops again and no X when starting it kernel-2.6.27-0.215.rc1.git4.fc10.i686 Here's oops http://www.kerneloops.org/submitresult.php?number=48331 nasty... did this just start recently? Any thoughts, Dave? r, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel-2.6.27-0.215.rc1.git4.fc10.i686 oops and no X :(
On Tue, Aug 05, 2008 at 04:16:39PM -0400, Kyle McMartin wrote: On Tue, Aug 05, 2008 at 12:37:32PM -0700, Antonio Olivares wrote: Dear fellow testers, New kernel oops again and no X when starting it kernel-2.6.27-0.215.rc1.git4.fc10.i686 Here's oops http://www.kerneloops.org/submitresult.php?number=48331 nasty... did this just start recently? Any thoughts, Dave? fwiw this is hitting the BUG_ON in drm_open. mutex_lock(dev-struct_mutex); BUG_ON((dev-dev_mapping != NULL) (dev-dev_mapping != inode-i_mapping)); if (dev-dev_mapping == NULL) dev-dev_mapping = inode-i_mapping; mutex_unlock(dev-struct_mutex); ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware --without vdso_install build options
On Tue, Aug 05, 2008 at 04:19:07PM -0400, Chuck Ebbert wrote: That's what it does. It includes all firmware, even for drivers that don't get built. Look in firmware/Makefile and you'll see it builds lists named fw-shipped-y, fw-shipped-m and fw-shipped- then just merges them to create fw-shipped-all which it uses to build/install the firmware. Does this cover the case of firmware declared in Makefiles in subdirs that are obj-$(CONFIG_i) += subdir/? If so, cool, but I can't be arsed to check. cheers, kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
On Tue, Aug 05, 2008 at 05:05:33PM -0400, Chuck Ebbert wrote: John W. Linville wrote: I still think that for continuity's sake f8 and f9 should continue to get wireless fixes from 2.6.27. Those should only be specific bug fixes (although I suppose there is still time for a new driver), so hopefully the nattering nabobs won't be opposed to continuing with that part of the original plan. If you push wireless fixes to -stable Fedora would then get them for free. I don't see many wireless patches in there generally, though the ath5k memory corruption fix just went in. And new drivers would be great. Lots of people seem to want ath9k, for example. John has been forwarding me fixes, I just haven't gotten around to applying them yet. Will do so tonight. r, Kyle ___ 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:31:33PM -0400, Dave Jones wrote: 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. Perfmon adds a ridiculous number of syscalls, which means we *really* shouldn't merge it until they're reserved upstream, otherwise backwards compat woes will ensue. However, perfmon doesn't look like it is anywhere near being merged in the current form, so I'd rate it as unlikely upstream will reserve 10+ syscall entrypoints for it... NAK from me... cheers, Kyle ___ 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 Looks fine. Thanks Roland. cheers, Kyle ___ 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.651, 1.652 linux-2.6-debug-no-quiet.patch, 1.7, NONE
On Fri, May 23, 2008 at 06:19:40PM +, Kristian H?gsberg wrote: Log Message: * Fri May 23 2008 Kristian Høgsberg [EMAIL PROTECTED] - Drop linux-2.6-debug-no-quiet.patch. As discussed with Jeremy and Dave, it's time to drop this patch. Verbose output can still be enabled by specifying 'noisy' on the kernel command line instead of 'quiet'. Groovy! ___ 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:32:37PM -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!) This looks sane, from my quick once over and fairly novice understanding of rpm... ___ 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: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? cheers, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] Merge the IMAC mode code with efifb and remove imacfb entirely.
On Mon, Mar 24, 2008 at 05:43:15PM -0400, Peter Jones wrote:
This mail contains a patch which merges the IMAC mode code into the efifb
driver and removes the imacfb driver entirely. There are also a couple of
minor bug fixes. Any comments before I start bothering the upstream
maintainers with it?
snip
+ switch (model) {
+ case M_I17:
+ width = 1440;
+ height = 900;
+ linelength = 1472 * 4;
+ base = 0x8001;
+ break;
+ case M_I20:
+ width = 1680;
+ height = 1050;
+ linelength = 1728 * 4;
+ base = 0x8001;
+ break;
+ case M_MINI:
+ width = 1024;
+ height = 768;
+ linelength = 2048 * 4;
+ base = 0x8000;
+ break;
+ case M_MACBOOK:
+ width = 1280;
+ height = 800;
+ linelength = 2048 * 4;
+ base = 0x8000;
+ break;
+ }
Oh wow. This is... ultragroady. Couldn't we do something slightly
cleaner, like instead of setting the dmi private data to a int flag, set
it to a pointer to a struct efifb_params or something? This has the
potential to become a switch-of-doom...
Might be nice to put the Intel Mac specific code in its own source file
too?
+
+ if (!screen_info.lfb_depth)
+ screen_info.lfb_depth = 32;
+ if (!screen_info.pages)
+ screen_info.pages = 1;
+ if (base !screen_info.lfb_base)
+ screen_info.lfb_base = base;
+
+ if (manual_width)
+ width = manual_width;
+ if (width !screen_info.lfb_width)
+ screen_info.lfb_width = width;
+ if (manual_height)
+ height = manual_height;
+ if (height !screen_info.lfb_height)
+ screen_info.lfb_height = height;
+
+ /* just assume they're all unset if any are */
+ if (!screen_info.blue_size) {
+ screen_info.blue_size = 8;
+ screen_info.blue_pos = 0;
+ screen_info.green_size = 8;
+ screen_info.green_pos = 8;
+ screen_info.red_size = 8;
+ screen_info.red_pos = 16;
+ screen_info.rsvd_size = 8;
+ screen_info.rsvd_pos = 24;
+ }
+
+ if (linelength !screen_info.lfb_linelength)
+ screen_info.lfb_linelength = linelength;
And possibly slurp this out of line into a seperate setup_fb_from_param
function or something?
It looks kind of groady for something that isn't the common case... I
hope.
Awesome patch though, always good to see more - than + :)
cheers, Kyle
___
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.481, 1.482 linux-2.6-blkcipher-depend-on-chainiv.patch, 1.2, NONE
On Fri, Mar 07, 2008 at 05:56:01PM +, Dave Jones wrote: Log Message: I think 76fc60a2e3c6aa6e98cd3a5cb81a1855c637b274 obsoletes this. It does indeed, sorry, I meant to remove this after I saw it go in. cheers, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[PATCH] lguest: fix undefined asm-offsets symbols
lguest uses asm-offsets to generate ... offsets, obviously, for use in the lguest switcher code. When the hypervisor code is built as a module though, the asm offsets it needs won't be generated since CONFIG_LGUEST will be undefined. Signed-off-by: Kyle McMartin [EMAIL PROTECTED] --- diff --git a/arch/x86/kernel/asm-offsets_32.c b/arch/x86/kernel/asm-offsets_32.c index a33d530..44bafdd 100644 --- a/arch/x86/kernel/asm-offsets_32.c +++ b/arch/x86/kernel/asm-offsets_32.c @@ -134,7 +134,7 @@ void foo(void) OFFSET(LGUEST_DATA_pgdir, lguest_data, pgdir); #endif -#ifdef CONFIG_LGUEST +#if defined(CONFIG_LGUEST) || defined(CONFIG_LGUEST_MODULE) BLANK(); OFFSET(LGUEST_PAGES_host_gdt_desc, lguest_pages, state.host_gdt_desc); OFFSET(LGUEST_PAGES_host_idt_desc, lguest_pages, state.host_idt_desc); ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: can not resolve global kernel variable.
On Tue, Feb 19, 2008 at 01:41:15PM +0200, Eugene Goubine wrote: Hello , dear list users. From my module I am trying to register for the system suspend using the * register_pm_notifier(nb)* which is expanded to *blocking_notifier_chain_register(pm_chain_head, nb).* ** I have a linker warning which tells pm_chain_head is undefined. I do see pm_chain_head in my /proc/kallsyms. What do I miss? Thank you. It's hard to comment on it if you don't attach the source code... At a guess, you tried using register_pm_notifier, that failed to link, so you tried to use the function that it calls, which won't work since pm_chain_head is static to the kernel/power/main.c compilation unit. License your module under the GPL and add MODULE_LICENSE(GPL) and you'll be able to use the register_pm_notifier export... regards, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: can not resolve global kernel variable.
On Tue, Feb 19, 2008 at 06:43:16PM +0200, Eugene Goubine wrote: Kyle, thanks for reffering,but it seems like GPL is not the case. I want to write a module to track netdevices present. Sort of a protocol sitting there. It is GPL'ed, but register_pm_notifier usage ( as you can see in sources) gives linker warning pm_chain_head undefined,since register_pm_notifier is static inline and expanded to blocking_notifier_chain_unregister(pm_chain_head, nb). Why do you say pm_chain_head is static there ? Is it because it is not exported by EXPORT_SYMBOL ? What kernel are you building against? Do you have CONFIG_PM_SLEEP=y? cheers, Kyle So what does it have to do with the license ( which is already GPL, but I just do not understand ). nothing in particular, it's just a linking restriction that might have bitten you if you didn't know while writing your own module. (that there are two different kinds of export, i mean.) ___ 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. my logic was people could be running rawhide kernels on old userspace (i do this, for instance.) For Fedora 9 maybe it should be the sysfs interface if it works. i don't really see a harm in having both. For 8 it should be only procfs to be backwards compatible. I'll do that. agreed, don't want to tempt fate on f8... cheers, kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list ___ 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 01:50:00PM -0800, Roland McGrath wrote: M linux-2.6-i386-vdso-install-unstripped-copies-on-disk.patch needs a bit of inspection, looks right (and builds ok) This one should be upstream now. If anything is still missing, I should be able to get it in for 2.6.25. I needed the following patch to be able to build the fedora rpms on i386. This is likely a case of the new code doing the right thing, but me not being able to figure out the debug stuff in the spec file at the time though. cheers, Kyle diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile index d28dda5..dcbca17 100644 --- a/arch/x86/vdso/Makefile +++ b/arch/x86/vdso/Makefile @@ -7,8 +7,9 @@ VDSO32-$(CONFIG_X86_32) := y VDSO32-$(CONFIG_COMPAT):= y vdso-install-$(VDSO64-y) += vdso.so -vdso-install-$(VDSO32-y) += $(vdso32-y:=.so) - +vdso-install-$(VDSO32-y) += vdso32-sysenter.so $(vdso32-y:=.so) +vdso-install-$(CONFIG_X86_32) += vdso32-int80.so +vdso-install-$(CONFIG_COMPAT) += vdso32-syscall.so # files to link into the vdso vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vvar.o ___ 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 01:54:25PM -0500, Jarod Wilson wrote: On Monday 11 February 2008 12:53:40 pm Kyle McMartin wrote: git trees: firewire - commented out, pending didn't apply Yeah, the pending bits depend on some bits that are in linux1394-git that haven't yet made their way over to Linus, I believe. Figure I'll just fix things up after the rebase. if you want, you can attach a diff here and i'll put it into the first upload, or commit it with something like pending-rc1.patch or something and i'll move it when we update. cheers, kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: execshield inspection needed
On Sun, Feb 10, 2008 at 08:43:32PM -0500, Kyle McMartin wrote:
x86-merge has kind of thrown a spanner in the execshield patchset. I've
merged it up so it looks like it works, but I'd like to get some input
from others to make sure I didn't brown-paper-bag it.
The randomization bits seem to have been merged upstream, but I deferred
to the execshield implementation since they had some differences.
cheers,
Kyle
[linux-2.6-execshield.patch is attached.]
i appear to have noviced it and truncated the patch. i remerged it
against rc1... seems to work. i hope...
cheers,
kyle
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f86a3c4..4c5f70d 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -478,6 +478,13 @@ void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
* we do generic changes.
*/
+ if (exec_shield != 0) {
+#ifdef CONFIG_X86_PAE
+ if (!test_bit(X86_FEATURE_NX, c-x86_capability))
+#endif
+ clear_bit(X86_FEATURE_SEP, c-x86_capability);
+ }
+
/* If the model name is still unset, do table lookup. */
if ( !c-x86_model_id[0] ) {
char *p;
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index a7d50a5..83f7b4e 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -677,7 +677,8 @@ struct task_struct * __switch_to(struct task_struct
*prev_p, struct task_struct
/* never put a printk in __switch_to... printk() calls wake_up*()
indirectly */
__unlazy_fpu(prev_p);
-
+ if (next_p-mm)
+ load_user_cs_desc(cpu, next_p-mm);
/* we're going to use this soon, after a few expensive things */
if (next_p-fpu_counter 5)
@@ -842,8 +843,58 @@ unsigned long arch_align_stack(unsigned long sp)
return sp ~0xf;
}
-unsigned long arch_randomize_brk(struct mm_struct *mm)
+void arch_add_exec_range(struct mm_struct *mm, unsigned long limit)
+{
+ if (limit mm-context.exec_limit) {
+ mm-context.exec_limit = limit;
+ set_user_cs(mm-context.user_cs, limit);
+ if (mm == current-mm) {
+ preempt_disable();
+ load_user_cs_desc(smp_processor_id(), mm);
+ preempt_enable();
+ }
+ }
+}
+
+void arch_remove_exec_range(struct mm_struct *mm, unsigned long old_end)
{
- unsigned long range_end = mm-brk + 0x0200;
- return randomize_range(mm-brk, range_end, 0) ? : mm-brk;
+ struct vm_area_struct *vma;
+ unsigned long limit = PAGE_SIZE;
+
+ if (old_end == mm-context.exec_limit) {
+ for (vma = mm-mmap; vma; vma = vma-vm_next)
+ if ((vma-vm_flags VM_EXEC) (vma-vm_end limit))
+ limit = vma-vm_end;
+
+ mm-context.exec_limit = limit;
+ set_user_cs(mm-context.user_cs, limit);
+ if (mm == current-mm) {
+ preempt_disable();
+ load_user_cs_desc(smp_processor_id(), mm);
+ preempt_enable();
+ }
+ }
+}
+
+void arch_flush_exec_range(struct mm_struct *mm)
+{
+ mm-context.exec_limit = 0;
+ set_user_cs(mm-context.user_cs, 0);
+}
+
+/*
+ * Generate random brk address between 128MB and 196MB. (if the layout
+ * allows it.)
+ */
+void randomize_brk(unsigned long old_brk)
+{
+ unsigned long new_brk, range_start, range_end;
+
+ range_start = 0x0800;
+ if (current-mm-brk = range_start)
+ range_start = current-mm-brk;
+ range_end = range_start + 0x0200;
+ new_brk = randomize_range(range_start, range_end, 0);
+ if (new_brk)
+ current-mm-brk = new_brk;
}
diff --git a/arch/x86/kernel/setup64.c b/arch/x86/kernel/setup64.c
index 309366f..8a940dc 100644
--- a/arch/x86/kernel/setup64.c
+++ b/arch/x86/kernel/setup64.c
@@ -45,46 +45,6 @@ EXPORT_SYMBOL_GPL(__supported_pte_mask);
static int do_not_nx __cpuinitdata = 0;
-/* noexec=on|off
-Control non executable mappings for 64bit processes.
-
-on Enable(default)
-offDisable
-*/
-static int __init nonx_setup(char *str)
-{
- if (!str)
- return -EINVAL;
- if (!strncmp(str, on, 2)) {
-__supported_pte_mask |= _PAGE_NX;
- do_not_nx = 0;
- } else if (!strncmp(str, off, 3)) {
- do_not_nx = 1;
- __supported_pte_mask = ~_PAGE_NX;
-}
- return 0;
-}
-early_param(noexec, nonx_setup);
-
-int force_personality32 = 0;
-
-/* noexec32=on|off
-Control non executable heap for 32bit processes.
-To control the stack too use noexec=off
-
-on PROT_READ does not imply PROT_EXEC for 32bit processes
-offPROT_READ implies PROT_EXEC (default)
-*/
-static int __init nonx32_setup(char *str)
-{
- if (!strcmp(str
importing 2.6.25-rc1
git trees: firewire - commented out, pending didn't apply ext4 - commented out, seems upstream wireless - mostly upstream, pending didn't apply M linux-2.6-acpi-eeepc-hotkey.patch fixed rejects 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? :/ R linux-2.6-agp-mm.patch upstream R linux-2.6-alsa-rc4-mm1.patch R linux-2.6-alsa-support-sis7019.patch upstream (obviously :) M linux-2.6-build-nonintconfig.patch M linux-2.6-compile-fix-gcc-43.patch M linux-2.6-crash-driver.patch fixed rejects R linux-2.6-dcdbas-autoload.patch upstream M linux-2.6-debug-no-quiet.patch M linux-2.6-debug-sizeof-structs.patch M linux-2.6-debug-taint-vm.patch more rejects M linux-2.6-devmem.patch fixed rejects... maybe needs merging upstream R linux-2.6-drm-mm.patch R linux-2.6-drm-radeon-update.patch R linux-2.6-git-initial-r500-drm.patch upstream M linux-2.6-execshield.patch rejects fixed (hopefully) R linux-2.6-futex-fix-fixups.patch upstream M linux-2.6-gelic-fixups.patch M linux-2.6-input-kill-stupid-messages.patch M linux-2.6-lirc.patch M linux-2.6-silence-noise.patch M linux-2.6-squashfs.patch trivial rejects M linux-2.6-i386-vdso-install-unstripped-copies-on-disk.patch needs a bit of inspection, looks right (and builds ok) R linux-2.6-libata-pegasos-fix.patch upstream R linux-2.6-netdev-bonding-fix-null-deref.patch R linux-2.6-pasemi-for-2.6.25.patch R linux-2.6-pasemi-reserve-i2c.patch R linux-2.6-powerpc-bootwrapper.patch R linux-2.6-powerpc-generic-suspend-001-pmu-no-lock-kernel.patch R linux-2.6-powerpc-generic-suspend-002-pmu-remove-dead-code.patch R linux-2.6-powerpc-generic-suspend-003-remove-adb-sleep-notifier.patch R linux-2.6-powerpc-generic-suspend-004-kill-pmu-sleep-notifier.patch R linux-2.6-powerpc-generic-suspend-005-proper-sleep-management.patch R linux-2.6-unexport-symbols.patch upstream R linux-2.6-rndis_wlan.patch upstream? M linux-2.6-utrace-core.patch M linux-2.6-utrace-tracehook.patch pull-upstream.sh didn't fix this... so commented out in the build R linux-2.6-xfs-optimize-away-realtime-tests.patch R linux-2.6-xfs-setfattr-32bit-compat.patch R linux-2.6-xfs-xfs_mount-refactor.patch upstream(?) M nouveau-drm.patch rejects fixed... maybe should be updated... airlied? M sources M upstream ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
execshield inspection needed
x86-merge has kind of thrown a spanner in the execshield patchset. I've merged it up so it looks like it works, but I'd like to get some input from others to make sure I didn't brown-paper-bag it. The randomization bits seem to have been merged upstream, but I deferred to the execshield implementation since they had some differences. cheers, Kyle [linux-2.6-execshield.patch is attached.] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel build fails with GCC 4.3
On Thu, Jan 31, 2008 at 04:47:55PM -0800, Roland McGrath wrote: Why are we building kernels with this broken compiler? http://bugzilla.kernel.org/show_bug.cgi?id=8501 http://koji.fedoraproject.org/koji/getfile?taskID=388196name=build.log Why are we building these broken kernels with our shiny new compiler? Does using -ffreestanding fix these references to libgcc? I notice we're not using it when we build x86 or powerpc kernels, where we see this... cheers, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
