openSUSE Kernel March 2015

kernel@lists.opensuse.org

28 participants
27 discussions

[opensuse-kernel] Kernel:linux-next: ARM
by Matwey V. Kornilov 06 Oct '15

06 Oct '15

Hi, Could we have ARM builds for Kernel:linux-next? The reason behind is that our kernel in Kernel:HEAD usually not even builds for early rc-s due to carefully applied upstream bugs. It would be great to be able to detect build failures as early as possible and report the problems upstream. -- 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] 32bit 13.2 panic when no apm=off on cmdline
by Felix Miata 20 Sep '15

20 Sep '15

I just spent most of the past several days getting this Intel 2 core E6700 P965/ICH8 RAID1 system switched from 11.4 to 13.1 and 13.2 in multiboot via Grub Legacy on primary partition. To do so, I used a single HD Intel 2 core E7600 mule/testing system with 2 new disks added, using running 13.1's yast to build all RAID devices on the new pair prior to initializing 13.1 installation. I eventually got both 13.1 and 13.2 booting and running satisfactorily, restored an rsync backup of user data to the RAID, then shut down this system and moved the RAID pair to it. 13.1 worked satisfactorily immediately, including NIC config retaining fixed IP on eth0. 13.2 spewed trap/segfault errors in a neverending stream virtually instantly in trying to boot from some cmdline config attempts. Many of the others ended in trap data, blinking keyboard LEDs and frozen screen claiming reboot would occur in 90 seconds. The failsafe stanza provided boot, but during init many errors were spewed on tty1 among normal messages. Before I even thought to try failsafe, I chrooted from 13.1 to zypper up and update kernel from 3.16.6 to 3.16.7, then when that didn't help, TW's 3.18.3, also no help. I booted failsafe taking one more option off cmdline each time about 8 times until the only rescue options left were noresume and apm=off, so apm=off definitely functions to get a working boot, yet not without seeing the error stream on tty1. The last attempt without apm=off produced the frozen screen and keyboard condition. I looked in the mailing list archives and Bugzilla, but didn't find anything I recognized as similar. Is there something journalctl can capture that can help someone help me figure out if this is a 13.2 bug that may have escaped discovery before now? FWIW, installing new kernels via chroot produces 13.2 initrds 50% bigger than those happening on account of zypper up processing. Here out of habit, zypper up/dup excludes adding a new kernel. I zypper al kernel* first, up, unlock, then repeat, so that the new kernel's initrd is guaranteed to be built once only. Also FWIW, 13.1 (like 11.4 did) requires clock=hpet on cmdline to prevent clock apparently overpowering ntp. While asleep last night it gained something like 10 minutes in 6 hours. -- "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

2 5

[opensuse-kernel] Set SCSI_MQ_DEFAULT=n in Kernel:stable
by David Sterba 24 Apr '15

24 Apr '15

Hi, currently the scsi-mq is set to Y, since 3.18-rc1 merge. The option enables a feature that makes advantage of enterprise-class storage. It's known not to perform well on slower devices [1] and lacks scheduler support. We'll set the option to N in our stable kernels. The lack of scheduler support can cause significant performance drop. Vojtech reports 10-50x slowdown on random read workloads, the disks seek all over the platters due to the missing io scheduler optimizations. As most of our users are not likely to run on high-end storage devices or otherwise benefit from the scsi-mq feature, I believe it's safe to turn the scsi-mq option off. Once the io scheduler support is availabe we can enable it again. The change will be done for all architectures and all kernel flavors (30 changes in total). [1] http://www.spinics.net/lists/linux-scsi/msg75246.html -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

4 11

[opensuse-kernel] [PATCH] ARM64: stable: Fix support for ARMv7 userspace
by Dirk Müller 04 Apr '15

04 Apr '15

Hi, here's the stable backport of the patchset. please review/merge. TIA, Dirk

2 3

[opensuse-kernel] optimizing ext4 bytes-per-inode on large arrays installed on opensuse?
by lyndat3＠your-mail.com 02 Apr '15

02 Apr '15

I'm replacing a RAID array for a NAS. I'm about to create a the ext4 partition on the primary, full-disk LV. The original LV had been formatted ext4, with defaults, mkfs.ext4 /dev/VG0/NAS03 I'm looking at the original drive's usage, hoping to optimize the new drive. /bin/df /dev/VG0/NAS03 Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VG0-NAS03 1548182724 1383153132 86363468 95% /NAS03 /bin/df -i /dev/VG0/NAS03 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/VG0-NAS03 98312192 1182797 97129395 2% /NAS03 For 1383153132 1K blocks = 1,416,348,807,168 bytes in use results in an effective 'bytes-per-inode' 1,416,348,807,168 / 1182797 = 1,197,457 bytes/inode The ext4 fs defaults for mke2fs on opensuse are cat /etc/mke2fs.conf [defaults] base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr default_mntopts = acl,user_xattr enable_periodic_fsck = 0 blocksize = 4096 inode_size = 256 inode_ratio = 16384 [fs_types] ... ext4 = { features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize auto_64-bit_support = 1 inode_size = 256 } ... The parameters are documented at https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions http://man7.org/linux/man-pages/man5/ext4.5.html Assuming (correct?) that "inode_ratio" == "bytes-per-inode" Comparing the default vs effective ratios 16384 <<< 1,197,457 where the effective ratio for my current usage profile falls between largefile = { inode_ratio = 1048576 blocksize = -1 } & largefile4 = { inode_ratio = 4194304 blocksize = -1 } Assuming that usage over time will be similar for the new LV, and Usage: mkfs.ext4 [-c|-l filename] [-b block-size] [-C cluster-size] [-i bytes-per-inode] [-I inode-size] [-J journal-options] [-G flex-group-size] [-N number-of-inodes] [-m reserved-blocks-percentage] [-o creator-os] [-g blocks-per-group] [-L volume-label] [-M last-mounted-directory] [-O feature[,...]] [-r fs-revision] [-E extended-option[,...]] [-t fs-type] [-T usage-type ] [-U UUID] [-jnqvDFKSV] device [blocks-count] for optimal performance, *should* the new LV fs be created as mkfs.ext4 -T largefile ... ? Might as well get it right before locking it in. LT -- 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] large data transfer rate slowdows over NFSv4 local lan with kernel 3.19.3x ?
by lyndat3＠your-mail.com 01 Apr '15

01 Apr '15

I was just pinged on this by a client; I can reproduce it here. I have two opensuse 13.2 machines. NFS xfers -- cp & rsync -- between them slow to a crawl: < 1 MB/sec in the worst case, over a 1Gb local lan. Chats @ #networking/#nfs suggest this is a kernel+NFS issue. So checking here 1st. Both machines run kernel uname -rm 3.19.3-1.gf10e7fc-default x86_64 Both have NFS installed. Packages include nfs-client-1.3.0-4.2.1.x86_64 nfs-kernel-server-1.3.0-4.2.1.x86_64 The server's store is at /NAS/NAS1 it's on a LV on a software (mdadm v3.3.1) RAID-10 array. The client's mounted it at /mnt/NFS4/NAS1 mount | grep NAS1 xen01.loc:/ on /mnt/NFS4/NAS1 type nfs4 (rw,nosuid,nodev,relatime,sync,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,soft,nosharecache,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.101,fsc,local_lock=none,addr=10.0.0.1) The diagnostics I can think to do follow. creating test files @ both machines @ server dd if=/dev/zero of=/NAS/NAS1/dump-server-file bs=1024 count=1000000 1000000+0 records in 1000000+0 records out 1024000000 bytes (1.0 GB) copied, 1.37631 s, 744 MB/s @ client dd if=/dev/zero of=~/dump-client-file bs=1024 count=1000000 1000000+0 records in 1000000+0 records out 1024000000 bytes (1.0 GB) copied, 1.988 s, 515 MB/s TESTS (1) server -> server, local cp rm -f /tmp/dump-server-file time /bin/cp /NAS/NAS1/dump-server-file /tmp/ real 0m0.486s user 0m0.004s sys 0m0.480s ~= 2100MB/s (real) ~= 2100MB/s (sys) (2) server -> server, local rsync rm -f /tmp/dump-server-file time /usr/bin/rsync /NAS/NAS1/dump-server-file /tmp/ real 0m2.491s user 0m3.344s sys 0m1.264s ~= 411 MB/s (real) ~= 810 MB/s (sys) (3) client -> server, PING ping -c 10 10.0.0.1 PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.307 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.280 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.303 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.280 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=0.262 ms 64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=0.290 ms 64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=0.281 ms 64 bytes from 10.0.0.1: icmp_seq=8 ttl=64 time=0.286 ms 64 bytes from 10.0.0.1: icmp_seq=9 ttl=64 time=0.287 ms 64 bytes from 10.0.0.1: icmp_seq=10 ttl=64 time=0.291 ms --- 10.0.0.1 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 8999ms rtt min/avg/max/mdev = 0.262/0.286/0.307/0.023 ms (4) client -> `iperf3 -s`@server: TCP, one thread iperf3 -c 10.0.0.1 -t 60 -i 15 -F ~/dump-client-file -f M [ ID] Interval Transfer Bandwidth Retr [ 5] 0.00-3.08 sec 337 MBytes 918 Mbits/sec 10 sender [ 5] 0.00-3.08 sec 336 MBytes 915 Mbits/sec receiver (5) client -> `iperf3 -s`@server: TCP, 100 threads iperf3 -c 10.0.0.1 -t 60 -i 15 -F ~/dump-client-file -f M -P100 [ ID] Interval Transfer Bandwidth Retr ... [SUM] 0.00-31.08 sec 3.40 GBytes 940 Mbits/sec 121 sender [SUM] 0.00-31.08 sec 3.39 GBytes 937 Mbits/sec receiver (6) client -> `iperf3 -s`@server: UDP, one thread iperf3 -c 10.0.0.1 -t 60 -i 15 -F ~/dump-client-file -f M -b 1G -P 1 [ ID] Interval Transfer Bandwidth Retr ... [ 5] 0.00-8.97 sec 977 MBytes 913 Mbits/sec 25 sender [ 5] 0.00-8.97 sec 976 MBytes 912 Mbits/sec receiver (7) client -> `iperf3 -s`@server: UDP, 100 threads iperf3 -c 10.0.0.1 -t 60 -i 15 -F ~/dump-client-file -f M -b 1G -P 100 [ ID] Interval Transfer Bandwidth Retr ... [SUM] 0.00-60.01 sec 6.56 GBytes 939 Mbits/sec 180 sender [SUM] 0.00-60.01 sec 6.55 GBytes 937 Mbits/sec receiver (8) client -> server, cp over NFS rm -f /mnt/NFS4/NAS1/dump-client-file time /bin/cp ~/dump-client-file /mnt/NFS4/NAS1/ real 0m54.589s user 0m0.005s sys 0m1.225s ~= 18.75 MB/s (real) ~= 810 MB/s (sys) (9) client -> server, rsync over NFS rm -f /mnt/NFS4/NAS1/dump-client-file time /usr/bin/rsync ~/dump-client-file /mnt/NFS4/NAS1/ real 18m13.408s user 0m4.642s sys 0m2.627s ~= 0.937 MB/s (real) ~= 390 MB/s (sys) If there's additional diagnostic info, I can provide it. What's causing the disproportionate slow down and what's needed for a fix? LT -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 9

[opensuse-kernel] [PATCH] ARM: config: Enable Stack Protector
by Dirk Müller 31 Mar '15

31 Mar '15

Signed-off-by: Dirk Mueller <dmueller(a)suse.com> --- config/armv7hl/default | 6 +++--- config/armv7hl/lpae | 6 +++--- config/armv7hl/vanilla | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/config/armv7hl/default b/config/armv7hl/default index 52ce7ec..ff55541 100644 --- a/config/armv7hl/default +++ b/config/armv7hl/default @@ -238,9 +238,9 @@ CONFIG_HAVE_PERF_USER_STACK_DUMP=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_HAVE_CC_STACKPROTECTOR=y -# CONFIG_CC_STACKPROTECTOR is not set -CONFIG_CC_STACKPROTECTOR_NONE=y -# CONFIG_CC_STACKPROTECTOR_REGULAR is not set +CONFIG_CC_STACKPROTECTOR=y +# CONFIG_CC_STACKPROTECTOR_NONE is not set +CONFIG_CC_STACKPROTECTOR_REGULAR=y # CONFIG_CC_STACKPROTECTOR_STRONG is not set CONFIG_HAVE_CONTEXT_TRACKING=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y diff --git a/config/armv7hl/lpae b/config/armv7hl/lpae index 4af5bff..20b08c9 100644 --- a/config/armv7hl/lpae +++ b/config/armv7hl/lpae @@ -239,9 +239,9 @@ CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_HAVE_RCU_TABLE_FREE=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_HAVE_CC_STACKPROTECTOR=y -# CONFIG_CC_STACKPROTECTOR is not set -CONFIG_CC_STACKPROTECTOR_NONE=y -# CONFIG_CC_STACKPROTECTOR_REGULAR is not set +CONFIG_CC_STACKPROTECTOR=y +# CONFIG_CC_STACKPROTECTOR_NONE is not set +CONFIG_CC_STACKPROTECTOR_REGULAR=y # CONFIG_CC_STACKPROTECTOR_STRONG is not set CONFIG_HAVE_CONTEXT_TRACKING=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y diff --git a/config/armv7hl/vanilla b/config/armv7hl/vanilla index 8b4f3c9..ba6a1dc 100644 --- a/config/armv7hl/vanilla +++ b/config/armv7hl/vanilla @@ -236,9 +236,9 @@ CONFIG_HAVE_PERF_USER_STACK_DUMP=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_HAVE_CC_STACKPROTECTOR=y -# CONFIG_CC_STACKPROTECTOR is not set -CONFIG_CC_STACKPROTECTOR_NONE=y -# CONFIG_CC_STACKPROTECTOR_REGULAR is not set +CONFIG_CC_STACKPROTECTOR=y +# CONFIG_CC_STACKPROTECTOR_NONE is not set +CONFIG_CC_STACKPROTECTOR_REGULAR=y # CONFIG_CC_STACKPROTECTOR_STRONG is not set CONFIG_HAVE_CONTEXT_TRACKING=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y -- 2.0.4 -- 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] [PATCH] config: armv7hl: set CONFIG_DRM_ARMADA_TDA1998X to y
by Matwey V. Kornilov 30 Mar '15

30 Mar '15

When CONFIG_DRM_I2C_NXP_TDA998X is compiled as module, HDMI doesn't work properly on BeagleBone Black. --- 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 32ad5fd..cc69550 100644 --- a/config/armv7hl/default +++ b/config/armv7hl/default @@ -4975,7 +4975,7 @@ CONFIG_DRM_KMS_CMA_HELPER=y CONFIG_DRM_I2C_ADV7511=m CONFIG_DRM_I2C_CH7006=m CONFIG_DRM_I2C_SIL164=m -CONFIG_DRM_I2C_NXP_TDA998X=m +CONFIG_DRM_I2C_NXP_TDA998X=y CONFIG_DRM_DW_HDMI=m CONFIG_DRM_PTN3460=y # CONFIG_DRM_TDFX is not set @@ -5008,6 +5008,7 @@ CONFIG_DRM_UDL=m # CONFIG_DRM_MGAG200 is not set # CONFIG_DRM_CIRRUS_QEMU is not set CONFIG_DRM_ARMADA=m +CONFIG_DRM_ARMADA_TDA1998X=y CONFIG_DRM_RCAR_DU=m CONFIG_DRM_RCAR_HDMI=y CONFIG_DRM_RCAR_LVDS=y diff --git a/config/armv7hl/vanilla b/config/armv7hl/vanilla index 99ab711..c923983 100644 --- a/config/armv7hl/vanilla +++ b/config/armv7hl/vanilla @@ -4970,7 +4970,6 @@ CONFIG_DRM_KMS_CMA_HELPER=y CONFIG_DRM_I2C_ADV7511=m CONFIG_DRM_I2C_CH7006=m CONFIG_DRM_I2C_SIL164=m -CONFIG_DRM_I2C_NXP_TDA998X=m CONFIG_DRM_DW_HDMI=m CONFIG_DRM_PTN3460=y # CONFIG_DRM_TDFX is not set @@ -7822,3 +7821,5 @@ CONFIG_FONT_8x16=y CONFIG_ARCH_HAS_SG_CHAIN=y CONFIG_VIRTUALIZATION=y # CONFIG_SCSI_MQ_DEFAULT is not set +CONFIG_DRM_I2C_NXP_TDA998X=y +CONFIG_DRM_ARMADA_TDA1998X=y -- 2.1.4 -- 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] booting kernel-default, if Xen's installed (but not used), 'systemd-modules-load' service fails on system startup
by lyndat3＠your-mail.com 30 Mar '15

30 Mar '15

On an opensuse 13.2 server, I installed rpm -qa | egrep "kernel-default|kernel-xen|^xen-4" kernel-default-3.19.3-1.1.gf10e7fc.x86_64 kernel-xen-3.19.3-1.1.gf10e7fc.x86_64 xen-4.5.0_03-359.8.x86_64 It's booted to kernel-default uname -rm 3.19.3-1.gf10e7fc-default x86_64 Checking startup sequence systemd-analyze blame 13.447s systemd-modules-load.service 6.111s wicked.service 1.387s systemd-tmpfiles-clean.service ... 'systemd-modules-load.service' takes a long time. Investigating finds a unit fail, journalctl -xb | grep -i systemd-modules-load.service Mar 29 14:44:13 xen01 systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE -- Subject: Unit systemd-modules-load.service has failed -- Unit systemd-modules-load.service has failed. Mar 29 14:44:13 xen01 systemd[1]: Unit systemd-modules-load.service entered failed state. Mar 29 14:44:36 xen01 systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE -- Subject: Unit systemd-modules-load.service has failed -- Unit systemd-modules-load.service has failed. Mar 29 14:44:36 xen01 systemd[1]: Unit systemd-modules-load.service entered failed state. and details systemctl status systemd-modules-load.service -l systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: failed (Result: exit-code) since Sun 2015-03-29 14:44:36 PDT; 19min ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 833 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE) Main PID: 833 (code=exited, status=1/FAILURE) Mar 29 14:44:23 xen01 systemd-modules-load[833]: Failed to find module 'xen-evtchn' Mar 29 14:44:23 xen01 systemd-modules-load[833]: Failed to find module 'xen-gntdev' Mar 29 14:44:23 xen01 systemd-modules-load[833]: Failed to find module 'xen-gntalloc' Mar 29 14:44:36 xen01 systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE Mar 29 14:44:36 xen01 systemd[1]: Failed to start Load Kernel Modules. Mar 29 14:44:36 xen01 systemd[1]: Unit systemd-modules-load.service entered failed state. Looking in the unit file cat /usr/lib/systemd/system/systemd-modules-load.service # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Load Kernel Modules Documentation=man:systemd-modules-load.service(8) man:modules-load.d(5) DefaultDependencies=no Conflicts=shutdown.target After=systemd-readahead-collect.service systemd-readahead-replay.service Before=sysinit.target shutdown.target ConditionCapability=CAP_SYS_MODULE ConditionDirectoryNotEmpty=|/lib/modules-load.d ConditionDirectoryNotEmpty=|/usr/lib/modules-load.d ConditionDirectoryNotEmpty=|/usr/local/lib/modules-load.d ConditionDirectoryNotEmpty=|/etc/modules-load.d ConditionDirectoryNotEmpty=|/run/modules-load.d ConditionKernelCommandLine=|modules-load ConditionKernelCommandLine=|rd.modules-load [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/lib/systemd/systemd-modules-load The module load refernces are grep xen /usr/lib/modules-load.d/* /usr/lib/modules-load.d/xen.conf:xen-evtchn /usr/lib/modules-load.d/xen.conf:xen-gntdev /usr/lib/modules-load.d/xen.conf:xen-gntalloc /usr/lib/modules-load.d/xen.conf:xen-blkback /usr/lib/modules-load.d/xen.conf:xen-netback /usr/lib/modules-load.d/xen.conf:xen-pciback /usr/lib/modules-load.d/xen.conf:xen-scsibk /usr/lib/modules-load.d/xen.conf:xen-acpi-processor I installed Xen, but never manually enabled any of its service. Checking xen's services, cd /usr/lib/systemd/system for s in $(ls xen*) do systemctl status $s | grep Loaded done Two services are enabled (1) Loaded: loaded (/usr/lib/systemd/system/xencommons.service; enabled) Loaded: loaded (/usr/lib/systemd/system/xenconsoled.service; disabled) (2) Loaded: loaded (/usr/lib/systemd/system/xendomains.service; enabled) Loaded: loaded (/usr/lib/systemd/system/xen-init-dom0.service; disabled) Loaded: loaded (/usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service; disabled) Loaded: loaded (/usr/lib/systemd/system/xenstored_ro.socket; disabled) Loaded: loaded (/usr/lib/systemd/system/xenstored.service; disabled) Loaded: loaded (/usr/lib/systemd/system/xenstored.socket; disabled) Loaded: loaded (/usr/lib/systemd/system/xen-watchdog.service; disabled) I'm booting to non-Xen. Why is the 'systemd-modules-load' unit attempting to load xen modules, and failing, in this case? Shouldn't that be conditional on which kernel flavor? LT -- 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] how to control/modify early framebuffer & resolution on UEFI-booted kernel 3.19.2?
by lyndat3＠your-mail.com 28 Mar '15

28 Mar '15

I'll start here -- because it is opensuse and kernel-related -- but don't know if this is the ultimately right place to ask. I'm working on setting console video resolution on an opensuse 13.2 server. I want 'hi-res' (to the extent possible), text-only display from grub menu, through completion of linux boot. My eventual questions are (1) why is 'efifb' used? it's supposed to be Mac-only (2) how do I change 'efifb' resolution? (3) can nouveaufb replace efifb completely? I have installed uname -r 3.19.2-3.gd8856ce-default It's booting UEFI dmesg | grep "efi: EFI" [ 0.000000] efi: EFI v2.31 by American Megatrends The mobo/cpu is SuperMicro + Intel Xeon Haswell v3. The video card is lspci -vnn | grep -i vga 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119 [GeForce GT 610] [10de:104a] (rev a1) (prog-if 00 [VGA controller]) 'nouveau' driver is in use rpm -qa | grep nouveau libdrm_nouveau2-2.4.58-1.1.x86_64 hwinfo --gfxcard | egrep "[ ]*Model:|[ ]*Driver" Model: "nVidia GF119 [GeForce GT 610]" Driver: "nouveau" Driver Modules: "drm" Driver Info #0: Driver Status: nouveau is active Driver Activation Cmd: "modprobe nouveau" The boot sequence display starts with 'efifb', @ availble (low) res dmesg | egrep "efifb:|fb[0-9]:" | grep -vi "command line" [ 2.936016] efifb: probing for efifb [ 2.939612] efifb: framebuffer at 0xd1000000, mapped to 0xffffc9000b800000, using 1876k, total 1875k [ 2.948732] efifb: mode is 800x600x32, linelength=3200, pages=1 [ 2.954648] efifb: scrolling: redraw [ 2.958223] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 2.975291] fb0: EFI VGA frame buffer device [ 18.366826] nouveau 0000:02:00.0: fb0: nouveaufb frame buffer device at the last line ^^ it then hands-off to 'nouveaufb' dmesg | grep nouveaufb [ 26.934467] fb: switching to nouveaufb from EFI VGA [ 27.530632] fbcon: nouveaufb (fb0) is primary device [ 27.612790] nouveau 0000:02:00.0: fb0: nouveaufb frame buffer device In GRUB2 config I am able to set the video resolution (in my case, to 1920x1080) only AFTER the handoff to 'nouveaudb' Given grep . /sys/class/drm/card*-*/modes | head -n 3 /sys/class/drm/card0-HDMI-A-1/modes:1920x1080 /sys/class/drm/card0-HDMI-A-1/modes:1680x1050 /sys/class/drm/card0-HDMI-A-1/modes:1280x1024 setting GRUB_CMDLINE_LINUX="... video=HDMI-A-1:1920x1080@60" works as intended. But, from grub menu display up until that point, i.e. prior to the fb handoff, the display resolution used by 'efifb' is currently limited to 800x600. Available EFI video modes are grub> videoinfo List of supported video modes: Legend: mask/position=red/green/blue/reserved ... Adapter 'EFI GOP Driver': * 0x000 800 x 600 x 32 (3200) Direct color, mask: 8/8/8/8/ pos: 16/8/0/24 0x001 1024 x 768 x 32 (4096) Direct color, mask: 8/8/8/8/ pos: 16/8/0/24 According to https://www.kernel.org/doc/Documentation/fb/efifb.txt "... efifb is only for EFI booted Intel Macs. ..." This is not a Mac, so why is the 'efifb' being used? Since this is post-grub2-menu, it seems something in the opensuse install/setup is possibly misidentifying the hardware. Randomly trying each of video=efifb:0x001 video=efifb:1024x768 video=efifb:1024x768x32 to GRUB_CMDLINE_LINUX="... video=efifb:<...> video=HDMI-A-1:1920x1080@60" had no effect. 'nouveaufb' clearly has the mode support I need. Is it possible to get the efi-booted kernel to use it @ early display, immediately post-grub2-menu? LT -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 7

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openSUSE Kernel March 2015