You are not logged in.
Hello, after yesterday update I have the same problem, freezing on boot, on either regular or fallback image. Problem disappear if I boot with acpi=off parameter.
Architecture: x86_64, CPU(s): 4, CPU family: 6, Model: 23
Model name: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz
BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=d64fe3c3-a144-4b79-b463-75fb0c5e025f rw acpi=off
Linux 4.18.5-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 24 12:48:58 UTC 2018 x86_64 GNU/Linux
Offline
So many much better options have been found in this thread and you go for disabling the kitchen sink? Does changing the clocksource not suffice for your case?
Offline
Is everyone suffering from this on an x200 running libreboot?
Offline
Is everyone suffering from this on an x200 running libreboot?
Nope. Running a Dell Latitude E6400 with the normal Dell BIOS.
Also have seen a Lenovo SL500, Dell M4400, Dell E6500, and a HP G61 on this thread. But there does seem to be quite a few people using x200s
Offline
I can boot on the kernel 4.18.5 if I add nosmp to the boot parameters, however, my laptop only recognizes 1 cpu when running nproc. I also get a message about my bios being broken (libreboot), but I think I have been getting this message since changing over to libreboot. When I tried using the acpi=off boot parameter, the laptop boots, but I cannot log in because the keyboard stops working.
From one Libreboot user to another, you can fix the "bios is broken" message by adding the intremap=off parameter.
Offline
So many much better options have been found in this thread and you go for disabling the kitchen sink? Does changing the clocksource not suffice for your case?
Yes, works:
clocksource=tsc -> boot freeze
---
clocksource=hpet -> boot ok
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hpet acpi_pm
---
clocksource=acpi_pm -> boot ok
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
acpi_pm
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hpet acpi_pm
---
acpi=off -> boot ok
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet
Offline
.Looking at the hardware from the users in this thread, I have the impression that the problem seems to occur with old Intel Core 2 Duo and related CPUs (I have a Core 2 Duo E8400). Therefore I looked for related changes in the kernel version 4.18 and I found out that there were at least these changes regarding the boot process on x86:
https://git.kernel.org/pub/scm/linux/ke … 7578ec1a71
I've just seen this issue on phoronix.
I have the same CPU and don't have the issue. My system is using the clocksource tsc.
$ head /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
stepping : 10
microcode : 0xa0b
cpu MHz : 2201.065
cache size : 6144 KB
physical id : 0
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
Offline
https://bugzilla.kernel.org/show_bug.cgi?id=200957#c4 at least the response was quick.
Offline
My computer is using hpet as the clock source. I have no idea if this is something which needs to be changed... For the time being, I've downgraded to kernel 4.17.14-arch1-1-ARCH as it is the newest kernel which recognizes both cores on my laptop. (It's nearly impossible to use firefox with only one cpu core.
Offline
E-Mails have been sent to the kernel developers and LKML.
Should not take long before it gets fixed.
I also wanted to mention that if a new issue on the kernel.org bugzilla is submitted,
the bugtracker will notify the subsystem maintainers per e-mail automatically.
So, there is not just an idle bugzilla entry, at least in our case, which we knew was related to 'timers'.
Offline
E-Mails have been sent to the kernel developers and LKML.
Here is the mail: https://lkml.org/lkml/2018/8/30/341
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Online
NiceGuy wrote:E-Mails have been sent to the kernel developers and LKML.
Here is the mail: https://lkml.org/lkml/2018/8/30/341
Subject REGRESSION: boot stalls on several old dual core Intel CPUs
Hmm, I have quad core (Q9550).
Offline
Still likely to be the same/similar underlying core architecture, so it's unsurprising you are affected as well.
Offline
Yes, I meant with my post that probably better would be to describe it as "Core 2" problem instead of "old dual core" for clarity reasons. But may be it is sufficient for them.
Offline
Depends if the kernel developers are able to reproduce the issue https://lore.kernel.org/lkml/2018083013 … s-ass.net/
Offline
Booting and works properly.
$ uname -srv
Linux 4.18.5-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 24 12:48:58 UTC 2018
$ lscpu
Model name: Intel(R) Core(TM)2 CPU T5300 @ 1.73GHz
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
Offline
benoliver999 wrote:Is everyone suffering from this on an x200 running libreboot?
Nope. Running a Dell Latitude E6400 with the normal Dell BIOS.
Also have seen a Lenovo SL500, Dell M4400, Dell E6500, and a HP G61 on this thread. But there does seem to be quite a few people using x200s
You may add the Dell Latitude XT2 with ye olde Intel(R) Core(TM)2 Duo CPU U9600 @ 1.60GHz to that list. No bueno in 4.18.5 (and .4) except for fallback mode.
Offline
Those affected are you using intel-ucode.img and what flags does lscpu show?
Offline
Since the fallback image boots fine, maybe you can try different compression algorithms for the image?
The weirdest thing about this bug is that the same kernel works fine with the fallback image but fails with the default.
Edit: Maybe loqs is onto something. I don't have a Core 2 and no bug either, but I remembered that I only added intel-ucode to my default boot entry. The fallback option does not load the microcode.
Last edited by progandy (2018-08-30 16:19:26)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Online
NO, fallback image doesnt work for me as I already posted. Also delete microcode image from cmdline in grub doesnt work for me.
in addition from 'journalctl --boot':
microcode: microcode updated early to revision 0xa0b, date = 2010-09-28
Last edited by LK001 (2018-08-30 16:45:50)
Offline
microcode: intel-ucode loaded and used: yes
journalctl:
microcode: microcode updated early to revision 0x60f, date = 2010-09-29
microcode: Microcode Update Driver: v2.2
microcode: sig=0x10676, pf=0x1, revision=0x60f
lscpu 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 lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm pti tpr_shadow vnmi flexpriority dtherm
Last edited by NiceGuy (2018-08-30 17:36:37)
Offline
I tested without the microcode package intel-ucode, made sure it's also completely removed by pacman.
In all cases with 4.18.5 I have to use "clocksource=hpet" or "clocksource=acpi_pm" with both normal and fallback initrd or it is stalling.
"clocksource=tsc" also stalls and does not work for me.
Offline
I'm also intrigued to do a test install of Fedora 29; different distribution, different .config for the kernel also at version 4.18.5.
I report back if this issue persists across distributions. Might be far fetched, but I'm willing to try.
Offline
Do the boot options tsc=unstable or tsc=reliable have any effect?
Offline
Indeed: tsc=unstable works, tsc=reliable fails to boot and stalls.
Offline