March 2016 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] kernel/initrd loading delays
by Felix Miata 03 Apr '16

03 Apr '16

Felix Miata composed on 2015-10-12 12:29 (UTC-0400): (originally to initramfs(a)vger.kernel.org) https://www.mail-archive.com/initramfs@vger.kernel.org/msg04168.html > On more and more installations since most distros have replaced mkinitrd with > dracut, on selecting a bootloader menu choice the "root > (hd0,...filesystemtype..[Linux-bzImage, setup, ... initrd /boot/initrd" > message stays on screen 40 seconds or more before the time-stamped boot > messages begin scrolling the screen. IIRC, these delays first began appearing > last January or February, and appear on multiple machines. All kernel and > initrd images are on smallish EXT3 or EXT4 (mostly the latter) filesystems > using 1024 blocksize on BIOS logical partitions on rotating rust (IIRC, all > with native 512b sector size, manufactured in 2011 or earlier). All > installations are configured with static IP. All have Plymouth either not > installed, or are booted with noplymouth included on kernel cmdline. > e.g, on my fastest system, host msi85, a 3.0 GHz dual core Haswell, total > time from boot stanza select on BIOS host msi85 to Rawhide 4.3.0-0.rc3.git4.1 > (dracut initramfs.img 11,326,223) multi-user.target shell prompt ready is > about 80 seconds following that 40 second delay, with last time stamp showing > 36.844484. > Same msi85 system booting LMDE 2 3.16.0-4 (non-dracut? initrd.img 27,362,964; > initramfs-tools 0.120) delays start of boot messages nearly 80 seconds, > reaching DM greeter ready nearly 140 seconds after stanza selection. > Same system booting openSUSE Leap 42.1 4.1.8 (dracut initrd 8,082,360) > exhibits no perceptible delay, reaching multi-user.target shell prompt in > under 47 seconds from boot stanza selection. > Same system booting openSUSE 13.2 3.16.7 (dracut initrd 5,351,996) delays > start of boot messages about 40 seconds, reaching multi-user.target bash > prompt about 90 seconds after stanza selection. > Same system booting Mageia 5 4.1.8 (dracut initrd.img 9,391,664) exhibits no > delay, reaching multi-user.target bash prompt in about 45 seconds. > Same system booting Wheezy 3.2.0 (non-dracut initrd.img 10,537,321) exhibits > no delay, reaching DM greeter in less than about 45 seconds. > Same system booting openSUSE 13.1 3.12.44 (non-dracut initrd 7,679,390) > exhibits no delay, reaching multi-user.target bash prompt in less than 45 > seconds. > Same system booting Fedora 23 4.2.2 (dracut initramfs.img 11,255,214) reaches > multi-user.target shell prompt in about 75 seconds after unknown > kernel/initrd delay (puts display into sleep mode until boot messages appear). > Same system booting openSUSE Tumbleweed 4.2.1 (dracut initrd 8,970,760) > exhibits no delay, reaching multi-user.target bash prompt in less than 45 > seconds. > Same system booting (second, on sda28, vs. other on sda23) openSUSE > Tumbleweed 4.2.1 (dracut initrd 8,965,124) exhibits ~40 second delay, > reaching multi-user.target bash prompt in about 100 seconds. > Same system booting Kubuntu 14.10 3.16.0 (non-dracut initrd 20,550,608) > exhibits no initial (linux/initrd) delay, reaching KDM greeter in about 90 > seconds. > Same system booting Fedora 22 4.1.8 (dracut initrd 10,788,392) exhibits no > delay, reaching multi-user.target bash prompt in less than 50 seconds. > Any ideas what could cause these delays, or how to eliminate them? Booting host hpg33 openSUSE Tumbleweed 20160307 64 bit kernel-default-4.4.3, 6194336 bytes, and initrd 38456340 bytes, just took 9.4 minutes for the last Grub message to clear, and extended that to ~10.2 minutes to reach a shell prompt. Prior 4.3.3-5 kernel-default's initrd is 9589212 bytes, 25% the size of the current. 4.3.3-5 took 2 2/3 minutes for the Grub message to clear, about 2/3 more minute to reach shell prompt, and 4.3.3-1 about the same. 3rd prior, kernel-desktop-4.2.1 cleared the Grub message in too few seconds to count, well under a minute to reach shell prompt. kernel-default-4.5.0 cleared the Grub in 130 seconds, reached shell prompt at 174, has 8664600 byte initrd, smallest since 4.1.6's 8663972. Mount reported /dev/mapper/* names with 4.4.3 and 4.5.0, while 4.2.1 and 4.3.3 reported device names. What's taking so long booting with kernel-default? P.S. Are long-winded /dev/mapper/* mount reports a new normal? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

6 13

[opensuse-kernel] Next openSUSE Leap 42.1 kernel update
by Takashi Iwai 21 Mar '16

21 Mar '16

Hi, I'm going to submit the next kernel update for openSUSE Leap 42.1 in this week. As of now, it's based on 4.1.20 stable kernel. If anyone is willing to test, please check the kernel packages in OBS Kernel:openSUSE-42.1 repo, and report back if any regression is seen. thanks, Takashi -- 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] TW - zypper ve loops due to kernel-desktop/kernel-default
by Felix Miata 18 Mar '16

18 Mar '16

No way to get past kernels to verify anything else. Skip works once for each kernel, then asks again about each a second time, then a third, yada yada. Both -default and -desktop are present because via zypper locks I don't allow old kernel removal until I decide they have no more use, and so use rpm --nodeps to install new ones. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- 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 Warning and Call Trace with i915 driver and 3.12.53-40.1 update kernel
by Martin Konold 17 Mar '16

17 Mar '16

Hi, when upgrading to the most recent kernel from http://ftp5.gwdg.de/pub/ opensuse/update/13.1/src/kernel-source-3.12.53-40.1.src.rpm and http:// ftp5.gwdg.de/pub/opensuse/update/13.1/nosrc/kernel-desktop-3.12.53-40.1.nosrc.rpm on OpenSUSE 13.1 I observe the following warning from i915 driver: Mär 16 09:35:12 rt-ccs7520 kernel: ------------[ cut here ]------------ Mär 16 09:35:12 rt-ccs7520 kernel: WARNING: CPU: 0 PID: 90 at ../drivers/gpu/ drm/i915/intel_panel.c:632 i9xx_enable_backlight+0xdc/0x100 [i915]() Mär 16 09:35:12 rt-ccs7520 kernel: backlight already enabled Mär 16 09:35:12 rt-ccs7520 kernel: Modules linked in: i2c_i801(+) lpc_ich(+) ata_piix(+) mfd_core tg3 libphy ptp i915(+) pps_core drm_kms_helper drm i2c_algo_bit shpchp button video processor thermal_sys Mär 16 09:35:12 rt-ccs7520 kernel: CPU: 0 PID: 90 Comm: udevd Not tainted 3.12.53-40.2-ccs #1 Mär 16 09:35:12 rt-ccs7520 kernel: Hardware name: National Instruments NI PXI-8190 Series Embedded Controller /NI PXI-8190 Series Embedded Controller , BIOS 1.3.2 03/24/2011 Mär 16 09:35:12 rt-ccs7520 kernel: f7d25318 c074fb28 00000000 c0247088 f7d2c021 f6cab85c 0000005a f7d25318 Mär 16 09:35:12 rt-ccs7520 kernel: 00000278 f7cf545c f7cf545c f6d08000 f6d5c000 f6d02000 00000292 c02470f3 Mär 16 09:35:12 rt-ccs7520 kernel: 00000009 f6cab844 f7d2c021 f6cab85c f7cf545c f7d25318 00000278 f7d2c021 Mär 16 09:35:12 rt-ccs7520 kernel: Call Trace: Mär 16 09:35:12 rt-ccs7520 kernel: [<c0205209>] try_stack_unwind+0x179/0x190 Mär 16 09:35:12 rt-ccs7520 kernel: [<c02041d7>] dump_trace+0x47/0xf0 Mär 16 09:35:12 rt-ccs7520 kernel: [<c020525f>] show_trace_log_lvl+0x3f/0x50 Mär 16 09:35:12 rt-ccs7520 kernel: [<c02042d0>] show_stack_log_lvl+0x50/0xd0 Mär 16 09:35:12 rt-ccs7520 kernel: [<c02052af>] show_stack+0x1f/0x40 Mär 16 09:35:12 rt-ccs7520 kernel: [<c074fb28>] dump_stack+0x48/0x76 Mär 16 09:35:12 rt-ccs7520 kernel: [<c0247088>] warn_slowpath_common +0x88/0xc0 Mär 16 09:35:12 rt-ccs7520 kernel: [<c02470f3>] warn_slowpath_fmt+0x33/0x40 Mär 16 09:35:12 rt-ccs7520 kernel: [<f7cf545c>] i9xx_enable_backlight+0xdc/ 0x100 [i915] Mär 16 09:35:12 rt-ccs7520 kernel: [<f7cf655c>] intel_panel_enable_backlight +0x9c/0xe0 [i915] Mär 16 09:35:12 rt-ccs7520 kernel: [<f7cd4440>] i9xx_crtc_enable+0x260/0x2f0 [i915] Mär 16 09:35:12 rt-ccs7520 kernel: [<f7cda8bc>] __intel_set_mode+0x77c/0x8d0 [i915] Mär 16 09:35:12 rt-ccs7520 kernel: [<f7cdd7bd>] intel_set_mode+0x1d/0x40 [i915] Mär 16 09:35:12 rt-ccs7520 kernel: [<f7cde04f>] intel_crtc_set_config+0x77f/ 0x960 [i915] Mär 16 09:35:12 rt-ccs7520 kernel: [<f7b40263>] drm_mode_set_config_internal +0x43/0xb0 [drm] Mär 16 09:35:12 rt-ccs7520 kernel: [<f7b1a2f5>] drm_fb_helper_set_par +0x45/0xb0 [drm_kms_helper] Mär 16 09:35:12 rt-ccs7520 kernel: [<c04f8eb2>] fbcon_init+0x482/0x4d0 Mär 16 09:35:12 rt-ccs7520 kernel: [<c055e1e6>] visual_init+0x96/0xf0 Mär 16 09:35:12 rt-ccs7520 kernel: [<c0560634>] do_bind_con_driver +0x104/0x2d0 Mär 16 09:35:12 rt-ccs7520 kernel: [<c0560cd6>] do_take_over_console +0xf6/0x190 Mär 16 09:35:12 rt-ccs7520 kernel: [<c04f4777>] do_fbcon_takeover+0x57/0xc0 Mär 16 09:35:12 rt-ccs7520 kernel: [<c0759346>] notifier_call_chain+0x46/0x60 Mär 16 09:35:12 rt-ccs7520 kernel: [<c0269897>] __blocking_notifier_call_chain +0x37/0x50 Mär 16 09:35:12 rt-ccs7520 kernel: [<c02698c7>] blocking_notifier_call_chain +0x17/0x20 Mär 16 09:35:12 rt-ccs7520 kernel: [<c04ec78b>] register_framebuffer+0x1bb/ 0x2d0 Mär 16 09:35:12 rt-ccs7520 kernel: [<f7b1a005>] drm_fb_helper_initial_config +0x2e5/0x490 [drm_kms_helper] Mär 16 09:35:12 rt-ccs7520 kernel: [<f7caae99>] i915_driver_load+0xfb9/0xfe0 [i915] Mär 16 09:35:12 rt-ccs7520 kernel: [<f7b3cbc3>] drm_get_pci_dev+0x103/0x2a0 [drm] Mär 16 09:35:12 rt-ccs7520 kernel: [<c04d02b5>] local_pci_probe+0x25/0x50 Mär 16 09:35:12 rt-ccs7520 kernel: [<c04d137f>] pci_device_probe+0xcf/0xe0 Mär 16 09:35:12 rt-ccs7520 kernel: [<c05862ee>] driver_probe_device+0x7e/ 0x3a0 Mär 16 09:35:12 rt-ccs7520 kernel: [<c05866b1>] __driver_attach+0x71/0x80 Mär 16 09:35:12 rt-ccs7520 kernel: [<c05847ef>] bus_for_each_dev+0x3f/0x70 Mär 16 09:35:12 rt-ccs7520 kernel: [<c0585e06>] driver_attach+0x16/0x20 Mär 16 09:35:12 rt-ccs7520 kernel: [<c0585a1f>] bus_add_driver+0x1cf/0x2b0 Mär 16 09:35:12 rt-ccs7520 kernel: [<c0586bf1>] driver_register+0x51/0xd0 Mär 16 09:35:12 rt-ccs7520 kernel: [<c020042a>] do_one_initcall+0xca/0x190 Mär 16 09:35:12 rt-ccs7520 kernel: [<c02b219b>] load_module+0x1d5b/0x2460 Mär 16 09:35:12 rt-ccs7520 kernel: [<c02b2a05>] SyS_finit_module+0x75/0xc0 Mär 16 09:35:12 rt-ccs7520 kernel: [<c075c37d>] sysenter_do_call+0x12/0x12 Mär 16 09:35:12 rt-ccs7520 kernel: [<b76fa428>] 0xb76fa427 Mär 16 09:35:12 rt-ccs7520 kernel: ---[ end trace 84f8674cd360f232 ]--- Mär 16 09:35:12 rt-ccs7520 kernel: Console: switching to colour frame buffer device 128x48 Mär 16 09:35:12 rt-ccs7520 kernel: i915 0000:00:02.0: fb0: inteldrmfb frame buffer device Mär 16 09:35:12 rt-ccs7520 kernel: i915 0000:00:02.0: registered panic notifier Mär 16 09:35:12 rt-ccs7520 kernel: [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 This issue got newly introduced and is not present in previous openSUSE kernels. # lspci -d 8086:2592 -v 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation Device 1999 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at a0080000 (32-bit, non-prefetchable) [size=512K] I/O ports at 1800 [size=8] Memory at c0000000 (32-bit, prefetchable) [size=256M] Memory at a0000000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at <unassigned> [disabled] Capabilities: [d0] Power Management version 2 Kernel driver in use: i915 Kernel modules: i915 # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 2.00GHz stepping : 8 microcode : 0x20 cpu MHz : 2000.000 cache size : 2048 KB fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx bts est tm2 bogomips : 3990.16 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management: This is an embedded system running a venerable mobile CPU with only a single external VGA. Regards --martin konold -- Dipl.-Physiker Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Registergericht: Amtsgericht Stuttgart PR 126 Firmensitz: Adolfstraße 23, 70469 Stuttgart fon: 0711 67400963 fax: 0711 67400959 email: martin.konold(a)erfrakon.de http://www.erfrakon.de -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

4 5

[opensuse-kernel] Re: [opensuse-factory] openSUSE Tumbleweed - Status information
by Dominique Leuenberger / DimStar 16 Mar '16

16 Mar '16

Hi Bo, and everybody else interested, On Wed, 2016-03-16 at 10:44 +0100, Bo Simonsen wrote: > The latest snapshot, 20160308, has been fully built by OBS and > > tested > > by openQA. It has not been released to the users, due to an > > identified > > issue: > > > > ! ! ! i586 systems fail to boot ! ! ! > Is there any news on this issue? > Progress is slow, much slower than we all wish. What happened so far is that various scenarios could be tested with more or less success. One of the main binutils maintainers took on the case as well and last night I have seen a patch uploaded to the kernel bug tracker. So our next steps will be to validate the patch and convince our kernel team to add this to our package - then we might be fortunate to get Tumbleweed rolling soon again. So, all in all: no change in the situation in Tumbleweed directly, but clearly work in the right direction is done and possible solutions are being found. Cheers, Dominique For reference, the relevant bug reports: https://bugzilla.opensuse.org/show_bug.cgi?id=970239 https://sourceware.org/bugzilla/show_bug.cgi?id=19807 https://bugzilla.kernel.org/show_bug.cgi?id=114671 -- 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] A new approach to verify changes in the Linux kernel ABI
by Ponomarenko Andrey 14 Mar '16

14 Mar '16

Hello, I've released new versions of the abi-compliance-checker and abi-dumper tools that are now able to easily verify compatibility of changes in the Linux kernel ABI: https://github.com/lvc/ 1. The kernel should be compiled with CONFIG_DEBUG_INFO=y and CONFIG_DEBUG_INFO_REDUCED=n additional options. 2. Create ABI dump for vmlinux: abi-dumper vmlinux -vnum 4.4.5 -kernel-export -o ABI.dump 3. Compare ABI dumps to produce report: abi-compliance-checker -l kernel -bin -old ABI-0.dump -new ABI-1.dump The new -kernel-export option of the abi-dumper is introduced to dump only public exported symbols of the kernel, i.e. declared in the ksymtab/ksymtab_gpl binary sections + system calls. I've applied this approach on the recent releases of the Linux kernel (2.6.36-4.4.5) as an example and prepared the compatibility table here: http://abi-laboratory.pro/tracker/timeline/linux/ The distribution specific changes in the kernel can be verified in the same way to prevent/minimize ABI differences with upstream or between sequential releases. Thank you. -- 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:openSUSE-42.1' 4.1.19-1.1.gba8f37b: xfs problems & kernel panic
by Dmitriy Perlow 14 Mar '16

14 Mar '16

3 5

[opensuse-kernel] [PATCH 1/5] tty: Move serial8250_stop_rx() in front of serial8250_start_tx()
by matwey.kornilov＠gmail.com 08 Mar '16

08 Mar '16

From: "Matwey V. Kornilov" <matwey(a)sai.msu.ru> Software RS485 emultaion is to be added in the following commit. serial8250_start_tx() will need to refer serial8250_stop_rx(). Move serial8250_stop_rx() in front of serial8250_start_tx() in order to avoid function forward declaration. Signed-off-by: Matwey V. Kornilov <matwey(a)sai.msu.ru> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Patch-mainline: Queued in linux-next for 4.6-rc1 Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Git-commit: a07a70bcb72e4a766c8d3173986a773cef842d30 Signed-off-by: Matwey V. Kornilov <matwey.kornilov(a)gmail.com> --- This patch series is for master (4.5). Since we switched from omap_serial to 8250_omap module, currently we lack TIOCSRS485/TIOCGRS485 ioctls in userspace. This ioctls were here before the switch and supported only by omap_serial. In order to provide this missed functionality for 8250_omap the following patches have been implemented and accepted in linux-next (4.6). It would be great, if openSUSE users could use this functionality. drivers/tty/serial/8250/8250_port.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 0bd3c6b..04681e5 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -1304,6 +1304,19 @@ static void autoconfig_irq(struct uart_8250_port *up) port->irq = (irq > 0) ? irq : 0; } +static void serial8250_stop_rx(struct uart_port *port) +{ + struct uart_8250_port *up = up_to_u8250p(port); + + serial8250_rpm_get(up); + + up->ier &= ~(UART_IER_RLSI | UART_IER_RDI); + up->port.read_status_mask &= ~UART_LSR_DR; + serial_port_out(port, UART_IER, up->ier); + + serial8250_rpm_put(up); +} + static inline void __stop_tx(struct uart_8250_port *p) { if (p->ier & UART_IER_THRI) { @@ -1371,19 +1384,6 @@ static void serial8250_unthrottle(struct uart_port *port) port->unthrottle(port); } -static void serial8250_stop_rx(struct uart_port *port) -{ - struct uart_8250_port *up = up_to_u8250p(port); - - serial8250_rpm_get(up); - - up->ier &= ~(UART_IER_RLSI | UART_IER_RDI); - up->port.read_status_mask &= ~UART_LSR_DR; - serial_port_out(port, UART_IER, up->ier); - - serial8250_rpm_put(up); -} - static void serial8250_disable_ms(struct uart_port *port) { struct uart_8250_port *up = -- cgit v0.12 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 4

[opensuse-kernel] [PATCH] config: arm: enable CONFIG_DRM_ETNAVIV
by Guillaume GARDET 02 Mar '16

02 Mar '16

Enable CONFIG_DRM_ETNAVIV for armv7 (default and vanilla) to get graphics acceleration on top of the Vivante GPU IP cores used in different SoCs, such as the Freescale i.MX6. Signed-off-by: Guillaume GARDET <guillaume.gardet(a)free.fr> Cc: Andreas Färber <afaerber(a)suse.de> --- config/armv7hl/default | 3 ++- config/armv7hl/vanilla | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/config/armv7hl/default b/config/armv7hl/default index 901f41d..9ce9bfc 100644 --- a/config/armv7hl/default +++ b/config/armv7hl/default @@ -5389,7 +5389,8 @@ CONFIG_DRM_IMX_LDB=m CONFIG_DRM_IMX_IPUV3=m CONFIG_DRM_IMX_HDMI=m CONFIG_DRM_VC4=m -# CONFIG_DRM_ETNAVIV is not set +CONFIG_DRM_ETNAVIV=m +CONFIG_DRM_ETNAVIV_REGISTER_LOGGING=y # # Frame buffer Devices diff --git a/config/armv7hl/vanilla b/config/armv7hl/vanilla index 1cfdba3..b363690 100644 --- a/config/armv7hl/vanilla +++ b/config/armv7hl/vanilla @@ -5384,7 +5384,8 @@ CONFIG_DRM_IMX_LDB=m CONFIG_DRM_IMX_IPUV3=m CONFIG_DRM_IMX_HDMI=m CONFIG_DRM_VC4=m -# CONFIG_DRM_ETNAVIV is not set +CONFIG_DRM_ETNAVIV=m +CONFIG_DRM_ETNAVIV_REGISTER_LOGGING=y # # Frame buffer Devices -- 1.8.4.5 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 4