May 2011 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] Retrieving patch rejects file from OBS
by Greg Freemyer 12 May '11

12 May '11

All, re: Adding ext4+ snapshots capability to a branched 2.6.38 kernel I branched 2.6.38.5 from Tumbleweed. home:next4 : next4-devel > kernel-source I've attempted to add a large patch to my project, but it is not applying: == from the build log + patch -s -F0 -E -p1 --no-backup-if-mismatch -i /usr/src/packages/BUILD/kernel-source-2.6.38.5/patches.ext4+/ext4_snapshot.patch 1 out of 74 hunks FAILED -- saving rejects to file fs/ext4/inode.c.rej 1 out of 33 hunks FAILED -- saving rejects to file fs/ext4/super.c.rej == Is there an easy way to get those to rej files out of OBS. Or do I have to figure out how to do a full local kernel build? (Since the source package is not building, that doesn't seem trivial.) Thanks Greg -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 8

[opensuse-kernel] Kernel:/stable/* repos
by Brian K. White 10 May '11

10 May '11

What happened to http://download.opensuse.org/repositories/Kernel:/stable/openSUSE_11.2 http://download.opensuse.org/repositories/Kernel:/stable/openSUSE_11.3 http://download.opensuse.org/repositories/Kernel:/stable/openSUSE_11.4 The rpm's are gone ? -- bkw -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

3 13

[opensuse-kernel] kernel-syms recommend instead of require kernel-*-devel?
by Stefan Seyfried 10 May '11

10 May '11

Hi, while upgrading my kernel to 2.6.39-rc6 (thanks, that will hopefully fix bnc#687998 for me), I found that zypper did not want to update kernel-syms et al due to missing kernel-xen-devel. I then selected "break kernel-syms by ignoring some deps" and "remove kernel-xen-devel". I know that I'll probably never need kernel-xen-devel (because I have perfectly fine Hardware, capable of KVM, there is no need to have a XEN kernel running on it), so it would be nice to save the download bandwidth and disk space of all those unnecessary kernel-*-devel by making them "recommended" instead of "required" IMHO. Opinions? -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 2

[opensuse-kernel] Is hiding the build host really needed?
by Jeff Mahoney 08 May '11

08 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - For quite some time we've carried a patch to obscure the build host in /proc/version so that it's always the same. It will always show up as (geeko@buildhost), even if it's not actually built for distribution. I looked at Ubuntu and Fedora, and they don't bother to obscure it. Is there any reason we should carry this patch indefinitely if nobody else bothers? - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3EgkkACgkQLPWxlyuTD7KFjwCgh5DzvykRtyVC/Eh52GFm9Vh8 QukAnjVBkDlpBDFOPgxW3yY4vPTQFcGC =5iZQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

4 5

[opensuse-kernel] [PATCH] Add support for per-kernel sysctl.conf files
by Jeff Mahoney 06 May '11

06 May '11

This patch adds support for per-kernel sysctl.conf files installed in /boot/sysctl.conf-$(uname -r). Since we don't really want to maintain yet another tree of mostly identical files, I implemented simple inheritance. The order of operation is, for flavor x86_64-desktop: - sysctl/defaults - sysctl/x86_64/arch-defaults - sysctl/x86_64/desktop I didn't bother implementing filtering, so using the example files below: - All flavors will get kernel.hung_task_timeout=0. - All x86_ flavors will also get vm.dirty_ratio=40. - x86-desktop will /also/ get vm.dirty_ratio=20. Since the sysctl lines are processed and overridden in order, this is fine. I have a separate (simple) patch to boot.sysctl to implement that part of it. Signed-off-by: Jeff Mahoney <jeffm(a)suse.com> --- rpm/kernel-binary.spec.in | 4 ++++ rpm/kernel-source.spec.in | 1 + scripts/tar-up.sh | 20 ++++++++++++++++++++ sysctl/defaults | 1 + sysctl/x86_64/arch-defaults | 1 + sysctl/x86_64/desktop | 1 + 6 files changed, 28 insertions(+), 0 deletions(-) diff --git a/rpm/kernel-binary.spec.in b/rpm/kernel-binary.spec.in index 3a82dee..9bed9a9 100644 --- a/rpm/kernel-binary.spec.in +++ b/rpm/kernel-binary.spec.in @@ -452,6 +452,10 @@ ln -s $image$suffix %buildroot/boot/$image$suffix ln -s initrd$suffix %buildroot/boot/initrd$suffix cp -p .config %buildroot/boot/config-%kernelrelease-%build_flavor +if [ -f %my_builddir/sysctl/%cpu_arch_flavor ]; then + cp -p %my_builddir/sysctl/%cpu_arch_flavor \ + %buildroot/boot/sysctl.conf-%kernelrelease-%build_flavor +fi %if %install_vdso # Install the unstripped vdso's that are linked in the kernel image diff --git a/rpm/kernel-source.spec.in b/rpm/kernel-source.spec.in index 6560706..1156d2a 100644 --- a/rpm/kernel-source.spec.in +++ b/rpm/kernel-source.spec.in @@ -101,6 +101,7 @@ Source111: patches.rt.tar.bz2 Source112: patches.trace.tar.bz2 Source113: patches.kabi.tar.bz2 Source120: kabi.tar.bz2 +Source121: sysctl.tar.bz2 BuildRoot: %{_tmppath}/%{name}-%{version}-build BuildArch: noarch Prefix: /usr/src diff --git a/scripts/tar-up.sh b/scripts/tar-up.sh index ffa4532..7ee43f3 100755 --- a/scripts/tar-up.sh +++ b/scripts/tar-up.sh @@ -311,6 +311,26 @@ done echo "kabi.tar.bz2" stable_tar $build_dir/kabi.tar.bz2 kabi +echo "sysctl.tar.bz2" +for config in $(scripts/guards --list < config.conf); do + arch=${config%%/*} + flavor=${config##*/} + + mkdir -p $tmpdir/sysctl/$arch + for file in sysctl/defaults sysctl/$arch/arch-defaults \ + sysctl/$arch/$flavor; do + if [ -f "$file" ]; then + cat $file + fi + done > $tmpdir/sysctl/$arch/$flavor +done + +# We don't need to ship empty files or directories +find $tmpdir/sysctl -size 0 -exec rm -f {} \; +rmdir $tmpdir/sysctl/* 2> /dev/null + +stable_tar -C $tmpdir $build_dir/sysctl.tar.bz2 sysctl + # Create empty dummys for any *.tar.bz2 archive mentioned in the spec file # not already created: patches.addon is empty by intention; others currently # may contain no patches. diff --git a/sysctl/defaults b/sysctl/defaults new file mode 100644 index 0000000..ac9d6d9 --- /dev/null +++ b/sysctl/defaults @@ -0,0 +1 @@ +kernel.hung_task_timeout=0 diff --git a/sysctl/x86_64/arch-defaults b/sysctl/x86_64/arch-defaults new file mode 100644 index 0000000..b6f94d4 --- /dev/null +++ b/sysctl/x86_64/arch-defaults @@ -0,0 +1 @@ +sys.vm.dirty_ratio=40 diff --git a/sysctl/x86_64/desktop b/sysctl/x86_64/desktop new file mode 100644 index 0000000..ef6e377 --- /dev/null +++ b/sysctl/x86_64/desktop @@ -0,0 +1 @@ +sys.vm.dirty_ratio=20 -- Jeff Mahoney SUSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

3 3

[opensuse-kernel] Crash with disk destroy
by Günther J. Niederwimmer 05 May '11

05 May '11

Hello, Is it possible to find this Problem in the Kernel ? openSUSE 11.4 when I like to change to console "Strg+Alt+F?" in the most time my system have a total crash with disk destroy? Only possible way is a "reset" After the restart I have a long list of "Inode" reconstruct entries from my "home" Partition ( /dev/md126p9) My System is a full Disk Raid 1 (Intel Board) -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 1

[opensuse-kernel] RFC: Use tarballs for -rc and stable releases?
by Michal Marek 04 May '11

04 May '11

Hi, currently, -rc and stable release updates are done by adding patches to patches.kernel.org/. Especially the -rc1 patches are *huge* and cannot be paired with any other object in the repository, so their gzip-compressed size adds to the total repository size: $ git cat-file -p b9044e3353ff21f12a86788a18cf36ba1071b6ab:patches.kernel.org/patch-2.6.37-rc1 | gzip -c -9 | wc -c 14627847 that is almost 14 megabytes. So I would like to propose to more or less discontinue patches.kernel.org and instead use the SRCVERSION variable in rpm/config.sh. This is already used in the vanilla and linux-next branches and it works. Code changes are more easily reviewed in the kernel.git nowadays, tar-up.sh and sequence-patch also work if you don't have the tarball around (it generates one from git, which is arguably slower, but works), so I think it's worth doing it. Opinions? Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 9

[opensuse-kernel] GCC 4.6 for 12.1
by Jeff Mahoney 02 May '11

02 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - I know someone else mentioned this briefly WRT to Tumbleweed, but I'd like to bring up for discussion the adoption of gcc 4.6 for Factory. A bit of background. We currently maintain a kernel-trace flavor to allow people to make use of the tracing facilities. Historically, there has been overhead associated with these, which is why they were in their own flavor. Most users don't care about them, so there's no sense in slowing everyone down to satisfy them. Over time, the maintainers of these facilities have worked to lower the overhead to the point where now dynamic ftrace only adds memory overhead. It uses gcc's profiling facility to call out to a function at the beginning of every function call to allow tracking. At boot, this is a function that returns immediately but during the boot process those calls are hot-patched to nop operations so that they carry virtually zero runtime overhead. This sounds great, right? There's one last bit, and that is actually the reason why ftrace is still disabled in our regular kernel flavors. The compiler's profiling feature calls the profiling function after the function prologue. That means that the stack pointer has already been advanced and since it can advance a different amount based on the needs of each function, we don't have an easy way to get the caller's stack frame back. It's needed to resolve where the caller was called from and the only way to do that is to dedicate a register to track the start of the current stack frame. Dedicating a register for this increases register contention and forces more accesses to CPU cache or main memory, slowing everything down. So, it's not worth it when most users will never actually take advantage of the feature that requires it. For some time, I've been trying to come up with ways to work around this so that the fast path stays fast and the tracing path takes any performance hit necessary. Until recently, the performance hit would've been too big to make it worthwhile. With gcc 4.6, we have the -mfentry option which moves the call to the profiling function *before* the function's prologue. This means that the caller's stack frame is still intact and we can resolve the caller's parent without issue. I've spent the past few days working up a proof of concept that takes advantage of this and doesn't require a dedicated register. It turns out that Steven Rostedt has already posted a patch set to do exactly this and he's targeting 2.6.40 for inclusion in the mainline kernel. For now it looks like it's x86-64 only but it should be ok for i386 as well. This would go a long way to eliminate the -trace flavor from our kernel packages. The benefits are multiple: It eliminates the maintenance of another kernel flavor, but it also allows everyone to use tracing facilities without installing a separate kernel release to do so. One last bit is needed, though, and that is for gcc to allow using -pg - -mfentry with -fomit-frame-pointers. Once that bit is taken care of then we can rid the kernel of the frame pointer requirement for ftrace and eliminate the -trace flavor entirely. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk263RwACgkQLPWxlyuTD7JhyQCfXcCcDjH0dYmnoguTCe+7J2FH YWkAn3+K1qintX3acivGSmUYCDVnDuqi =3BMz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

8 13

[opensuse-kernel] A libre version of the kernel to openSUSE
by José Luis Maqueda 01 May '11

01 May '11

Hi. I am working to package a libre version of the kernel to openSUSE. I use a clean tarball of Linux-libre project [ http://linux-libre.fsfla.org/ ] I invite others to collaborate. This is a repo: http://download.opensuse.org/repositories/home:/maquedam:/ And my OBS project: https://build.opensuse.org/project/show?project=home%3Amaquedam%3AKernel-li… Regards! -- José Luis A tlamaki (libre) developer. :-) http://hackers.tlamaki.org/author/joseluis/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0