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
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
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
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
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
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
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