- Status Closed
- Percent Complete
- Task Type Bug Report
- Category Any
-
Assigned To
coadde Emulatorman g4jc - Operating System All
- Severity Critical
- Priority Very High
- Reported Version Any
- Due in Version Starfix
-
Due Date
Undecided
-
Votes
1
- fablamar78 (18/01/2019)
- Private
Attached to Project: Packages
Opened by ralessi - 18/01/2019
Last edited by Emulatorman - 21/01/2019
Opened by ralessi - 18/01/2019
Last edited by Emulatorman - 21/01/2019
FS#1342 - [linux-libre-lts] spinlock not released on kernel by i915, CPU stuck
Description:
With the latest release of the kernel, xwindow does not start anymore. I had to revert to 4.9.143.
Additional info:
* package version(s): linux-libre-lts-4.9.150_gnu-0-x86_64.pkg.tar.xz
Steps to reproduce:
Upgrade to the following:
- linux-libre-lts-4.9.150_gnu-0-x86_64.pkg.tar.xz
- linux-libre-lts-headers-4.9.150_gnu-0-x86_64.pkg.tar.xz
- acpi_call-lts-1.1.0-42.hyperbola34.6-x86_64.pkg.tar.xz
And try to start xwindow
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Same issue with several machines.
No X. No remote access (SSH)
Had to chroot and revert to 4.9.143.
No ssh either, this is serious. An other way to revert is by adding, say: `init=/bin/bash` as a kernel parameter, which gives you a shell. Then, you can `cd /var/cache/pacman/pkg` and revert with `pacman -U`.
Thanks for the tip Robert.
Yes indeed it is serious..
Same issue for me too, don't get me wrong, This distro hasn't had any issues like this before, but it is still annoying. ;/
Do you know when you will be able to fix this issue/upgrade to 4.14 lts kernel?
Oh by the way, will I have to reinstall the entire system? Just wondering... if there is a way to fix the problem without reinstalling the whole operating system all over again.
It is related to upstream, not Hyperbola. If you see, i just upgraded linux-libre-lts from 4.9.143 to 4.9.150 [0]
Anyway, there is a new revision (4.9.151) and i upgraded it in our git [1] . Currently, our build server is building it, so i'll let you know when it's ready in our stable repos.
We won't upgrade our kernel from 4.9 to 4.14 in Milky Way while it is under active development, see projected EOL in Linux kernel longterm releases for further details.
Ahh okay, so its a linux problem not a, Hyperbola problem... sounds about right. Never had this problem with any LTS kernel before though in any stable distro though.
Well anyways, do I need to reinstall my os completely?
So when it reaches EOL, you will update it to 4.14. Gotcha okay.
Thanks for showing that, I feel relieved to know it wasn't your fault or the fault of any Hyperbola developers. :)
It isn't needed, just upgrade when the latest kernel will be available from our repos. Anyway, i'll make testing before push it to our repos to see if it requires some backporting patch to solve the issue.
Maybe it's my fault to trust upstream completely instead of make testing before push it to repos. Anyway, i never imagined it could happened with a kernel for just upgrading it. So i'm sorry for the inconvenience.
I actually kept getting stuck on lxdm, given that I hae full disk encryption, but I found a way using a live iso and a rather strange guide on the net to figure out how to fix the issue.
I turned off LXDM, and now I can at least enter the console. But yeah, trusting upstream completely might be a small fault issue, but I still say most of this IS NOT your fault.
Upstream should have done so much better. ;)
No problem, you work your butt off making such an excellent distro. :)
linux-libre-lts-4.9.151_gnu-0 pushed and tested. Let me know if it works well in your machine to close this task.
linux-libre-lts-4.9.151_gnu-0 still not working. No X, no remote access. What's going on exactly here ?
PS : Not working with X200, T500, G41M-ES2L. All running with coreboot.
I have tested here and Xorg don't work with 4.9.151
4.9.151.log (43.3 KiB)
Strange, i tested it in my machine and virtual ones and works well. I will try replicate from my laptop and i'll let you know.
Thank you Jesús for your logs, it's so useful to understand where is the bug, because i can't replicate it.
fablamar, please send us your log files to research this bug (eg. kern.log, Xorg.0.log and Xorg.1.log)
Seems kernel soft lockups leading to complete system lockup. It's affecting users with Intel CPUs since i tested in AMD one and works. I'm looking for a way to solve it, sorry again for the inconvenience.
Same on my side. Tell me if you need my log files as well. (I use a librebooted X200.)
Don't be sorry. On the contrary, on behalf of Hyperbola users, I must say that we all are grateful!
I downgraded to linux-libre-lts-4.9.143_gnu-0 in our repos until fix the upstream one. Linux kernel is really getting poor programming lately. This is stable LTS kernel, so they shouldn't do stuff like this to it. :s
Please, we need the kern.log file from /var/log. It will help us to debug the issue better.
"I downgraded to linux-libre-lts-4.9.143_gnu-0 in our repos until fix the upstream one. Linux kernel is really getting poor programming lately. This is stable LTS kernel, so they shouldn't do stuff like this to it. :s"
Thank you, I was hoping you would do that, I really appreciate it, odd that an LTS kernel would have such errors right? ;/
Here is my kern.log. You'll see that line #1 is very strange!
linux-libre-lts-4.9.151_gnu-0.1 + locking/qspinlock regression patches pushed [0] . It was tested in a machine with i915 graphics driver support and works well. Please let us know if it works well in their machines to close this task.
Very well done André, it works on my side (Librebooted X200)!
@André :
Works fine now, thanks
Cool, thanks for let me know, i'm going to close this task. :)