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
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
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
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
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
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
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
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
-----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