March 2013 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] kernel-default-base-2.6.29-5.2.x86_64 rpm errors
by Dave Plater 18 Jul '24

18 Jul '24

Hi, I'm busy updating to the latest factory kernel and have received the following errors from kernel-default-base installation (I did insert a blank dvd during the installation of the rpm by zypper):- WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sd_mod.ko needs unknown symbol crc_t10dif WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol register_cdrom WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_ioctl WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_media_changed WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_get_media_event WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_release WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_open WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol unregister_cdrom WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_number_of_slots And then these errors which I think IIRC happened before when the kernel was first split into three:- Kernel image: /boot/vmlinuz-2.6.29-rc8-5-default Initrd image: /boot/initrd-2.6.29-rc8-5-default Root device: /dev/disk/by-id/ata-WDC_WD800JB-00JJC0_WD-WMAM9RA78067-part3 (/dev/sda3) (mounted on / as xfs) Resume device: /dev/disk/by-id/ata-WDC_WD800JB-00JJC0_WD-WMAM9RA78067-part2 (/dev/sda2) FATAL: Module processor not found. WARNING: no dependencies for kernel module 'processor' found. FATAL: Module thermal not found. WARNING: no dependencies for kernel module 'thermal' found. FATAL: Module ata_generic not found. WARNING: no dependencies for kernel module 'ata_generic' found. FATAL: Module piix not found. WARNING: no dependencies for kernel module 'piix' found. FATAL: Module ide_pci_generic not found. WARNING: no dependencies for kernel module 'ide_pci_generic' found. FATAL: Module fan not found. WARNING: no dependencies for kernel module 'fan' found. FATAL: Module xfs not found. WARNING: no dependencies for kernel module 'xfs' found. FATAL: Module usbhid not found. WARNING: no dependencies for kernel module 'usbhid' found. Kernel Modules: scsi_mod libata ata_piix edd ahci sd_mod usbcore ohci-hcd ehci-hcd uhci-hcd WARNING: /dev/shm/mkinitramfs.0drQsZ/mnt/lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sd_mod.ko needs unknown symbol crc_t10dif Features: block usb resume.userspace resume.kernel Bootsplash: openSUSE (1280x1024) 22669 blocks Should I open a bug report about the errors which are possibly from inserting a dvd while the kernel rpm was installing? Regards Dave P -- 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] 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] CONFIG_SND_HDA_PREALLOC_SIZE too small
by Cristian Rodríguez 02 Apr '13

02 Apr '13

Hi: Is there a reason why CONFIG_SND_HDA_PREALLOC_SIZE is set to 1024 when the documentation says. "A larger buffer (e.g. 2048) is preferred for systems using PulseAudio. " .. plus all other distributions I have checked: fedora and arch 4096 mandriva 2048 gentoo 2048 is this an oversight or intended ? at least for kernel-desktop it looks like we want 4096 .. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

6 9

[opensuse-kernel] opensuse 12.3 xen-kernel happened i915 issue in Thinkpad x200
by Jun Hu 31 Mar '13

31 Mar '13

Hi Guys: I met a graphical video crad issue in my pc :Thinkpad x200 In the last months , I use Opensuse 12.2 userspace with kernel 3.7.3, desktop,default , xen flavors are ok. they can enter X window with i915 driver which kms supported. but now I upgrade to 12.3, I found kernel 3.7.10 desktop ,default kernel are ok ,with i915 kms supported. but kernel-xen-3.7.10 l boot ok and can't enter X window. when I add parameter "nomodeset" , can enter X window. wiredly , I use Opensuse 12.3 userspace with kernel-xen-3.7.3 ,when it boots to load i915 module , the screen shows black . of course if I add parameter "nomodeset", can enter X window. why do I need use xen-kernel in PC ? maybe you feel strange , because I want to study xen or kvm virtulization technology. I can't find any useful info in /var/log/messages. -- --------------------------- Suse Linux ,Best ! ---------------------------

1 0

[opensuse-kernel] UCB1400 support
by Jean Delvare 30 Mar '13

30 Mar '13

Hi all, Investigation reveals that the UCB1400 is only used on ARM OMAP machines: linux $ git grep '"ucb1400_core"' arch/arm/mach-pxa/balloon3.c: .name = "ucb1400_core", arch/arm/mach-pxa/cm-x2xx.c: .name = "ucb1400_core", arch/arm/mach-pxa/colibri-pxa270.c: .name = "ucb1400_core", arch/arm/mach-pxa/palmtc.c: .name = "ucb1400_core", arch/arm/mach-pxa/vpac270.c: .name = "ucb1400_core", drivers/mfd/ucb1400_core.c: .name = "ucb1400_core", This means that CONFIG_TOUCHSCREEN_UCB1400=m, CONFIG_GPIO_UCB1400=y and CONFIG_UCB1400_CORE=m are useless in non-ARM configuration files, and as I understand it, they could also be removed from armv5tel/versatile and armv7hl/exynos. I'm going to do that if there are no objections in the next few days. Also, investigation revealed that the gpio-ucb1400 driver is dead code at the moment, and given that it can't be built as a module, I would like to remove it not only in the Factory kernel but also in the 12.2, 12.3 and stable kernels (non-arm, at least.) If you disagree, speak up now. -- Jean Delvare Suse L3 -- 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] Increase Thinkpad fan speed
by Sankar P 29 Mar '13

29 Mar '13

Hi, I have a Thinkpad T400 where the machine overheats whenever I run openSUSE. The fan speed never increases even though the machine is too hot and shutsdown eventually. I googled and found http://www.thinkwiki.org/wiki/How_to_control_fan_speed Bu I could not get the thinkpad_acpi.conf file or the /proc/acpi/ibm/fan file. So what is the way to increase the fan speed in openSUSE ? -- Sankar P http://psankar.blogspot.com -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

4 4

[opensuse-kernel] kcmp --> Function not implemented
by Cristian Rodríguez 29 Mar '13

29 Mar '13

Hi: According to the manual the kcmp system call appeared in kernel 3.5 but SUSE kernels do not enable CONFIG_CHECKPOINT_RESTORE (kernel:head included) zgrep CHECKPOINT_RESTORE /proc/config.gz # CONFIG_CHECKPOINT_RESTORE is not set Is there a reason why it is disabled ? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 3

[opensuse-kernel] kernel head: usb totally broken
by Cristian Rodríguez 21 Mar '13

21 Mar '13

after installing this kernel whose latests changes are Thu Mar 21 2013 agraf(a)suse.de - SMDKV310: Fix compilation. - commit cf345eb * Thu Mar 21 2013 agraf(a)suse.de - ARM: FEC: Fix module compilation. - ARM: kvm: fix IOMMU dependency check. - omap3isp: fix miscompile. - VT8500: fix miscompile in clk driver. - config.conf: Remove imx51 and omap2plus, reenable arm - Update config files. - Delete config/armv7hl/imx51. - Delete config/armv7hl/omap2plus. - commit 7d60e2d I have one machine with USB totally non functional. Mar 21 17:30:53 xps9000.cristianrodriguez.net kernel: usb 2-3: device not accepting address 5, error -110 Mar 21 17:30:53 xps9000.cristianrodriguez.net kernel: hub 2-0:1.0: unable to enumerate USB device on port 3 Mar 21 17:30:53 xps9000.cristianrodriguez.net systemd-udevd[418]: worker [451] terminated by signal 9 (Killed) This repeats ad-nauseum with all usb ports, either in the usb 2 or usb 3 controller, I tried unplugging everything, rebooting etc.. no luck... -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 1

[opensuse-kernel] [PATCH] Axe MODULES_LOADED_ON_BOOT and migrate users to modules-load.d(5)
by Cristian Rodríguez 21 Mar '13

21 Mar '13

To support MODULES_LOADED_ON_BOOT systemd requires to carry a patch for yet another distribution specific hack. remove this variable and migrate all users to the distribution-agnostic modules-load.d(5) --- etc/sysconfig.kernel-mkinitrd | 10 ---------- mkinitrd.spec | 16 ++++++++++++++++ 2 files changed, 16 insertions(+), 10 deletions(-) diff --git a/etc/sysconfig.kernel-mkinitrd b/etc/sysconfig.kernel-mkinitrd index 89062a8..a958c2a 100644 --- a/etc/sysconfig.kernel-mkinitrd +++ b/etc/sysconfig.kernel-mkinitrd @@ -31,16 +31,6 @@ NO_KMS_IN_INITRD="no" # DOMU_INITRD_MODULES="xennet xenblk" -## Type: string -## ServiceRestart: boot.loadmodules -# -# This variable contains the list of modules to be loaded -# once the main filesystem is active -# You will find a few default modules for hardware which -# can not be detected automatically. -# -MODULES_LOADED_ON_BOOT="" - ## Type: string ## Default: "" # diff --git a/mkinitrd.spec b/mkinitrd.spec index cebf70e..916fc66 100644 --- a/mkinitrd.spec +++ b/mkinitrd.spec @@ -157,6 +157,22 @@ install -m 644 etc/purge-kernels.service $RPM_BUILD_ROOT/%{_unitdir}/ %service_add_post purge-kernels.service %endif + +if [ -f /etc/sysconfig/kernel ]; then + . /etc/sysconfig/kernel + if [ -n "$MODULES_LOADED_ON_BOOT" ]; then + for m in $MODULES_LOADED_ON_BOOT ; do + if [ ! -f "/etc/modules-load.d/$m.conf" ]; then + tmpf=$(mktemp) || exit 1 + echo $m > $tmpf + mv $tmpf /etc/modules-load.d/$m.conf + fi + done + fi +fi + +%{remove_and_set -n kernel MODULES_LOADED_ON_BOOT} + %postun %insserv_cleanup %if 0%{?suse_version} >= 1210 -- 1.8.1.4 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

4 8

[opensuse-kernel] let's go 3.8 :)
by Stephan Kulow 13 Mar '13

13 Mar '13

Hi, I changed the devel project of kernel-source back to Kernel:HEAD, so push it :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 1

[opensuse-kernel] Secure boot with self built kernel on openSUSE or SLES
by Thomas Renninger 12 Mar '13

12 Mar '13

Hi, I've seen the various module signing and other patches to make secure boot work. But I could not find some kind of quick guide how to sign a kernel and modules myself, install my own key or whatever is needed. If I have missed an already existing documentation, it would be great if someone can point me to it. Otherwise it would be nice to have a tiny thread explaining what tools are needed, etc.. Differences to SLES would be nice to know as well. Thanks, Thomas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 5

[opensuse-kernel] Patch to build VirtualBox kernel module with kernel 3.9
by Larry Finger 04 Mar '13

04 Mar '13

In kernel 3.9, one of the headers is no longer included by default, and must be added explicitly. The patch is Index: vboxhost/vboxdrv/r0drv/linux/thread2-r0drv-linux.c =================================================================== --- vboxhost.orig/vboxdrv/r0drv/linux/thread2-r0drv-linux.c +++ vboxhost/vboxdrv/r0drv/linux/thread2-r0drv-linux.c @@ -34,6 +34,7 @@ #include <iprt/assert.h> #include <iprt/thread.h> #include <iprt/err.h> +#include <linux/sched/rt.h> #include "internal/thread.h" Larry -- 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] Intel 82574L Gig E Adapter not recognized by kernel 3.8.0-29-desktop
by Bruce Ferrell 04 Mar '13

04 Mar '13

lsmod | grep e1000e e1000e 252782 0 ./netdriverinfo.sh : 01:00.0 Make/Model = Intel Corporation Gigabit CT Desktop Adapter Ethernet controller = Intel Corporation 82574L Gigabit Network Connection VenID:DevID = 8086:10d3 Driver name = No driver loaded Driver version = No driver loaded Modinfo e1000e as version: 2.1.4-k alias: pci:v00008086d000010D3sv*sd*bc*sc*i* And the Id string seems to be present This worked under 3.7.9 modprobe -r e1000e rr-iii:~ # dmesg [ 3993.357312] e1000e 0000:01:00.0: Disabling ASPM L0s L1 [ 3993.357507] e1000e 0000:01:00.0: irq 59 for MSI/MSI-X [ 3993.357512] e1000e 0000:01:00.0: irq 60 for MSI/MSI-X [ 3993.357519] e1000e 0000:01:00.0: irq 61 for MSI/MSI-X [ 3993.360114] e1000e 0000:01:00.0 eth1: MAC Wakeup cause - Link Status Change [ 3993.430154] device eth1 left promiscuous mode dmesg -C dmesg modprobe e1000e debug=10 rr-iii:~ # dmesg [ 4040.770118] e1000e: Intel(R) PRO/1000 Network Driver - 2.1.4-k [ 4040.770120] e1000e: Copyright(c) 1999 - 2012 Intel Corporation. [ 4040.770137] e1000e 0000:01:00.0: Disabling ASPM L0s L1 [ 4040.770236] e1000e 0000:01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [ 4040.770301] e1000e 0000:01:00.0: irq 59 for MSI/MSI-X [ 4040.770305] e1000e 0000:01:00.0: irq 60 for MSI/MSI-X [ 4040.770308] e1000e 0000:01:00.0: irq 61 for MSI/MSI-X [ 4040.867432] e1000e 0000:01:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 68:05:ca:12:90:dd [ 4040.867435] e1000e 0000:01:00.0 eth1: Intel(R) PRO/1000 Network Connection [ 4040.867446] e1000e 0000:01:00.0 eth1: MAC: 3, PHY: 8, PBA No: E46981-008 [ 4041.002738] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [ 4041.002741] device eth1 entered promiscuous mode modprobe -r e1000e rr-iii:~ # dmesg [ 4040.770118] e1000e: Intel(R) PRO/1000 Network Driver - 2.1.4-k [ 4040.770120] e1000e: Copyright(c) 1999 - 2012 Intel Corporation. [ 4040.770137] e1000e 0000:01:00.0: Disabling ASPM L0s L1 [ 4040.770236] e1000e 0000:01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [ 4040.770301] e1000e 0000:01:00.0: irq 59 for MSI/MSI-X [ 4040.770305] e1000e 0000:01:00.0: irq 60 for MSI/MSI-X [ 4040.770308] e1000e 0000:01:00.0: irq 61 for MSI/MSI-X [ 4040.867432] e1000e 0000:01:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 68:05:ca:12:90:dd [ 4040.867435] e1000e 0000:01:00.0 eth1: Intel(R) PRO/1000 Network Connection [ 4040.867446] e1000e 0000:01:00.0 eth1: MAC: 3, PHY: 8, PBA No: E46981-008 [ 4041.002738] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [ 4041.002741] device eth1 entered promiscuous mode [ 4067.818496] e1000e 0000:01:00.0: Disabling ASPM L0s L1 [ 4067.818693] e1000e 0000:01:00.0: irq 59 for MSI/MSI-X [ 4067.818697] e1000e 0000:01:00.0: irq 60 for MSI/MSI-X [ 4067.818700] e1000e 0000:01:00.0: irq 61 for MSI/MSI-X [ 4067.821318] e1000e 0000:01:00.0 eth1: MAC Wakeup cause - Link Status Change [ 4067.891790] device eth1 left promiscuous mode [ 4067.962423] vboxnetflt: dropped 0 out of 0 packets modprobe e1000e ethtool eth1 Settings for eth1: Cannot get device settings: No such device Cannot get wake-on-lan settings: No such device Cannot get message level: No such device Cannot get link status: No such device No data available -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 1

[opensuse-kernel] "SLAB: Unable to allocate memory" vs. vm.swappiness & vm/vfs_cache_pressure?
by chrysippus＠operamail.com 01 Mar '13

01 Mar '13

On a 4GB RAM edge server running 12.2 w/ kernel 3.4.28/x86_64 I'm seeing an increasing frequency of "SLAB: Unable to allocate memory on node 0" (http://pastebin.com/xDPgtut8) errors in syslog, e.g.: cat /var/log/messages ... Feb 28 09:24:30 core kernel: [777611.883853] The following is only an harmless informational message. Feb 28 09:24:30 core kernel: [777611.883860] Unless you get a _continuous_flood_ of these messages it means Feb 28 09:24:30 core kernel: [777611.883864] everything is working fine. Allocations from irqs cannot be Feb 28 09:24:30 core kernel: [777611.883868] perfectly reliable and the kernel is designed to handle that. Feb 28 09:24:30 core kernel: [777611.883873] swapper/2: page allocation failure. order:4, mode:0x20 Feb 28 09:24:30 core kernel: [777611.883880] Pid: 0, comm: swapper/2 Tainted: P W O 3.4.28-2.20-default #1 Feb 28 09:24:30 core kernel: [777611.883885] Call Trace: Feb 28 09:24:30 core kernel: [777611.883908] [<ffffffff81004598>] dump_trace+0x78/0x2c0 Feb 28 09:24:30 core kernel: [777611.883921] [<ffffffff81532e6a>] dump_stack+0x69/0x6f Feb 28 09:24:30 core kernel: [777611.883933] [<ffffffff810fdf02>] warn_alloc_failed+0x102/0x1b0 Feb 28 09:24:30 core kernel: [777611.883946] [<ffffffff81101cfb>] __alloc_pages_nodemask+0x68b/0x9a0 Feb 28 09:24:30 core kernel: [777611.883959] [<ffffffff811401e2>] kmem_getpages+0x62/0x190 Feb 28 09:24:30 core kernel: [777611.883969] [<ffffffff81140ddf>] fallback_alloc+0x21f/0x270 Feb 28 09:24:30 core kernel: [777611.883981] [<ffffffff8114153b>] __kmalloc+0x14b/0x1d0 Feb 28 09:24:30 core kernel: [777611.883994] [<ffffffff8143e87c>] pskb_expand_head+0x8c/0x310 Feb 28 09:24:30 core kernel: [777611.884006] [<ffffffff814d9355>] ip6_forward+0x515/0x770 Feb 28 09:24:30 core kernel: [777611.884027] [<ffffffff81449712>] __netif_receive_skb+0x532/0x600 Feb 28 09:24:30 core kernel: [777611.884039] [<ffffffff81449881>] process_backlog+0xa1/0x180 Feb 28 09:24:30 core kernel: [777611.884049] [<ffffffff8144a280>] net_rx_action+0x140/0x230 Feb 28 09:24:30 core kernel: [777611.884062] [<ffffffff810459be>] __do_softirq+0xae/0x1c0 Feb 28 09:24:30 core kernel: [777611.884073] [<ffffffff8154724c>] call_softirq+0x1c/0x30 Feb 28 09:24:30 core kernel: [777611.884082] [<ffffffff810044e5>] do_softirq+0x75/0xb0 Feb 28 09:24:30 core kernel: [777611.884094] [<ffffffff81045d55>] irq_exit+0xa5/0xb0 Feb 28 09:24:30 core kernel: [777611.884105] [<ffffffff8100413b>] do_IRQ+0x5b/0xd0 Feb 28 09:24:30 core kernel: [777611.884115] [<ffffffff8153e5ea>] common_interrupt+0x6a/0x6a Feb 28 09:24:30 core kernel: [777611.884129] [<ffffffff8131861c>] intel_idle+0xec/0x160 Feb 28 09:24:30 core kernel: [777611.884141] [<ffffffff81412bfd>] cpuidle_idle_call+0x9d/0x240 Feb 28 09:24:30 core kernel: [777611.884152] [<ffffffff8100b5f5>] cpu_idle+0x65/0xd0 Feb 28 09:24:30 core kernel: [777611.884163] [<ffffffff8152be3d>] start_secondary+0x208/0x20d Feb 28 09:24:30 core kernel: [777611.884171] SLAB: Unable to allocate memory on node 0 (gfp=0x20) Feb 28 09:24:30 core kernel: [777611.884176] cache: size-65536, object size: 65536, order: 4 Feb 28 09:24:30 core kernel: [777611.884184] node 0: slabs: 19/19, objs: 19/19, free: 0 Feb 28 09:24:30 core kernel: [777611.886007] The following is only an harmless informational message. Feb 28 09:24:30 core kernel: [777611.886015] Unless you get a _continuous_flood_ of these messages it means Feb 28 09:24:30 core kernel: [777611.886018] everything is working fine. Allocations from irqs cannot be Feb 28 09:24:30 core kernel: [777611.886022] perfectly reliable and the kernel is designed to handle that. Feb 28 09:24:30 core kernel: [777611.886027] kswapd0: page allocation failure. order:4, mode:0x20 Feb 28 09:24:30 core kernel: [777611.886034] Pid: 35, comm: kswapd0 Tainted: P W O 3.4.28-2.20-default #1 Feb 28 09:24:30 core kernel: [777611.886038] Call Trace: Feb 28 09:24:30 core kernel: [777611.886061] [<ffffffff81004598>] dump_trace+0x78/0x2c0 Feb 28 09:24:30 core kernel: [777611.886073] [<ffffffff81532e6a>] dump_stack+0x69/0x6f Feb 28 09:24:30 core kernel: [777611.886085] [<ffffffff810fdf02>] warn_alloc_failed+0x102/0x1b0 Feb 28 09:24:30 core kernel: [777611.886097] [<ffffffff81101cfb>] __alloc_pages_nodemask+0x68b/0x9a0 Feb 28 09:24:30 core kernel: [777611.886110] [<ffffffff811401e2>] kmem_getpages+0x62/0x190 Feb 28 09:24:30 core kernel: [777611.886120] [<ffffffff81140ddf>] fallback_alloc+0x21f/0x270 Feb 28 09:24:30 core kernel: [777611.886132] [<ffffffff8114153b>] __kmalloc+0x14b/0x1d0 Feb 28 09:24:30 core kernel: [777611.886145] [<ffffffff8143e87c>] pskb_expand_head+0x8c/0x310 Feb 28 09:24:30 core kernel: [777611.886157] [<ffffffff814d9355>] ip6_forward+0x515/0x770 Feb 28 09:24:30 core kernel: [777611.886178] [<ffffffff81449712>] __netif_receive_skb+0x532/0x600 Feb 28 09:24:30 core kernel: [777611.886194] [<ffffffff81449881>] process_backlog+0xa1/0x180 Feb 28 09:24:30 core kernel: [777611.886210] [<ffffffff8144a280>] net_rx_action+0x140/0x230 Feb 28 09:24:30 core kernel: [777611.886229] [<ffffffff810459be>] __do_softirq+0xae/0x1c0 Feb 28 09:24:30 core kernel: [777611.886245] [<ffffffff8154724c>] call_softirq+0x1c/0x30 Feb 28 09:24:30 core kernel: [777611.886259] [<ffffffff810044e5>] do_softirq+0x75/0xb0 Feb 28 09:24:30 core kernel: [777611.886276] [<ffffffff81045d55>] irq_exit+0xa5/0xb0 Feb 28 09:24:30 core kernel: [777611.886291] [<ffffffff8100413b>] do_IRQ+0x5b/0xd0 Feb 28 09:24:30 core kernel: [777611.886304] [<ffffffff8153e5ea>] common_interrupt+0x6a/0x6a Feb 28 09:24:30 core kernel: [777611.886319] [<ffffffff8153e1d9>] _raw_spin_unlock_irqrestore+0x9/0x30 Feb 28 09:24:30 core kernel: [777611.886329] [<ffffffff8111a1b8>] compaction_alloc+0x288/0x2b0 Feb 28 09:24:30 core kernel: [777611.886342] [<ffffffff81144d83>] migrate_pages+0xb3/0x500 Feb 28 09:24:30 core kernel: [777611.886352] [<ffffffff8111ad47>] compact_zone+0x1d7/0x320 Feb 28 09:24:30 core kernel: [777611.886364] [<ffffffff8111af3b>] __compact_pgdat+0xab/0x170 Feb 28 09:24:30 core kernel: [777611.886374] [<ffffffff8111b237>] compact_pgdat+0x27/0x30 Feb 28 09:24:30 core kernel: [777611.886384] [<ffffffff8110dc8c>] balance_pgdat+0x6cc/0x710 Feb 28 09:24:30 core kernel: [777611.886396] [<ffffffff8110de18>] kswapd+0x148/0x370 Feb 28 09:24:30 core kernel: [777611.886407] [<ffffffff8105ec55>] kthread+0x85/0x90 Feb 28 09:24:30 core kernel: [777611.886417] [<ffffffff81547154>] kernel_thread_helper+0x4/0x10 Feb 28 09:24:30 core kernel: [777611.886426] SLAB: Unable to allocate memory on node 0 (gfp=0x20) Feb 28 09:24:30 core kernel: [777611.886430] cache: size-65536, object size: 65536, order: 4 Feb 28 09:24:30 core kernel: [777611.886439] node 0: slabs: 15/19, objs: 15/19, free: 4 Feb 28 09:24:38 core kernel: [777620.441021] The following is only an harmless informational message. Feb 28 09:24:38 core kernel: [777620.441029] Unless you get a _continuous_flood_ of these messages it means Feb 28 09:24:38 core kernel: [777620.441033] everything is working fine. Allocations from irqs cannot be Feb 28 09:24:38 core kernel: [777620.441036] perfectly reliable and the kernel is designed to handle that. Feb 28 09:24:38 core kernel: [777620.441042] swapper/1: page allocation failure. order:4, mode:0x20 Feb 28 09:24:38 core kernel: [777620.441048] Pid: 0, comm: swapper/1 Tainted: P W O 3.4.28-2.20-default #1 Feb 28 09:24:38 core kernel: [777620.441053] Call Trace: Feb 28 09:24:38 core kernel: [777620.441076] [<ffffffff81004598>] dump_trace+0x78/0x2c0 Feb 28 09:24:38 core kernel: [777620.441089] [<ffffffff81532e6a>] dump_stack+0x69/0x6f ... Atm, `slabtop` shows 99% usage for "ext4_inode_cache": slabtop Active / Total Objects (% used) : 1275578 / 1419483 (89.9%) Active / Total Slabs (% used) : 187764 / 187786 (100.0%) Active / Total Caches (% used) : 109 / 232 (47.0%) Active / Total Size (% used) : 639586.50K / 660294.86K (96.9%) Minimum / Average / Maximum Object : 0.02K / 0.46K / 4096.00K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 606252 601064 99% 0.85K 151563 4 606252K ext4_inode_cache 380397 283799 74% 0.10K 10281 37 41124K buffer_head 241600 231794 95% 0.19K 12080 20 48320K dentry 34986 34973 99% 0.54K 4998 7 19992K inode_cache 27435 12674 46% 0.06K 465 59 1860K size-64 21952 21115 96% 0.03K 196 112 784K size-32 18734 18690 99% 0.11K 551 34 2204K sysfs_dir_cache 16086 14359 89% 0.55K 2298 7 9192K radix_tree_node 13475 11758 87% 0.05K 175 77 700K jbd2_inode ... This is with default values of: cat /proc/sys/vm/vfs_cache_pressure 100 cat /proc/sys/vm/swappiness 60 Reading @ http://doc.opensuse.org/documentation/html/openSUSE/opensuse-tuning/cha.tun…, and taking a random stab at changing echo 200 > /proc/sys/vm/vfs_cache_pressure echo 25 > /proc/sys/vm/swappiness Seems to reduce -- thought not completely eliminate -- the syslog errors. `slabtop` shows no change. After dropping cache sync && echo 3 > /proc/sys/vm/drop_caches `slabtop` usage for "ext4-inode_cache" seems to have dropped to 74%, although other items are still ~99%: slabtop Active / Total Objects (% used) : 130790 / 216154 (60.5%) Active / Total Slabs (% used) : 12482 / 12506 (99.8%) Active / Total Caches (% used) : 109 / 232 (47.0%) Active / Total Size (% used) : 40954.73K / 54620.83K (75.0%) Minimum / Average / Maximum Object : 0.02K / 0.25K / 4096.00K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 60740 22518 37% 0.19K 3037 20 12148K dentry 23423 8006 34% 0.06K 397 59 1588K size-64 !! 21952 21119 96% 0.03K 196 112 784K size-32 !! 19397 19126 98% 0.54K 2771 7 11084K inode_cache !! 18734 18690 99% 0.11K 551 34 2204K sysfs_dir_cache 16687 4514 27% 0.10K 451 37 1804K buffer_head 4543 2173 47% 0.05K 59 77 236K anon_vma_chain 4200 3013 71% 0.12K 140 30 560K size-128 !! 4088 4072 99% 0.13K 146 28 584K ext4_groupinfo_4k !! 4084 4079 99% 1.00K 1021 4 4084K size-1024 3784 2956 78% 0.17K 172 22 688K vm_area_struct 3283 962 29% 0.55K 469 7 1876K radix_tree_node 2596 1484 57% 0.06K 44 59 176K anon_vma 2160 1798 83% 0.02K 15 144 60K dm_target_io 2116 1820 86% 0.04K 23 92 92K dm_io 2020 1687 83% 0.19K 101 20 404K size-192 1925 45 2% 0.05K 25 77 100K jbd2_inode 1845 1108 60% 0.25K 123 15 492K filp 1431 1344 93% 0.07K 27 53 108K Acpi-Operand --> 1408 1042 74% 0.85K 352 4 1408K ext4_inode_cache ... With this config, post clear, for ~ 20 minutes, no more SLAB errors in syslog. My understanding of the effect/beahvior of Memory Subsytem tuning is rudimentary at best. Chatting in #opensuse-server, IIUC, it seems that it's not leaking, but not automatically freeing up enough memory. (1) Are the SLAB errors I'm seeing indicative of a problem in the sysctl setting for swappiness & vfs_cache_pressure, particularly for server use? Or something else? (2) What, if any, specific/initial guidance or recommendation exists for these values for Opensuse server, not desktop, usage? Thanks. /C -- 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] expanded repository rewritten
by Michal Marek 01 Mar '13

01 Mar '13

Hi, tl;dr: I had to rewrite the history of some branches of the expanded tree (http://kernel.opensuse.org/cgit/kernel/) to fix some bugs. Please do git checkout HEAD^0 git fetch -f origin 'refs/heads/*:refs/heads/*' 'refs/tags/*:refs/tags/*' to update your clone. Long version: I tried to optimize the script that converts a given kernel-source commit into an expanded version, to expedite processing of a large SLE11-SP3 backport two weeks ago. I unfortunately made a mistake and the script did not detect the mainline version of the patched tree properly, resulting in a merge with the base kernel version (e.g. 3.0) instead of the current version (e.g. 3.0.58). Although I fixed the bug before it hit master or openSUSE-*, I decided to use this opportunity to fix some bugs in the openSUSE branches as well. The list of fixes is as follows: * The optimisation was basically an equivalent of Jeff's --fast option to sequence-patch.sh. Unfortunately, this failed with malformed patches that contain one less line of context at the very end. I fixed the script to retry in the one patch at a time mode if a series fails. * A series of SLE11-SP3 commits (f2dc7ee..4b3b361) deleted and later restored series.conf due to a bug in scripts/log, which resulted in two giant commits changing the expanded SLE11-SP3 branch to vanilla and back. In the new branch, the series is instead marked as broken. * Version updates were not detected, if the commit updating the version or the preceding commit could not be applied. To not change the entire history of the SLE branches, I only fixed this in the openSUSE branches (inc. master) and the very recent history of the SLE branches. * The openSUSE branches included commits from the 'packaging' branch, which is a branch without any code, so it resulted in broken commits. In the new history, the packaging branch is excluded. The changed braches are as follows: * SLE11-SP3: History changes after 69c726c from last November * SLE11-SP2: Changed after d860544 from January 18 * SLES10_SP4_BRANCH: Only last ten days of history changed, due to the bug with wrongly computed upstream version. * master, stable, openSUSE-12.{1,2,3}: History changed about three years back, mainly due to missed version updates. I decided to err on the side of correctness in the openSUSE branches, as long as the commits were not shared with any SLE branch. * rpm-* tags changed if the respective commit changed. Sorry for the inconvenience, Michal -- 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] kernel downgraded in 12.3 RC2?
by Andrey Borzenkov 01 Mar '13

01 Mar '13

Kernel before 12.3 RC2 was 3.7.9-1.4.1 and in RC2 it is 3.7.9-1.1.2. Was it really downgraded? It is causing a bit of confusion between testers. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 1