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
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
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
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_Questionshttp://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
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
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
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
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