[opensuse] kernel-default-5.3.18-lp152.33.1.x86_64 crashes
Hi, the July patches in kernel-default-5.3.18-lp152.33.1.x86_64 has here introduced a problem with hard lockups. No logging about the problem. Does anyone see the same crashing with the new kernel package? kernel-default-5.3.18-lp152.26.2.x86_64 works. Thanks Markus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 7/28/20 2:23 PM, Markus Kolb wrote:
Hi,
the July patches in kernel-default-5.3.18-lp152.33.1.x86_64 has here introduced a problem with hard lockups. No logging about the problem.
Does anyone see the same crashing with the new kernel package?
kernel-default-5.3.18-lp152.26.2.x86_64 works.
I didn't notice any on update, but I'll restart that VM and see how it does under use. In order to help further, it would be useful for you to tell us what type of hardware you are using, any attached devices or other hardware that may contribute. When you experience the crash -- are you doing anything in particular or is this just a random lockup? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 28.07.2020 21:52, schrieb David C. Rankin:
On 7/28/20 2:23 PM, Markus Kolb wrote:
Hi,
the July patches in kernel-default-5.3.18-lp152.33.1.x86_64 has here introduced a problem with hard lockups. No logging about the problem.
Does anyone see the same crashing with the new kernel package?
kernel-default-5.3.18-lp152.26.2.x86_64 works.
I didn't notice any on update, but I'll restart that VM and see how it does under use.
In order to help further, it would be useful for you to tell us what type of hardware you are using, any attached devices or other hardware that may contribute.
When you experience the crash -- are you doing anything in particular or is this just a random lockup?
Just asking if there is already known some problem... Feels randomly. Doing some development, compiling, test runs. Same 3 apps open. Whole day the same and with the latest kernel package it crashes suddenly after half an hour up to an hour. Now switched back to the previous kernel package version and no problem. If nobody knows anything particular, I will configure tomorrow for crash dumps and report a bug. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 7/28/20 5:56 PM, Markus Kolb wrote:
Just asking if there is already known some problem... Feels randomly. Doing some development, compiling, test runs. Same 3 apps open. Whole day the same and with the latest kernel package it crashes suddenly after half an hour up to an hour. Now switched back to the previous kernel package version and no problem.
If nobody knows anything particular, I will configure tomorrow for crash dumps and report a bug.
I have had 15.2 running since your earlier message and have compiled several significant Gtk applications as well as a few general C/C++ programs and I haven't been able to trigger a crash. (I don't know if the time has been long enouhg) Otherwise, I haven't seen anything similar since I installed in about a month before it was released. Only problem I have had was the purge-kernel app wiping out my kernel-devel, kernel-source, and kernel-syms during kernel updates, but that looks like it is solved now. See if there is anything that gets logged in the future that may shed more light on it. Post any further info you get of anything else that may be pertinent. But just on a general "Have you seen it?" level -- so far no. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 28/07/2020 21.23, Markus Kolb wrote:
Hi,
the July patches in kernel-default-5.3.18-lp152.33.1.x86_64 has here introduced a problem with hard lockups. No logging about the problem.
Does anyone see the same crashing with the new kernel package?
kernel-default-5.3.18-lp152.26.2.x86_64 works.
I assume you are using openSUSE Leap 15.2? -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
On 28/07/2020 16:17, Carlos E. R. wrote:
On 28/07/2020 21.23, Markus Kolb wrote:
Hi,
the July patches in kernel-default-5.3.18-lp152.33.1.x86_64 has here introduced a problem with hard lockups. No logging about the problem.
Does anyone see the same crashing with the new kernel package?
kernel-default-5.3.18-lp152.26.2.x86_64 works.
I assume you are using openSUSE Leap 15.2?
That assumption is unwarranted. I was using it with 15.1 I'm now using kernel-default-5.7.10 with Leap 15.1 -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 29/07/2020 03.07, Anton Aylward wrote:
On 28/07/2020 16:17, Carlos E. R. wrote:
On 28/07/2020 21.23, Markus Kolb wrote:
Hi,
the July patches in kernel-default-5.3.18-lp152.33.1.x86_64 has here introduced a problem with hard lockups. No logging about the problem.
Does anyone see the same crashing with the new kernel package?
kernel-default-5.3.18-lp152.26.2.x86_64 works.
I assume you are using openSUSE Leap 15.2?
That assumption is unwarranted. I was using it with 15.1
But you are not he, and I finished the phrase with a question mark ;-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 29/07/2020 04:31, Carlos E.R. wrote:
On 29/07/2020 03.07, Anton Aylward wrote:
On 28/07/2020 16:17, Carlos E. R. wrote:
On 28/07/2020 21.23, Markus Kolb wrote:
Hi,
the July patches in kernel-default-5.3.18-lp152.33.1.x86_64 has here introduced a problem with hard lockups. No logging about the problem.
Does anyone see the same crashing with the new kernel package?
kernel-default-5.3.18-lp152.26.2.x86_64 works.
I assume you are using openSUSE Leap 15.2?
That assumption is unwarranted. I was using it with 15.1
But you are not he, and I finished the phrase with a question mark ;-)
Indeed, and I've occasionally got hard lock-ups with all the 5.3 series kernels while using Firefox that necessitated a reboot. And no, restarting with the same configuration of tabs did not cause the lock-up to re-occur. There _may_ be a symptomatic issue with the kernel, but it is more likely a issue with Firefox or a library. I say this because a more common lock-up is with Firefox itself. While in FF I don't even have control over the cursor but can Alt-Tab to thunderbird, konsole or dolphin, for example, and control comes back. So I and kill the FF and restart it. The way that FF locks-up makes me sceptical about the kernel. Why do I loose so much control? Sometimes just in that application/window, sometimes the large scope. Might the problem be with KDE/plasma? Marcus did not mention the specific application that triggered the lock-up. The way he phrased it seemed to indicate that it was an accumulation of activity that triggered the problem with that specific kernel. That makes me wonder about the swap. My own experience with trying to 'tune' swap and swappiness and other paging parameters that seem to run afoul of using FF, as well as other sceptical comments on this forum about the way swap works in 15.x kernels compared to 42.x and 43.x adds to that. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 29.07.2020 15:13, schrieb Anton Aylward:
Marcus did not mention the specific application that triggered the lock-up. The way he phrased it seemed to indicate that it was an accumulation of activity that triggered the problem with that specific kernel. That makes me wonder about the swap. My own experience with trying to 'tune' swap and swappiness and other paging parameters that seem to run afoul of using FF, as well as other sceptical comments on this forum about the way swap works in 15.x kernels compared to 42.x and 43.x adds to that.
I'm talking about kernel crashing with hard lockup. So Num lock key or here the Shift lock key is blinking and also SysRq doesn't react. It has nothing to do with any application is using too many resources... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/07/2020 10:19, Markus Kolb wrote:
Am 29.07.2020 15:13, schrieb Anton Aylward:
Please don't cc me. I subscribe to the list and read there; there is not need to send me a personal copy as well.
Marcus did not mention the specific application that triggered the lock-up. The way he phrased it seemed to indicate that it was an accumulation of activity that triggered the problem with that specific kernel. That makes me wonder about the swap. My own experience with trying to 'tune' swap and swappiness and other paging parameters that seem to run afoul of using FF, as well as other sceptical comments on this forum about the way swap works in 15.x kernels compared to 42.x and 43.x adds to that.
I'm talking about kernel crashing with hard lockup. So Num lock key or here the Shift lock key is blinking and also SysRq doesn't react.
Yes, yes, and yes. That's what I'm describing.
It has nothing to do with any application is using too many resources...
I also have a window on 'vmstat' running, which will show me if I'm approaching a heavy load factor, swap thrashing or anything like that. <sidebar> yes, I've observed those with some applications and it has nothing to do with lock-up. </sidebar> I also have on my bottom panel the simple graphs showing disk activity and CPU load. These are available as widget under KDE. I'm sure there are similar for other desktops. Yes, I can run application like Darktable that do heavy image rendering and eat memory and CPU ('cos I don't have a $4,000 GPU), but what over-heats then is my cooking pan as I make dinner waiting for the rendering to finish. No lock-up. DT is nice about that :-) For a kernel to lock up there has to be a flaw in the kernel that is triggered by some event; a peripheral asynchronous event or a as a result of a user space activity. Yes, I'm stating the bleeding obvious. My inclination is to blame the the too-smart-for-their-own-good buqqers at Mozilla for something in Firefox. No wait, it might be an idiot plug-in coder assumes about the API that those too-smart-for-their-own-good buqqers at Mozilla claim to have put in there. What's your theory on why it crashes? If you don't think it is triggered by an application then what? Are you bothering to metricate your system with the widget that KDE lets you put in your panel, with the other tools and log mechanisms? -- If you can read this, we wasted 32 billion bucks. -- bumper sticker on stealth bomber -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 28.07.20 um 21:23 schrieb Markus Kolb:
Hi,
the July patches in kernel-default-5.3.18-lp152.33.1.x86_64 has here introduced a problem with hard lockups. No logging about the problem.
Does anyone see the same crashing with the new kernel package?
kernel-default-5.3.18-lp152.26.2.x86_64 works.
Thanks Markus
Hi, yesterday I got once a kernel panic after wakeup from Suspend to RAM. Otherwise no problems until now. Hendrik -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 7/28/20 2:23 PM, Markus Kolb wrote:
the July patches in kernel-default-5.3.18-lp152.33.1.x86_64 has here introduced a problem with hard lockups. No logging about the problem.
Hmm, my system crashed around 2 hours ago. I had last booted on Monday, 7 am Chicago time, and logged into a KDE/Wayland session. I could not find anything logged that was relevant to the crash. I do remember what I was last doing before the crash. I had just updated Tumbleweed running in a KVM virtual machine. I did the update in an "icewm" session. And then I did a reboot from the "icewm" menu. And everything froze. Not just the virtual machine -- everything. After a few minutes, it rebooted. I logged into a KDE/X11 session (because Wayland is not ready for prime time). I started virt-manager. It showed the virtual-machine as "Shutoff". So maybe it actually managed to shutdown, though I did not see that happen. I also did not see signs of an unclean shutdown for the virtual machine. It is probably just coincidence that the main system crashed at the time the virtual machine was shutting down. I'm still running 5.3.18-lp152.33-default, but if I have another crash I will revert to the previous kernel. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 28.07.2020 21:23, schrieb Markus Kolb:
Hi,
the July patches in kernel-default-5.3.18-lp152.33.1.x86_64 has here introduced a problem with hard lockups. No logging about the problem.
Does anyone see the same crashing with the new kernel package?
kernel-default-5.3.18-lp152.26.2.x86_64 works.
I've created a bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1174737 The curiosity is, that when enabling kdump to collect a crash dump, the kernel doesn't crash any longer. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (7)
-
Anton Aylward -
Carlos E. R. -
Carlos E.R.
-
David C. Rankin -
Hendrik Woltersdorf -
Markus Kolb -
Neil Rickert