kernel April 2007

kernel@lists.fedoraproject.org

18 participants
11 discussions

[PATCH FC6] x86_64 page_is_ram() uses __initdata; breaks /dev/crash and /dev/mem restriction
by Dave Anderson 14 May '07

14 May '07

Somewhere after the 2.6.18 timeframe, Andi Kleen made the x86_64 e820 map __initdata: struct e820map e820 __initdata; This is fine for upstream x86_64 kernels, because the e820 map never gets used during runtime. But because we (RHEL/Fedora) have an x86_64 version of page_is_ram(), it ends up using __init data. I became aware of this when I got an FC6/crash-utility bugzilla #237383, filed because the crash utility started failing on later FC6 live systems. This is because the kernel's /dev/crash module crash.ko started failing because it uses page_is_ram() as a memory access qualifer. Also, because of Red Hat's restriction on the use of /dev/mem to only the first 256 RAM pages, the __initdata addition ends up opening the flood gates for /dev/mem usage. That's because of this: /* * devmem_is_allowed() checks to see if /dev/mem access to a certain address is * valid. The argument is a physical page number. * * * On x86-64, access has to be given to the first megabyte of ram because that area * contains bios code and data regions used by X and dosemu and similar apps. * Access has to be given to non-kernel-ram areas as well, these contain the PCI * mmio resources as well as potential bios/acpi data regions. */ int devmem_is_allowed(unsigned long pagenr) { if (pagenr <= 256) return 1; if (!page_is_ram(pagenr)) return 1; return 0; } The function is meant to allow /dev/mem accesses above pagenr 256 only if they are *not* RAM -- but since since page_is_ram() is failing, it inadvertantly allows access to any pagenr. (Interestingly enough, this bug allows the user of the crash utility to work around the /dev/crash failure by alternatively using /dev/mem instead! /dev/crash was only created to begin with because of the /dev/mem restriction... Anyway, reverting back from __initdata fixes the situation for both /dev/crash and the /dev/mem restriction. Dave Anderson (patch is against 2.6.20-1.2944) --- linux-2.6.20.x86_64/arch/x86_64/kernel/e820.c.orig 2007-04-26 14:38:12.000000000 -0400 +++ linux-2.6.20.x86_64/arch/x86_64/kernel/e820.c 2007-04-26 14:38:24.000000000 -0400 @@ -25,7 +25,7 @@ #include <asm/bootsetup.h> #include <asm/sections.h> -struct e820map e820 __initdata; +struct e820map e820; /* * PFN of last memory page.

2 1

Pre-release kernel versioning
by Thorsten Leemhuis 01 May '07

01 May '07

Hi all! I'd like to put a old but still valid discussion on the table again where a solution never was found: Pre-release kernel versioning. In short: Kernel like for example kernel-2.6.20-1.3066.fc7 are in reality 2.6.21-rc6-git5. That's not only confusing to users, it also breaks outside kernel modules sometimes; just yesterday I saw a patch in 3rd party repo applied that did this... +-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,21) ++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20) ...to make it compile against the kernel from FC4-test4 (no idea if it helped, but I had to apply similar patches in the past nyself to make somethign work), as the kernels in rawhide until they switched to 2.6.21-final announces itself as 2.6.20-1.3066.fc7 instead of 2.6.21-rc6-git5, as upstream would do. I don't want to get further into the details if I don't have to, as this stuff was discussed multiple times already on mailing lists. The last time was here: https://www.redhat.com/archives/fedora-devel-list/2007-March/msg00897.html So, what will we do in the future? Can we (after F7 is out and rawhide rolls again) please switch to something less confusing where version somehow allows normal users to clearly see what kernel they got? And one that doesn't confuse outside modules? Something like kernel-2.6.22-1.3200.fc7.rc2.git15 maybe? CU thl

7 17

Keep the FC6 kernel at 2.6.20 or move it to 2.6.21?
by Chuck Ebbert 01 May '07

01 May '07

The number of bugs reported against the FC6 kernel is now dropping. Should we move to kernel 2.6.21 and risk a whole new wave of bug reports, or leave it on 2.6.20 and live with the fact that some things can't/won't be fixed right, like support for PCI message signaled interrupts?

8 16

About audio programming
by bluehat prometheus 26 Apr '07

26 Apr '07

Hello! I want to know something more about audio programming on Fedora I using Fedora Core 4 ,by the way. But I have no idea about it, can anyone tell me how to do with it?? Such as which header file to use, libs, etc. Please give me a sample if you can.. Thanks,pretty thanks!!

1 0

[OT] please review new kernel build doc on fedora wiki
by Sam Folk-Williams 20 Apr '07

20 Apr '07

Hi, I (with DaveJ) help maintain the kernel release notes for Fedora. A user suggested a while back that we remove the building instructions from the release notes and put those in a separate doc devoted to more detailed instructions on building the kernel RPM (including applying patches and configuring options). I've got a draft doc now. I come to this from a support perspective - building kernels with patches I get from Engineering to pass on for testing. I'd like to get the point of view of some kernel developers as well. - Is what's here correct? - Is there more that should be here? - Does the info here conform to best practices? Any feedback appreciated. I am happy to make edits myself if you reply, or of course any one can make edits on their own. http://fedoraproject.org/wiki/Docs/Drafts/CustomKernel Thanks, Sam -- Sam Folk-Williams, RHCE Red Hat Global Support Services Phone: 919/754-4558 GPG ID: 1B0D46BA

4 6

Re: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21?
by Christopher Brown 19 Apr '07

19 Apr '07

> On 18.04.2007 23:23, Dave Jones wrote: > > On Wed, Apr 18, 2007 at 01:47:55PM -0700, Roland McGrath wrote: > > > I'd say let F7 testing iron out 2.6.21 for a while before deciding > about > > > FC6. We should be in the part of freeze where serious Fedora weenies > are > > > doing a lot of testing. > > Getting 2.6.21 into FC6 does also have the additional advantage that > > it's an extra round of testing for what will become the F7 kernel. > > +1 -- putting in in updates-testing quite soon might be a start. +1 for moving it straight into updates for reasons already stated plus isn't a kernel upgrade dependent on user confirmation? I have always felt for this reason that updates-testing is not the right place for testing kernels as the installonlyn plugin for yum ensures that a backup kernel (hopefully stable) is always available. Cheers Chris -- http://www.chruz.com

2 5

solved!!! VDSO support, 2.6.20-1.2925 hangs after unmounting old proc and sys
by Daniel Kirsten 13 Apr '07

13 Apr '07

Hallo, we discussed the following problem in march >my compiled 2.6.20-1.2925 kernel does not boot. >It hangs after unmounting the old proc and >sys filesystems. However, I can still use >Ctrl+Alt+Del to reboot. > >Maybe, the problem is related to Selinux. > >My compiled kernels 2.6.19-1.2895 and 2.6.19-1.2911 >worked fine, and I did not change the kernel >configuration. > >The Fedora-kernels 2.6.19-1.2895, 2.6.19-1.2911 and >2.6.20-1.2925 also work. The same problem occured in 2.6.20-1.2933. However, in a needle-in-the-haystick search, I solved the problem by DISabeling the option Compat VDSO support (COMPAT_VDSO) Best regards, Daniel

4 7

Spinning kernel-vanilla packages via standard spec
by Jarod Wilson 03 Apr '07

03 Apr '07

A little follow-on to the "Longing for git-bisect" thread, in a newly-created/subjected thread... So, I've been poking around in the kernel spec file extensively the past few days already... Any objections to my attempting to implement the building of a kernel-vanilla package as well? Roland, not sure if you were already planning to do this in conjunction with digging up your old patches, or if you were just throwing the patches out there, but either way, I'm happy to take on the task, but I'll defer to anyone else that really wants to do it. -- Jarod Wilson jwilson(a)redhat.com

2 8

Make "pci=nomsi" the default on 2.6.20 kernels?
by Chuck Ebbert 03 Apr '07

03 Apr '07

It seems like more and more problems with PCI MSI are turning up in the 2.6.20 kernel. Discussion upstream concluded that maybe it should have been off by default in 2.6.20, so maybe we should just do that in Fedora and make people who want it use "pci=msi" to enable it? It's probably not going to be really stable until 2.6.22...

6 13

Putting the full unstripped modules in the kernel-debuginfo package
by Chuck Ebbert 02 Apr '07

02 Apr '07

Right now we package the debuginfo so it contains only the DWARF debug information, but some utilities can't work with that. If we put the full modules with debug info in the package then everything should work, at the cost of making the package about 14MB larger. Is there any reason not to do this? (i686 debuginfo is about 175MB now.)

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel April 2007