February 2011 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] [patch #2 0/5] scripts/sequence-patch.sh: Add some useful options
by Jeff Mahoney 05 Oct '11

05 Oct '11

Hi all - There are a few things I do every time I expand the source tree with sequence-patch.sh. Or, rather, things I should do and forget to do a lot. The first I always remember to do: Copy the config I want to test with to my build directory. The second I forget more often than not: Expand the kABI references into my build directory. One of the things that bites me occasionally is when there are kABI changes that go un-noticed until the automated build checker flags them and sends me an email yelling at me for my carelessness. This patch adds three options to scripts/sequence-patch.sh to take care of these automatically. --build-dir=PATH allows you to specify the build directory you'll be using. It will create the directory if it doesn't exist. It defaults to $PATCH_DIR. --config=ARCH-FLAVOR allows you to specify the config you'll use. It will copy the config to your build directory. It is not a fatal error if the config does not exist. It will just not copy one. --kabi allows you to direct sequence-patch to expand the kABI references into your build directory. Since the references are arch/flavor specific, it depends on --config=ARCH-FLAVOR. It is not a fatal error if the kABI reference doesn't exist since this is always the case in the master branch. The --build-dir PATH is subject to shell expansion. It is expanded late enough in the script that most variables should be available. There are also three new variables available when --config is used: $CONFIG contains the --config contents. $CONFIG_ARCH contains the arch part of the config. $CONFIG_FLAVOR contains the flavor part. For reference, I have this in my .bashrc: export SEQUENCE_PATCH_ARGS="--config=x86_64-desktop --build-dir=~/src/scratch/build/\$CONFIG_ARCH/linux-\$SRCVERSION-\$TAG-\$CONFIG_FLAVOR --kabi" I've also added patches for --ctags and --cscope which will automatically generate the databases for either of those tools in the build directory after the source tree is expanded. - Issues addressed in patchset #2: - Help text is now a here document for easy addition of more documentation - Explanation of which variables are allowed by --build-dir - Missing rpm/modversions script is not an error on older branches - Missing symvers files are not errors - Uses true/false for simple feature flags -Jeff -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

5 13

[opensuse-kernel] [PATCH] scripts: add patch-tags-from-git
by Brandon Philips 09 Mar '11

09 Mar '11

usage: patch-tags-from-git <filename> <kernel checkout> Adds a Git-commit: tag from the From header also adds a Patch-mainline: tag if <kernel checkout> is given Signed-off-by: Brandon Philips <bphilips(a)suse.de> --- scripts/patch-tags-from-git | 62 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 62 insertions(+), 0 deletions(-) create mode 100755 scripts/patch-tags-from-git diff --git a/scripts/patch-tags-from-git b/scripts/patch-tags-from-git new file mode 100755 index 0000000..2277376 --- /dev/null +++ b/scripts/patch-tags-from-git @@ -0,0 +1,62 @@ +#!/bin/bash +# Add suse Kernel repo headers to a patch created using git-format-patch +# +# Brandon Philips <bphilips(a)suse.de> + +if [ $# -lt 1 ]; then + echo "usage: $0 <filename> <kernel checkout>" + echo "Adds a Git-commit: tag from the From header" + echo "also adds a Patch-mainline: tag if <kernel checkout> is given" + exit 1 +fi + +FILE=$1 + +if [ ! -f $FILE ]; then + echo "No such file $1" + exit 2 +fi + +commit=$(head -n1 $FILE | sed -n "s%From\s$[0-9a-f]*$\s.*%\1%p") + +if [ "z$commit" = "z" ]; then + echo "$FILE doesn't look like a patch from git" +else + patch-tag -A git-commit="$commit" $FILE +fi + +if [ $# -ne 2 ]; then + exit 0 +fi + +DIR=$2 + +commit=$(patch-tag -p git-commit $FILE | grep -i "git-commit:" | sed "s%.*:\s$.*$%\1%g") + +if [ "z$commit" = "z" ]; then + echo "No git-commit tag in $FILE" + exit 3 +fi + +export GIT_DIR=$DIR/.git + +if [ ! -d $GIT_DIR ]; then + echo "No such directory $GIT_DIR" + echo 4 +fi + +mainline=$(git describe --contains $commit 2> /dev/null) + +if [ "z$mainline" = "z" ]; then + git show $commit > /dev/null + if git show $commit > /dev/null 2> /dev/null; then + merged=$(basename $DIR) + patch-tag -A Patch-mainline="Merged into $merged" $FILE + exit 0 + else + echo "$commit from $FILE does not exist in $DIR" + exit 5 + fi +fi + +patch-tag -A Patch-mainline="$mainline" $FILE -- 1.7.2.2 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

3 4

[opensuse-kernel] openSUSE - User Mode Linux
by Sankar P 02 Mar '11

02 Mar '11

Hi, I am trying to see what user mode linux is and trying to see how one can use userspace tools like callgrind, valgrind to debug the kernel. I followed the instructions in the UML wiki (http://user-mode-linux.sourceforge.net/ ) . I found that after compiling the kernel sources (Linus' tree) with ARCH=um option, I need to download a root filesystem which is based of fedora. Instead of downloading that I would like to know if there is any other root filesystem that I can use which is based on SUSE. I have not looked into the wiki page in detail to find out how I can create my custom root filesystem image for UML. But before that I wanted to check if there is any openSUSE based root image, that I can just download and use. Sorry if something is wrong in my mail due to a misunderstanding. Thanks. -- Sankar P http://psankar.blogspot.com -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 3

[opensuse-kernel] getting btrfs to find & assemble raid array on boot?
by dev001x 23 Feb '11

23 Feb '11

i'm working on using btrfs with our newer kernels. atm i've, uname -a Linux test 2.6.37.1-4-xen #1 SMP 2011-02-20 11:37:34 +0100 x86_64 x86_64 x86_64 GNU/Linux lsb_release -d Description: openSUSE 11.3 (x86_64) chatting @ #btrfs, 1st order of business was an up-to-date version of btrfs progs: zypper rm btrfsprogs git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git cd /usr/local/src/btrfs-progs-unstable make -j5 make install rehash btrfs --help | grep "Btrfs v" Btrfs v0.19-35-g1b444cd with that, mkfs.btrfs -L BTRFS_POOL -m raid10 -d raid10 /dev/sd[abcd] btrfs fi show Label: none uuid: d45db479-5447-3ac8-80db-6464a381d3a5 Total devices 4 FS bytes used 28.00KB devid 1 size 931.51GB used 2.03GB path /dev/sda devid 2 size 931.51GB used 2.01GB path /dev/sdb devid 3 size 931.51GB used 2.01GB path /dev/sdc devid 4 size 931.51GB used 2.01GB path /dev/sdd mount /dev/sda /mnt df -h | grep /mnt /dev/sda 3.7T 40K 3.7T 1% /mnt btrfs fi df /mnt Data, RAID10: total=2.00GB, used=0.00 Data: total=8.00MB, used=0.00 System, RAID10: total=16.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, RAID10: total=2.00GB, used=8.00KB Metadata: total=8.00MB, used=16.00KB which is all fine. on reboot, iiuc, btrfs module is supposed to find & auto-assemble the array. but, shutdown -r now btrfs fi show Btrfs v0.19-35-g1b444cd fdisk -l | grep /dev/sd | grep GB Disk /dev/sda: 1000.2 GB, 1000204886016 bytes Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes btrfs device scan Scanning for Btrfs filesystems btrfs fi show Btrfs v0.19-35-g1b444cd so the disks are there, but seemingly btrfs array metadata is not found ... recreating, mkfs.btrfs -L BTRFS_POOL -m raid10 -d raid10 /dev/sd[abcd] btrfs fi show Label: 'BTRFS_POOL' uuid: fe927b40-8fe1-430f-ae72-fbe8f1292b4b Total devices 4 FS bytes used 28.00KB devid 1 size 931.51GB used 2.03GB path /dev/sda devid 2 size 931.51GB used 2.01GB path /dev/sdb devid 3 size 931.51GB used 2.01GB path /dev/sdc devid 4 size 931.51GB used 2.01GB path /dev/sdd Btrfs v0.19-35-g1b444cd all's again in existence -- noting, of course, the new/different UUID. unclear whether whatever info btrfs needs to find & autoassemble the array is missing in my conf/process, in initrd, in kernel, init scripts, etc. any guidance? thanks -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0

[opensuse-kernel] linux-next packages for openSUSE
by Michal Marek 23 Feb '11

23 Feb '11

Hi, If you are using opensuse and want to contribute to kernel development by testing the linux-next tree, reporting bugs and verifying fixes, you now have a convenient way: # zypper addrepo --refresh \ http://download.opensuse.org/repositories/Kernel:/linux-next/standard \ linux-next # zypper install --from linux-next kernel-vanilla and then just do 'zypper install kernel-vanilla' (*) every day. The packages are updated daily by a script and fixed by me as necessary, so they might be lagging behind at times. The config is previous config + allmodconfig for new options, so some unwanted debug options can creep in occasionally. The build logs are here: https://build.opensuse.org/project/monitor?project=Kernel%3Alinux-next the configs are here: http://gitorious.org/opensuse/kernel-source/trees/linux-next/config Please report installation and config issues to opensuse-kernel(a)opensuse.org, everything else should go to the upstream mailing lists as usual. Happy testing. Oh, and there are also builds of latest Linus' tree and latest stable: http://download.opensuse.org/repositories/Kernel:/vanilla/standard/ http://download.opensuse.org/repositories/Kernel:/stable/openSUSE_Factory/ Michal (*) The name kernel-vanilla might be a bit confusing; in the suse build scripts it means "upstream kernel without suse patches", not necessarily Linus' kernel. -- 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] kernel-$flavour-devel from Kernel:stable
by Mariusz Fik 21 Feb '11

21 Feb '11

When we update kernel-$flavour-devel via `zypper in kernel-$flavour-devel` it doesn't force update of kernel-$flavour. Is it normal behaviour or we miss some Requires in kernel-$flavour-devel package?. For now, it has: |rpmlib(VersionedDependencies) <= 3.0.3-1 |kernel-devel = 2.6.37.1-2 |/bin/sh |/bin/sh |rpmlib(PayloadFilesHavePrefix) <= 4.0-1 |rpmlib(CompressedFileNames) <= 3.0.4-1 |libc.so.6 |libc.so.6(GLIBC_2.0) |libc.so.6(GLIBC_2.1) |libc.so.6(GLIBC_2.3) |libc.so.6(GLIBC_2.3.4) |libc.so.6(GLIBC_2.7) |rpmlib(PayloadIsLzma) <= 4.4.6-1 -- Pozdrawiam / Best regards, Mariusz Fik openSUSE Community Member

2 1

[opensuse-kernel] suspend fails on 2.6.37.1
by Michael Großhäuser 21 Feb '11

21 Feb '11

Hi, with kernel 2.6.37.1 from Kernel:/stable/openSUSE_11.3 suspend fails on my HP 2510p. dmesg output is: tpm_tis 00:02: Operation Timed out legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -62 PM: Device 00:02 failed to suspend: error -62 PM: Some devices failed to suspend after unloading the tpm modules (tpm_tis,tpm_infineon and tpm) the problem is gone. With kernel 2.6.37 suspend works without problems. Is there any fix available? Thanks, Michael -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

3 4

[opensuse-kernel] threads and/or memory MUCH slower on 2.6.37 than 2.6.34 ?
by Richard Ems 15 Feb '11

15 Feb '11

Hi list, I was trying to check if updating to 2.6.37 on our openSUSE 11.3 nodes would bring any performance changes for our application (HPC CFD programs) and was surprised to see a big performance decrease on my test runs. Trying to follow this problem down I came to the following perl test line to show the differences. If I run the following perl line on the same hardware on openSUSE 11.3, with 2.6.34.7-0.5-default and with 2.6.37-6-default (from http://download.opensuse.org/repositories/Kernel:/stable/openSUSE_11.3/x86_… ) I get VERY different results: On 2.6.34 it runs in about 10 secs. On 2.6.37 it takes at least 17 secs to run. Could someone else test this on another hardware? Please run a couple of times with 2.6.34 and then with 2.6.37. Do others also see this big differences? The system I am testing on is a dual Xeon X5650 @ 2.67 GHz (12 cores) with 24 GB memory. Please set $T to your number of cores. Perhaps you would also have to reduce the (1..9e6) if you have less than 2GB per core. time perl -e 'use threads; $T=12 ; foreach (1..$T) { $thr[$i++] = threads->create(sub { printf "I am thread %s\n", threads->tid(); foreach (1..9e6) { push(@a, sqrt(1234)/sin(1234)) } ; printf "thread %s finished.\n", threads->tid(); }); } foreach (0..$T-1) { $thr[$_]->join(); }' Many thanks for testing! Does anyone have an idea why this could be happening? Richard -- Richard Ems mail: Richard.Ems(a)Cape-Horn-Eng.com Cape Horn Engineering S.L. C/ Dr. J.J. Dómine 1, 5º piso 46011 Valencia Tel : +34 96 3242923 / Fax 924 http://www.cape-horn-eng.com -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

4 7

[opensuse-kernel] Re: [opensuse-factory] RFC: Staging driver communication
by Michal Marek 10 Feb '11

10 Feb '11

On 10.2.2011 09:45, Ludwig Nussel wrote: > Jeff Mahoney wrote: >> Wouldn't >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;… >> essentially do the same thing? > > Patches would still need to be included in the huge kernel package > with all it's special magic and processes though. You send the backported patch, with the upstream commit id included, to stable(a)kernel.org. The rest of the process is handled by Greg :). Michal -- 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: Staging driver communication
by Jeff Mahoney 09 Feb '11

09 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - One of the things I've seen cropping up lately is the number of bug reports that involve staging drivers. For the uninitiated, staging drivers are drivers that have been included in the kernel but are known to be of insufficient quality to be considered for "true" inclusion. Sometimes drivers in staging are improved and "promoted" to full inclusion and other times they are considered abandoned and are dropped entirely. One common example is the rt2860 driver. When I find the time, which is becoming rarer these days, I try to backport fixes to this driver to the 11.3 kernel since the hardware seems common enough. The issue as I see it is that we have no way to communicate to the user that the driver they're using is of dubious quality. In an ideal world, we could take the bug reports and fix the upstream driver. In reality, most of us don't have the time to tackle improving a driver for hardware we don't have. So, what's the best way to communicate this to the user? Here's my list but I'm open to suggestions: 1) Move staging drivers to a separate package that isn't installed by default 2) Issue a warning during install or first driver load that the driver is of dubious quality 3) Use something like the flags we use in the SLE kernels to document a driver as supported or not to prevent the driver from being loaded without explicitly enabling it (preferably combined with #2) 4) Add a release note documenting which drivers are staging and hope that users actually read it (unlikely) 5) Don't change anything - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1StIYACgkQLPWxlyuTD7LNoQCeLZMvEOfv4dEqeZ5INr8kCFkc y40AoJIdXIZceIIEj7liktJtzSl4+7QY =NaWq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 4