I’m not sure what will be easier, figuring out how to get the latest update to boot or trying to roll it back.
After the latest update it required a restart, which I did, and now freezes at “loading initial ramdisk…” for kernel 4.4.143-65-default.
I am able to get back in using kernel 4.4.140-62-default, so I haven’t lost anything yet.
Any ideas or wisdom would be greatly appreciated.
Nvidia Driver is installed?
Yes. Now to add text to get 10 characters.
Post:
zypper se -si nvidia kernel
drew@linux-r85f:~> sudo zypper se -si nvidia kernel
[sudo] password for root:
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+---------------------------+---------+----------------------+--------+--------------------------
i+ | kernel-default | package | 4.4.143-65.1 | x86_64 | openSUSE-Leap-42.3-Update
i+ | kernel-default | package | 4.4.140-62.2 | x86_64 | openSUSE-Leap-42.3-Update
i+ | kernel-default-devel | package | 4.4.143-65.1 | x86_64 | openSUSE-Leap-42.3-Update
i+ | kernel-default-devel | package | 4.4.140-62.2 | x86_64 | openSUSE-Leap-42.3-Update
i+ | kernel-devel | package | 4.4.143-65.1 | noarch | openSUSE-Leap-42.3-Update
i+ | kernel-devel | package | 4.4.140-62.2 | noarch | openSUSE-Leap-42.3-Update
i+ | kernel-firmware | package | 20170530-20.1 | noarch | openSUSE-Leap-42.3-Update
i+ | kernel-macros | package | 4.4.143-65.1 | noarch | openSUSE-Leap-42.3-Update
i+ | nvidia-computeG04 | package | 390.77-9.1 | x86_64 | nVidia Graphics Drivers
i+ | nvidia-gfxG04-kmp-default | package | 390.77_k4.4.76_1-9.1 | x86_64 | nVidia Graphics Drivers
i+ | nvidia-glG04 | package | 390.77-9.1 | x86_64 | nVidia Graphics Drivers
i+ | x11-video-nvidiaG04 | package | 390.77-9.1 | x86_64 | nVidia Graphics Drivers
drew@linux-r85f:~>
Try as root:
zypper in -f nvidia-gfxG04-kmp-default
Reboot.
No luck on that. I was kinda wondering as the display driver glitches generally show up later on in the boot sequence.
Post:
cat /var/log/Xorg.0.log
Maybe as Textfile…
Sorry “I may NOT post attachments” and the output is too long. I could take out things that don’t seem relevant, such as Wacom tablet, in an effort to shorten it but I’m not really adept at that sort of thing and could make a mess.
You can use the susepaste command from a rescue boot from installation media, or other means to upload the file to susepaste.org, and provide a link to the resulting URL here.
Thanks for that.
Hello forum,
I am also hit by this event - kernel vmlinuz-4.4.143-65-default stops loading when or after it loads the kernel image into the ramdisk.
It looks like a permanent freeze without reaction to anything (ctrl alt del, SysRQ-Reboot request). Only the reset button helps…
I can boot into the fallback kernel (vmlinuz-4.4.140-62-default) - but I cannot find any logs from the broken boot process (journalctl --boot=-1 does yield the last succesful boot with the old kernel where I can follow the session where the updates were applied).
I use NVIDIA proprietary drivers…
As I can work for now, this is not a big issue, but I can provide additional info if required to help to clarify the issue.
Note: the formerly requested Xorg-logs also do not contain any line from the broken boot - just the successful boots.
Greetings
Bernd
I had the same problem and found out that the problems is with tsc. Add the following kernel parameter to solve: tsc=unstable
Ok - that was fast… and it solved the problem for me, too.
Stupid question: why?
cpuid reports my CPUs to be TscInvariant, so that the CPU manufacturer - well - guarantees that CPU powermanagement details should not affect the TSC reliability.
And it seemed to have worked until the last update…
Anyway - problem mitigated for now…
Many Thanks!
Greetings
Bernd
tsc-Time Stamp Counter is time source for the kernel. My guess is that a jitter is intentionally introduced to mitigate the meltdown and Spector CPU bugs. this apparently has some negative effects on some hardware. Pure guessing:P
The boot-up hanged on the following line: “Marking TSC unstable due to check_tsc_source failed”. The above parameter makes the boot process to ignore that check-up.
Exactly what CPU do you have. I run AMD CPU and have not seen the problem and just updated fully.
lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 12
On-line CPU(s) list: 0-11
Thread(s) per core: 2
Core(s) per socket: 6
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 63
Model name: Intel(R) Core™ i7-5930K CPU @ 3.50GHz
Stepping: 2
CPU MHz: 3400.063
CPU max MHz: 3700.0000
CPU min MHz: 1200.0000
BogoMIPS: 6812.20
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 15360K
NUMA node0 CPU(s): 0-11
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht
tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pcl
mulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer ae
s xsave avx f16c rdrand lahf_lm abm arat epb invpcid_single pln pts dtherm spec_ctrl ssbd ibpb stibp retpoline kaiser tpr_shadow vnmi f
lexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc
I think the issue is with the tsc_adjust flag. In other computers I have, on which boot up is OK this flag is absent.
Just to add my processor:
lscpu
Architektur: x86_64
CPU Operationsmodus: 32-bit, 64-bit
Byte-Reihenfolge: Little Endian
CPU(s): 12
Liste der Online-CPU(s):0-11
Thread(s) pro Kern: 2
Kern(e) pro Socket: 6
Sockel: 1
NUMA-Knoten: 1
Anbieterkennung: GenuineIntel
Prozessorfamilie: 6
Modell: 63
Modellname: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
Stepping: 2
CPU MHz: 1670.064
Maximale Taktfrequenz der CPU:3600,0000
Minimale Taktfrequenz der CPU:1200,0000
BogoMIPS: 6599.79
Virtualisierung: VT-x
L1d Cache: 32K
L1i Cache: 32K
L2 Cache: 256K
L3 Cache: 15360K
NUMA-Knoten0 CPU(s): 0-11
Markierungen: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm flush_l1d constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat invpcid_single pln pts dtherm spec_ctrl ssbd ibpb stibp retpoline kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc
Maybe we have a setup with this processor and the surrounding hardware that causes unwanted side effects…
My system is running now on an alternative time source (hpet) which seems to work well…
If every i7 processor would be affected I guess that we would see much more feedback or issue reports. I assume that it is only a combination of processor and environment that causes this unwanted effect to appear.
At least we have a workaround and people can find it now.
Greetings
Bernd