openSUSE Kernel November 2012

kernel@lists.opensuse.org

28 participants
18 discussions

[opensuse-kernel] CONFIG_CC_STACKPROTECTOR
by richard -rw- weinberger 14 Dec '13

14 Dec '13

Hi! I'm wondering why CONFIG_CC_STACKPROTECTOR is disabled on openSUSE. Debian and Fedora seem to enabled it per default. What's the deal? -- Thanks, //richard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

7 17

[opensuse-kernel] Use ext4 kernel driver for ext3 filesystems?
by Jan Kara 10 Dec '12

10 Dec '12

Hello, so it has been about 1 year since openSUSE uses ext4 kernel driver for ext2 filesystems. I haven't heard any complaints so I feel it's time to do the same for ext3 as well. Fedora actually uses this setting for over an year already so it's not like we are going to use something heavily experimental. I'd just add that this transition is desirable as ext3 is slowly being deprecated upstream in favor of ext4 (so that we can get rid of similar code bases). Anyone has any objections? Honza -- Jan Kara <jack(a)suse.cz> SUSE Labs, CR -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 2

[opensuse-kernel] [PATCH] Use new suse-module-tools package
by Jan Engelhardt 06 Dec '12

06 Dec '12

The "weak-modules" programs moved to "suse-module-tools" in openSUSE 12.3. "modutils" is an unversioned virtual provides to get at an implementation that has the "insmod", "modprobe"-named executables. Because "modutils" is not even new, it is now unconditionally used in macros.kernel-source. --- rpm/kernel-binary.spec.in | 8 ++++++-- rpm/macros.kernel-source | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/rpm/kernel-binary.spec.in b/rpm/kernel-binary.spec.in index 26e2332..654c7c2 100644 --- a/rpm/kernel-binary.spec.in +++ b/rpm/kernel-binary.spec.in @@ -62,7 +62,7 @@ Release: @RELEASE@ License: GPL-2.0 Group: System/Kernel Url: http://www.kernel.org/ -BuildRequires: coreutils module-init-tools sparse +BuildRequires: coreutils modutils sparse BuildRequires: fdupes Provides: multiversion(kernel) Provides: %{name}_%_target_cpu = %version-%release @@ -73,8 +73,12 @@ Provides: kernel-base = %version-%source_rel Obsoletes: %name-base <= 2.6.31 %endif Requires(pre): coreutils awk -# Need a module-init-tools with /usr/lib/module-init-tools/weak-modules2 +# We need the weak-modules2 utility +%if 0%{?suse_version} >= 1230 +Requires(post): suse-module-tools +%else Requires(post): module-init-tools >= 3.4 +%endif # This Requires is wrong, because the post/postun scripts have a # test -x update-bootloader, having perl-Bootloader is not a hard requirement. # But, there is no way to tell rpm or yast to schedule the installation diff --git a/rpm/macros.kernel-source b/rpm/macros.kernel-source index f584129..27fa8bb 100644 --- a/rpm/macros.kernel-source +++ b/rpm/macros.kernel-source @@ -1,6 +1,6 @@ # A few cross-distro definitions: %kernel_module_package_release 1 -%kernel_module_package_buildreqs module-init-tools kernel-syms +%kernel_module_package_buildreqs modutils kernel-syms # Defines %flavors_to_build and %kernel_source() as a side effect. %_kernel_module_package(n:v:r:t:f:Xp:b) \ -- 1.7.10.4 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 5

[opensuse-kernel] Constant crash under a 12.1-default kernel
by Bruno Friedmann 27 Nov '12

27 Nov '12

I pick several of those per day [867184.522832] The following is only an harmless informational message. [867184.522841] Unless you get a _continuous_flood_ of these messages it means [867184.522846] everything is working fine. Allocations from irqs cannot be [867184.522850] perfectly reliable and the kernel is designed to handle that. [867184.522857] kworker/0:1: page allocation failure. order:1, mode:0x20 [867184.522865] Pid: 0, comm: kworker/0:1 Not tainted 3.1.10-1.16-default #1 [867184.522870] Call Trace: [867184.522900] [<ffffffff810042fa>] dump_trace+0x9a/0x270 [867184.522915] [<ffffffff81527ce8>] dump_stack+0x69/0x6f [867184.522929] [<ffffffff810f5d6e>] warn_alloc_failed+0xfe/0x1b0 [867184.522944] [<ffffffff810f9e96>] __alloc_pages_nodemask+0x6b6/0x900 [867184.522959] [<ffffffff81136a68>] kmem_getpages+0x48/0x150 [867184.522971] [<ffffffff8113773d>] fallback_alloc+0x17d/0x230 [867184.522984] [<ffffffff81137fa3>] kmem_cache_alloc+0x143/0x1a0 [867184.522999] [<ffffffff81415783>] sk_prot_alloc+0x43/0x200 [867184.523012] [<ffffffff8141650a>] sk_clone+0x1a/0x300 [867184.523023] [<ffffffff81461d50>] inet_csk_clone+0x10/0xc0 [867184.523037] [<ffffffff8147a211>] tcp_create_openreq_child+0x21/0x460 [867184.523050] [<ffffffff81478817>] tcp_v4_syn_recv_sock+0x47/0x280 [867184.523062] [<ffffffff8147adaf>] tcp_check_req+0x2ff/0x4c0 [867184.523075] [<ffffffff81477a8a>] tcp_v4_hnd_req+0x6a/0x130 [867184.523087] [<ffffffff81478513>] tcp_v4_do_rcv+0x123/0x1d0 [867184.523100] [<ffffffff81479cd9>] tcp_v4_rcv+0x559/0x810 [867184.523114] [<ffffffff814575ec>] ip_local_deliver_finish+0xcc/0x270 [867184.523125] [<ffffffff81426cb2>] __netif_receive_skb+0x482/0x520 [867184.523138] [<ffffffff814274d0>] netif_receive_skb+0x70/0x80 [867184.523149] [<ffffffff814275e8>] napi_skb_finish+0x38/0x50 [867184.523191] [<ffffffffa0215067>] e1000_clean_rx_irq+0x2a7/0x440 [e1000e] [867184.523303] [<ffffffffa0217444>] e1000_clean+0x74/0x130 [e1000e] [867184.523393] [<ffffffff81427cf9>] net_rx_action+0x119/0x260 [867184.523406] [<ffffffff8105927d>] __do_softirq+0x9d/0x1f0 [867184.523420] [<ffffffff8154a02c>] call_softirq+0x1c/0x30 [867184.523432] [<ffffffff81004175>] do_softirq+0x65/0xa0 [867184.523443] [<ffffffff81059656>] irq_exit+0x96/0xc0 [867184.523456] [<ffffffff81003d9c>] do_IRQ+0x5c/0xd0 [867184.523468] [<ffffffff815403ee>] common_interrupt+0x6e/0x6e [867184.523485] [<ffffffff81029af2>] native_safe_halt+0x2/0x10 [867184.523497] [<ffffffff8100a21d>] default_idle+0x4d/0x1d0 [867184.523509] [<ffffffff8100a42b>] amd_e400_idle+0x8b/0x110 [867184.523522] [<ffffffff8100119f>] cpu_idle+0x7f/0xd0 [867184.523542] The following is only an harmless informational message. [867184.523547] Unless you get a _continuous_flood_ of these messages it means [867184.523552] everything is working fine. Allocations from irqs cannot be [867184.523557] perfectly reliable and the kernel is designed to handle that. [867184.523563] kworker/0:1: page allocation failure. order:1, mode:0x20 [867184.523571] Pid: 0, comm: kworker/0:1 Not tainted 3.1.10-1.16-default #1 [867184.523576] Call Trace: [867184.523589] [<ffffffff810042fa>] dump_trace+0x9a/0x270 [867184.523601] [<ffffffff81527ce8>] dump_stack+0x69/0x6f [867184.523612] [<ffffffff810f5d6e>] warn_alloc_failed+0xfe/0x1b0 [867184.523625] [<ffffffff810f9e96>] __alloc_pages_nodemask+0x6b6/0x900 [867184.523639] [<ffffffff81136a68>] kmem_getpages+0x48/0x150 [867184.523650] [<ffffffff8113773d>] fallback_alloc+0x17d/0x230 [867184.523664] [<ffffffff81137fa3>] kmem_cache_alloc+0x143/0x1a0 [867184.523677] [<ffffffff81415783>] sk_prot_alloc+0x43/0x200 [867184.523690] [<ffffffff8141650a>] sk_clone+0x1a/0x300 [867184.523701] [<ffffffff81461d50>] inet_csk_clone+0x10/0xc0 [867184.523713] [<ffffffff8147a211>] tcp_create_openreq_child+0x21/0x460 [867184.523727] [<ffffffff81478817>] tcp_v4_syn_recv_sock+0x47/0x280 [867184.523740] [<ffffffff8147adaf>] tcp_check_req+0x2ff/0x4c0 [867184.523753] [<ffffffff81477a8a>] tcp_v4_hnd_req+0x6a/0x130 [867184.523766] [<ffffffff81478513>] tcp_v4_do_rcv+0x123/0x1d0 [867184.523779] [<ffffffff81479cd9>] tcp_v4_rcv+0x559/0x810 [867184.523792] [<ffffffff814575ec>] ip_local_deliver_finish+0xcc/0x270 [867184.523803] [<ffffffff81426cb2>] __netif_receive_skb+0x482/0x520 [867184.523817] [<ffffffff814274d0>] netif_receive_skb+0x70/0x80 [867184.523828] [<ffffffff814275e8>] napi_skb_finish+0x38/0x50 [867184.523857] [<ffffffffa0215067>] e1000_clean_rx_irq+0x2a7/0x440 [e1000e] [867184.523959] [<ffffffffa0217444>] e1000_clean+0x74/0x130 [e1000e] [867184.524048] [<ffffffff81427cf9>] net_rx_action+0x119/0x260 [867184.524061] [<ffffffff8105927d>] __do_softirq+0x9d/0x1f0 [867184.524073] [<ffffffff8154a02c>] call_softirq+0x1c/0x30 [867184.524085] [<ffffffff81004175>] do_softirq+0x65/0xa0 [867184.524096] [<ffffffff81059656>] irq_exit+0x96/0xc0 [867184.524109] [<ffffffff81003d9c>] do_IRQ+0x5c/0xd0 [867184.524120] [<ffffffff815403ee>] common_interrupt+0x6e/0x6e [867184.524135] [<ffffffff81029af2>] native_safe_halt+0x2/0x10 [867184.524146] [<ffffffff8100a21d>] default_idle+0x4d/0x1d0 [867184.524158] [<ffffffff8100a42b>] amd_e400_idle+0x8b/0x110 [867184.524170] [<ffffffff8100119f>] cpu_idle+0x7f/0xd0 What would be the best approach to start digging those crash ? Unfortunately, this is on a production server and thus not that easy to stop or run in full debug mode. Thanks for any input -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 4

[opensuse-kernel] toogle CONFIG_CIFS_SMB2 y
by Cristian Rodríguez 27 Nov '12

27 Nov '12

Hi: Will be cool if CONFIG_CIFS_SMB2 is enabled in our kernels... yes.. it is experimental but requires explicit mount option to enable so I guess it is safe for regular users and handy for us in the bleeding edge. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

4 14

[opensuse-kernel] RealTime kernel
by Andrew Wafaa 27 Nov '12

27 Nov '12

Could someone provide a link to the RT kernel that is used in SUSE, please? I've looked on OBS but can't find anything. I'd like to see what patches are applied etc, and also to see how it well it works on ARM. Thanks, Andy -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

4 7

[opensuse-kernel]
by 胡浩 27 Nov '12

27 Nov '12

opensuse-kernel subscribe -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 0

[opensuse-kernel] How to run xfstests against btrfs on multipath disks?
by Ryan Wang 27 Nov '12

27 Nov '12

Hello, I tried to kick off xfstests against btrfs on multipath device, e.g I set TEST_DEV="/dev/mapper/mpatha", which is a symlink to "/dev/dm-0". I mkfs.btrfs mpatha beforehand. When I run "./check 001", it said: " common.rc: Error: $TEST_DEV (/dev/dm-0) is not a MOUNTED btrfs filesystem " The I checked the script common.rc, and found that it uses df to determine the filesystem type and it uses the realpath "/dev/dm-0" instead of "/dev/mapper/mpatha", while df always shows "devtmpfs" instead of "btrfs" for /dev/dm-0. I run "mount" and found that devtmpfs is mount on /dev/ ***by default***. Even though I run "mount -t btrfs /dev/dm-0 /somedir", df still showed devtmpfs. Any ideas to kick off the xfstests? thanks, -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 3

[opensuse-kernel] kernel-cubox fails to build
by Cristian Rodríguez 24 Nov '12

24 Nov '12

Hi: Can anyone experienced with the kernel packages plz fix kernel-cubox (openSUSE:Factory:ARM) ? [ 262s] Xen guest support on ARM (EXPERIMENTAL) (PARAVIRT_XEN) [N/y/?] (NEW) aborted! [ 262s] [ 262s] Console input/output is redirected. Run 'make oldconfig' to update configuration. [ 262s] [ 262s] make[2]: *** [silentoldconfig] Error 1 [ 262s] make[1]: *** [silentoldconfig] Error 2 [ 262s] make: *** [sub-make] Error 2 [ 262s] make: Leaving directory `/home/abuild/rpmbuild/BUILD/kernel-cubox-3.7.rc6/linux-3.7-rc6' [ 262s] error: Bad exit status from /var/tmp/rpm-tmp.y1BWhw (%prep) [ 262s] [ 262s] [ 262s] RPM build errors: [ 262s] Bad exit status from /var/tmp/rpm-tmp.y1BWhw (%prep) [ 264s] /.build/build: line 313: 227 Killed background_monitor_process / &>/dev/null [ 266s] [ 198.082408] SysRq : Power Off [ 266s] [ 198.092423] Power down. Thanks. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 0

[opensuse-kernel] Auto suspend does not connect wifi right, when waking up.
by Oddball 20 Nov '12

20 Nov '12

Hi, I do not know where to place this message, so i place it here. With the last two KOTD's, i notice that when waking from autosuspend/sleep, the network does not connect properly. I have to deactivate and activate wifi, to get it going right. When i put sleep on myself, wifi works how it should. I have no problem with it, as i can get it to work again, but i thought i'll let you know. Kind regards. -- Have a nice day, Oddball. OS: Linux 3.7.0-rc6-1-desktop i686 Huidige gebruiker: oddball@EeePc-Rob-SFN9 Systeem: openSUSE 12.2 (i586) KDE: 4.9.3 "release 520" -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 4

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openSUSE Kernel November 2012