openSUSE Kernel March 2018

kernel@lists.opensuse.org

18 participants
7 discussions

[opensuse-kernel] Reliability test for hard drives and SSD

by Andrey Ponomarenko

Hi there! Good news for all interested in hardware compatibility and reliability. I've started a new project to estimate reliability of hard drives and SSD in real-life conditions based on the SMART data reports collected by Linux users in the Linux-Hardware.org database since 2014. The initial data (SMART reports), analysis methods and results are publicly shared in a new github repository: https://github.com/linuxhw/SMART. Everyone can contribute to the report by uploading probes of their computers by the hw-probe tool! The primary aim of the project is to find drives with longest "power on hours" and minimal number of errors. The following formula is used to measure reliability: Power_On_Hours / (1 + Number_Of_Errors), i.e. time to the first error/between errors. Please be careful when reading the results table. Pay attention not only to the rating, but also to the number of checked model samples. If rating is low, then look at the number of power-on days and number of errors occurred. New drive models will appear at the end of the rating table and will move to the top in the case of long error-free operation. Thanks to ROSA, openSUSE, Gentoo, Ubuntu, Debian, Mint, Arch, Fedora users and others who had made this work possible by contribution to the database! -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 years, 11 months

[opensuse-kernel] After upgrading Kernel:/stable 4.12.x -> 4.13.x, boot reproducible fails to dracut emergency shell. "busname"?

by sigise＠mailc.net

Hi, After upgrading from Kernel:/stable 4.12.x -> 4.13.x, on Leap 42.3, the system no longer boots -- instead drops to dracut emergency shell. Unfortunately, at shell, I've got no keyboard, and I have no serial port, so having some challenges GRABBING the early logs to share. I turned on more verbose logging. At boot, although without keyboard I can't, unfortunately INTERRUPT it on screen, I DO see an ENORMOUS amount of output (moving by VERY quickly ...) re: "dracut-initqueue" and something about "settled" ... Rebooting to 4.12.x, and checking prior boot, in journalctl I do NOT see any mention of dracut, but I DO see journalctl -b -1 -- Logs begin at Mon 2016-11-07 13:36:46 PST, end at Tue 2018-03-27 10:17:20 PDT. -- Mar 27 09:37:01 0031.austin.local CRON[2126]: (CRON) ERROR chdir failed (/var/lib/amavisd): No such file or directory Mar 27 09:37:01 0031.austin.local systemd[2123]: pam_unix(systemd-user:session): session closed for user amavisd Mar 27 09:37:01 0031.austin.local systemd[2122]: user(a)5003.service: Executing: /usr/lib/systemd/systemd --user Mar 27 09:37:01 0031.austin.local systemd[2122]: systemd 228 running in user mode for user 5003/amavisd. (+PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN) Mar 27 09:37:01 0031.austin.local systemd[2122]: Using cgroup controller name=systemd. File system hierarchy is at /sys/fs/cgroup/systemd/user.slice/user-5003.slice/user(a)5003.service. Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'cpu' supported: no Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'cpuacct' supported: yes Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'blkio' supported: yes Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'memory' supported: yes Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'devices' supported: yes Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'pids' supported: yes Mar 27 09:37:01 0031.austin.local systemd[2122]: Controller 'net_cls' supported: yes Mar 27 09:37:01 0031.austin.local systemd[2122]: Set up TFD_TIMER_CANCEL_ON_SET timerfd. Mar 27 09:37:01 0031.austin.local systemd[2122]: Spawned /usr/lib/systemd/user-generators/systemd-dbus1-generator as 2125. Mar 27 09:37:01 0031.austin.local systemd[2122]: /usr/lib/systemd/user-generators/systemd-dbus1-generator succeeded. Mar 27 09:37:01 0031.austin.local systemd[2122]: user-generators succeeded. Mar 27 09:37:01 0031.austin.local systemd[2122]: Looking for unit files in (higher priority first): Mar 27 09:37:01 0031.austin.local systemd[2122]: /var/lib/amavisd/.config/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /etc/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /run/user/5003/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /run/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /var/lib/amavisd/.local/share/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /usr/local/share/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /usr/share/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /usr/local/lib/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: /usr/lib/systemd/user Mar 27 09:37:01 0031.austin.local systemd[2122]: Unit type .busname is not supported on this system. Mar 27 09:37:01 0031.austin.local systemd[2122]: var.mount: Failed to load configuration: No such file or directory Mar 27 09:37:01 0031.austin.local systemd[2122]: var-lib.mount: Failed to load configuration: No such file or directory Mar 27 09:37:01 0031.austin.local systemd[2122]: var-lib-amavisd.mount: Failed to load configuration: No such file or directory Mar 27 09:37:01 0031.austin.local systemd[2122]: dev.mount: Failed to load configuration: No such file or directory Mar 27 09:37:01 0031.austin.local systemd[2122]: dev-mapper.mount: Failed to load configuration: No such file or directory ... This is DIFFERENT that for a successful boot to 4.12.x, where there's no mention of "busname" at all in journalctl I don't know what that busname is. Checking around, I 1st find a [systemd-devel] Failed units and "Unit type .busname is not supported on this system" https://lists.freedesktop.org/archives/systemd-devel/2015-February/028174.h… >> systemd[1]: Unit type .busname is not supported on this system. >> This may be ignored. >> .busname units are only supported on kdbus systems.> and https://fossies.org/linux/systemd/NEWS CHANGES WITH 219: 3512 * systemd now has an explicit notion of supported and 3513 unsupported unit types. Jobs enqueued for unsupported unit 3514 types will now fail with an "unsupported" error code. More 3515 specifically .swap, .automount and .device units are not 3516 supported in containers, .busname units are not supported on 3517 non-kdbus systems. .swap and .automount are also not 3518 supported if their respective kernel compile time options 3519 are disabled. On this box cd /usr/lib/systemd grep -i busname `grep -rlni busname .` Binary file ./systemd matches ./user/evolution-user-prompter.service:BusName=org.gnome.evolution.dataserver.UserPrompter0 ./user/glib-pacrunner.service:BusName=org.gtk.GLib.PACRunner ./user/evolution-source-registry.service:BusName=org.gnome.evolution.dataserver.Sources5 ./user/at-spi-dbus-bus.service:BusName=org.a11y.Bus ./user/gnome-terminal-server.service:BusName=org.gnome.Terminal ./user/evolution-addressbook-factory.service:BusName=org.gnome.evolution.dataserver.AddressBook9 ./user/evolution-calendar-factory.service:BusName=org.gnome.evolution.dataserver.Calendar7 Binary file ./systemd-coredump matches Binary file ./systemd-machined matches Binary file ./systemd-logind matches Binary file ./system-generators/systemd-debug-generator matches Binary file ./system-generators/systemd-getty-generator matches Binary file ./system-generators/systemd-dbus1-generator matches Binary file ./system-generators/systemd-sysv-generator matches Binary file ./system-generators/systemd-fstab-generator matches Binary file ./system-generators/systemd-hibernate-resume-generator matches Binary file ./system-generators/systemd-insserv-generator matches Binary file ./system-generators/systemd-cryptsetup-generator matches Binary file ./system-generators/systemd-gpt-auto-generator matches Binary file ./systemd-journald matches Binary file ./systemd-udevd matches ./system/wickedd-auto4.service:BusName=org.opensuse.Network.AUTO4 ./system/polkit.service:BusName=org.freedesktop.PolicyKit1 ./system/org.freedesktop.locale1.busname:[BusName] ./system/upower.service:BusName=org.freedesktop.UPower ./system/org.freedesktop.hostname1.busname:[BusName] ./system/wpa_supplicant.service:BusName=fi.w1.wpa_supplicant1 ./system/NetworkManager.service:BusName=org.freedesktop.NetworkManager ./system/wickedd-nanny.service:BusName=org.opensuse.Network.Nanny ./system/wpa_supplicant@.service:BusName=fi.w1.wpa_supplicant1 ./system/geoclue.service:BusName=org.freedesktop.GeoClue2 ./system/wickedd.service:BusName=org.opensuse.Network ./system/org.freedesktop.systemd1.busname:[BusName] ./system/accounts-daemon.service:BusName=org.freedesktop.Accounts ./system/tuned.service:BusName=com.redhat.tuned ./system/systemd-localed.service:BusName=org.freedesktop.locale1 ./system/udisks2.service:BusName=org.freedesktop.UDisks2 ./system/org.freedesktop.timedate1.busname:[BusName] ./system/rtkit-daemon.service:BusName=org.freedesktop.RealtimeKit1 ./system/wickedd-dhcp4.service:BusName=org.opensuse.Network.DHCP4 ./system/systemd-timedated.service:BusName=org.freedesktop.timedate1 ./system/org.freedesktop.network1.busname:[BusName] ./system/colord.service:BusName=org.freedesktop.ColorManager ./system/org.freedesktop.machine1.busname:[BusName] ./system/bluetooth.service:BusName=org.bluez ./system/thermald.service:BusName=org.freedesktop.thermald ./system/systemd-machined.service:BusName=org.freedesktop.machine1 ./system/org.freedesktop.import1.busname:[BusName] ./system/systemd-hostnamed.service:BusName=org.freedesktop.hostname1 ./system/systemd-networkd.service:# On kdbus systems we pull in the busname explicitly, because it ./system/systemd-networkd.service:Wants=org.freedesktop.network1.busname ./system/systemd-networkd.service:After=org.freedesktop.network1.busname ./system/systemd-logind.service:BusName=org.freedesktop.login1 ./system/wickedd-dhcp6.service:BusName=org.opensuse.Network.DHCP6 ./system/systemd-importd.service:BusName=org.freedesktop.import1 ./system/org.freedesktop.login1.busname:[BusName] ./system/NetworkManager-dispatcher.service:BusName=org.freedesktop.nm_dispatcher Binary file ./systemd-update-utmp matches -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 3 months

[opensuse-kernel] kernel tools packaging

by Guillaume Gardet

Hi, the kernel provides a number of tools in the tools/ subdir. I think some of them would be nice to package, such as tools/gpio and tools/spi, especially for ARM. What would be the best way to do it? Integrate those tools in kernel packaging (Create a new spec file in kernel sources), or create a standalone package outside the kernel packaging (see [1])? Guillaume [1]: https://build.opensuse.org/package/show/home:Guillaume_G:ARM/gpio-tools -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 4 months

[opensuse-kernel] Raspberry PI3 kernel - gpio export error

by Raz

Hey I am using raspberry PI3 64bit. I am failing to export a gpio. ie; when I enter: echo 4 > /sys/class/gpio/export I get permission denied. Any idea ? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 4 months

Re: [opensuse-kernel] Raspberry PI3 kernel - gpio export error

by Raz

Yes. I am root.I tried with: openSUSE-Leap42.2-ARM-E20-raspberrypi3.aarch64-2017.02.02-Build1.165.raw openSUSE-Leap42.3-ARM-JeOS-raspberrypi3.aarch64-2017.07.26-Build1.1.raw openSUSE-Leap42.3-ARM-XFCE-raspberrypi3.aarch64-2017.07.26-Build1.1.raw and the gpios cannot be exported. When I boot regular Raspbian distribution I can export it. Can you export ? On Thu, Mar 8, 2018 at 11:59 AM, Raz <raziebe(a)gmail.com> wrote: > Yes. I am root. > > > בתאריך 8 במרץ 2018 11:40,‏ "Michal Suchánek" <msuchanek(a)suse.de> כתב: > >> Hello, >> >> On Wed, 7 Mar 2018 09:41:14 +0200 >> Raz <raziebe(a)gmail.com> wrote: >> >> > Hey >> > >> > I am using raspberry PI3 64bit. >> > I am failing to export a gpio. ie; when I enter: >> > echo 4 > /sys/class/gpio/export >> > >> > I get permission denied. >> > >> > Any idea ? >> >> Are you root? >> >> sudo does not work with > >> >> HTH >> >> Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 4 months

[opensuse-kernel] [PATCH] x86/kvm/vmx: do not use vm-exit instruction length for fast MMIO when running nested

by Matwey V. Kornilov

From: Vitaly Kuznetsov <vkuznets(a)redhat.com> I was investigating an issue with seabios >= 1.10 which stopped working for nested KVM on Hyper-V. The problem appears to be in handle_ept_violation() function: when we do fast mmio we need to skip the instruction so we do kvm_skip_emulated_instruction(). This, however, depends on VM_EXIT_INSTRUCTION_LEN field being set correctly in VMCS. However, this is not the case. Intel's manual doesn't mandate VM_EXIT_INSTRUCTION_LEN to be set when EPT MISCONFIG occurs. While on real hardware it was observed to be set, some hypervisors follow the spec and don't set it; we end up advancing IP with some random value. I checked with Microsoft and they confirmed they don't fill VM_EXIT_INSTRUCTION_LEN on EPT MISCONFIG. Fix the issue by doing instruction skip through emulator when running nested. Fixes: 68c3b4d1676d870f0453c31d5a52e7e65c7448ae Suggested-by: Radim Krčmář <rkrcmar(a)redhat.com> Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets(a)redhat.com> Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> (cherry picked from commit d391f1207067268261add0485f0f34503539c5b0) Patch-mainline: v4.16-rc1 Git-commit: d391f1207067268261add0485f0f34503539c5b0 References: boo#1081431 Signed-off-by: Matwey V. Kornilov <matwey.kornilov(a)gmail.com> --- Hello, The commit message references Hyper-V, but the same patch fixes issues with nested guests at VmWare ESXi. See boo#1081431 for reference. This is for openSUSE-42.3 and openSUSE-15.0 arch/x86/kvm/vmx.c | 18 ++++++++++++++++-- arch/x86/kvm/x86.c | 3 ++- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index d46d88117bfa..2dfd16736535 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -6036,9 +6036,23 @@ static int handle_ept_misconfig(struct kvm_vcpu *vcpu) gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS); if (!kvm_io_bus_write(vcpu, KVM_FAST_MMIO_BUS, gpa, 0, NULL)) { - skip_emulated_instruction(vcpu); trace_kvm_fast_mmio(gpa); - return 1; + /* + * Doing kvm_skip_emulated_instruction() depends on undefined + * behavior: Intel's manual doesn't mandate + * VM_EXIT_INSTRUCTION_LEN to be set in VMCS when EPT MISCONFIG + * occurs and while on real hardware it was observed to be set, + * other hypervisors (namely Hyper-V) don't set it, we end up + * advancing IP with some random value. Disable fast mmio when + * running nested and keep it for real hardware in hope that + * VM_EXIT_INSTRUCTION_LEN will always be set correctly. + */ + if (!static_cpu_has(X86_FEATURE_HYPERVISOR)) { + skip_emulated_instruction(vcpu); + return 1; + } else + return x86_emulate_instruction(vcpu, gpa, EMULTYPE_SKIP, + NULL, 0) == EMULATE_DONE; } ret = handle_mmio_page_fault(vcpu, gpa, true); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 49fcdac6e3af..6e244bd9d79c 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5476,7 +5476,8 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, * handle watchpoints yet, those would be handled in * the emulate_ops. */ - if (kvm_vcpu_check_breakpoint(vcpu, &r)) + if (!(emulation_type & EMULTYPE_SKIP) && + kvm_vcpu_check_breakpoint(vcpu, &r)) return r; ctxt->interruptibility = 0; -- 2.13.6 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 4 months

[opensuse-kernel] openSUSE Tumbleweed will receive signed modules

by Jiri Slaby

Hi, we currently sign the kernel in openSUSE but we don't sign modules. I am not going to open the questions for released/semi-released products like openSUSE 42.3 or openSUSE 15. But I see no reason why we shouldn't sign modules in Tumbleweed and in releases forked from TW in the future. The reasons are at least: * to allow for more security (attackers have harder times to replace our modules with theirs) * offer what SLE offers. We have modules signing there since SLE11 (i.e. 2012)! * be competitive with other distros; ubuntu and fedora both sign So my plan is to enable modules signing in the near future, perhaps even before merging 4.16 and push it out to the wild. There may be some nits to solve, but given we are flying on SLE for years already, it should be no hard work. As the next step, I would love to have kernels in Kernel:* signed by SUSE keys too. The current state forces people who test them (me including) to have secure boot disabled. That is not nice at all. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openSUSE Kernel March 2018