[SOLVED] Occasional system freeze after the latest update in Slackware64 --curent

ricky_cardo · 12-31-2020, 11:10 AM

Quote:

Originally Posted by GazL

10.5.4 just crashed on me. Was scrolling a page in firefox using the mouse scroll-wheel at the time. Mouse pointer still moves from both external usb mouse, and laptop clickpad, but X11 completely locked up, xclock window not updating time, keyboard (including capslock led indicator unresponsive) but magic-sysrq still allowed me to REISUB to reboot.

Gone back to 5.9.

The magic-sysrq good call if I see it again. (better than ssh in from another machine, for me). My symptom is very much like what you describe can move the mouse but keys non-resposive. Still going ok since new version Firefox. (though not saying that is the cause)

Could someone describe the moving files way to trigger the freeze a little more? You talking 2 thunar windows and moving files between them?
- I did some 7zip compress and uncompress "cat /dev/urandom | base64 > garbage_file.tst" then p7zip to try to load CPU while doing things but it did not cause issue yet.

****** 12-31-2020 16:18 Freeze again (shoot) was watching youtube on firefox... (so rebuild did not help) I could not get CTRL-ALT-SysRq to reboot (but never used it before so thinking PEBCAC)
when I ssh'd into the box it was showing 99% cpu util in htop for Xorg

Andersen · 12-31-2020, 10:31 PM

Mesa has just been upgraded, I don't know if it could help, but I'll give it a try.

Quote:

Thu Dec 31 20:42:33 UTC 2020
a/glibc-zoneinfo-2020f-noarch-1.txz: Upgraded.
This package provides the latest timezone updates.
ap/inxi-20201217_df45e6d4-noarch-1.txz: Upgraded.
ap/neofetch-20201126_6dd85d6-noarch-1.txz: Upgraded.
n/getmail-6.12-x86_64-1.txz: Upgraded.
n/mutt-2.0.4-x86_64-1.txz: Upgraded.
n/wget-1.21-x86_64-1.txz: Upgraded.
x/mesa-20.3.2-x86_64-1.txz: Upgraded.

edit:
nope.. and it took only a couple of minutes this time.

GazL · 01-01-2021, 04:32 AM

Quote:

Originally Posted by ricky_cardo

I could not get CTRL-ALT-SysRq to reboot (but never used it before so thinking PEBCAC)

To use magic-sysrq to reboot:

Hold down alt-gr and press and release sysrq. While continuing to hold alt-gr press and release R E I S U B keys in that order. I recommend a short pause between each key to give the kernel time to do its thing at each step.

FTIO · 01-01-2021, 08:43 AM

Quote:

Originally Posted by ricky_cardo

Could someone describe the moving files way to trigger the freeze a little more? You talking 2 thunar windows and moving files between them?

When it crashes krusader (or konqueror) as I'm moving files, in either of those I *always* set up the preferences for a two-pane window so that I can be in each directory at one time (I think that makes sense, heh)...I simply am right-clicking on a file in the one directory and choosing to 'move' it to the other directory and as soon as I click 'move', the program crashes. The system still stays up, just the programs krusader and konqueror (I didn't try any other file managers). I also tried to just moving a file by holding it with the mouse and dragging it over to the other pane/directory...same thing, it crashed the program.

ricky_cardo · 01-02-2021, 09:43 AM

Wow all this time I have not used Krusader, I was able to move files back and forth between the two windows, right clicking. (did you get as far as the popup window asking for new name if desired?)
I was a dolphin, then thunar man

One huge variant is I am using i3 and not KDE. I'm going to switch to KDE and see what happens there.
- I've got the intel i915 story here btw (not nvidia nor ati)

--Seems ok in KDE as well no crash(wow kde is fancy now, I did see the effect where background got dimmer when popup for rename appeared.)

garpu · 01-02-2021, 10:23 AM

Quote:

Originally Posted by GazL

To use magic-sysrq to reboot:

Hold down alt-gr and press and release sysrq. While continuing to hold alt-gr press and release R E I S U B keys in that order. I recommend a short pause between each key to give the kernel time to do its thing at each step.

Don't you have to hold down alt, sysrq, and the key? Granted, I've only ever used REISUB twice.

GazL · 01-02-2021, 11:35 AM

Quote:

Originally Posted by garpu

Don't you have to hold down alt, sysrq, and the key? Granted, I've only ever used REISUB twice.

Not in my experience, no. The way it seems to work is that once you've pressed alt-gr sysrq, the keyboard driver stays in sysrq mode until you release alt-gr,

algr-sysrq r k is often enough to unhang a hung X11, and will allow you to ctrl-alt-f1 back to a console login, but when my system encounters this particular hang, that doesn't work, which suggests that the hang is at a very low level in the stack, in the virtual console/framebuffer itself or the low level gfx card drivers. Forcing a reboot with REISUB is the only choice at that point.

Unfortunately, the hangs are completely random here. I might get one 3 hours after a boot, or I might not get one that entire day. It's very hard to try an diagnose by swapping things in/out, or trying to bisect when its that intermittent.

Paulo2 · 01-02-2021, 01:05 PM

5.10.4 crashed here too in a X session. Firefox wasn't running as some other reports.
X and keyboard were completely frozen, only mouse pointer was alive.
I tried to login through ssh but it didn't connect.

This was totally unexpected since I'm running nouveau, and with that driver the system
is (was) rock solid. So I'm blaming the kernel.

Another problem I had was returning from hibernation.
With nouveau the system never had any problem, and some days ago,
a few seconds after returning from hibernation the system crashed too,
it was a previous kernel 5.10.3 or 5.10.2.

I'm running 5.9.16 now, IIRC 5.9.x was stable as 5.4.x.

qunying · 01-02-2021, 06:24 PM

I have encounter several times when screen saver could not get back (my screen saver is set to blank only and display power management is set to standby after 5 minutes, suspend after 6 minutes and off after 7 minutes ) and Xorg is in D state.

1352 is my Xorg process.

Code:

cat /proc/1352/stack
[<0>] sync_eld_via_acomp+0x3f/0x2e0 [snd_hda_codec_hdmi]
[<0>] check_presence_and_report+0x57/0x80 [snd_hda_codec_hdmi]
[<0>] intel_audio_codec_enable+0x12a/0x1a0 [i915]
[<0>] intel_enable_ddi+0x445/0x5a0 [i915]
[<0>] intel_encoders_enable+0x80/0xa0 [i915]
[<0>] hsw_crtc_enable+0x1ca/0x5d0 [i915]
[<0>] intel_enable_crtc+0x53/0x60 [i915]
[<0>] skl_commit_modeset_enables+0x25f/0x540 [i915]
[<0>] intel_atomic_commit_tail+0x30e/0x12c0 [i915]
[<0>] intel_atomic_commit+0x333/0x3b0 [i915]
[<0>] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper]
[<0>] drm_mode_setcrtc+0x1d3/0x6f0 [drm]
[<0>] drm_ioctl_kernel+0xaa/0xf0 [drm]
[<0>] drm_ioctl+0x20f/0x3a0 [drm]
[<0>] __x64_sys_ioctl+0x83/0xb0
[<0>] do_syscall_64+0x33/0x80
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Code:

echo w > /proc/sysrq-trigger; dmesg
[ 9479.067593] task:Xorg            state:D stack:    0 pid: 1352 ppid:  1351 flags:0x00404004
[ 9479.067597] Call Trace:
[ 9479.067601]  __schedule+0x207/0x810
[ 9479.067603]  schedule+0x46/0xb0
[ 9479.067606]  schedule_preempt_disabled+0xa/0x10
[ 9479.067608]  __mutex_lock.constprop.0+0x24b/0x490
[ 9479.067646]  ? fwtable_write32+0x4c/0x230 [i915]
[ 9479.067666]  sync_eld_via_acomp+0x3f/0x2e0 [snd_hda_codec_hdmi]
[ 9479.067671]  check_presence_and_report+0x57/0x80 [snd_hda_codec_hdmi]
[ 9479.067717]  intel_audio_codec_enable+0x12a/0x1a0 [i915]
[ 9479.067769]  intel_enable_ddi+0x445/0x5a0 [i915]
[ 9479.067822]  intel_encoders_enable+0x80/0xa0 [i915]
[ 9479.067874]  hsw_crtc_enable+0x1ca/0x5d0 [i915]
[ 9479.067926]  intel_enable_crtc+0x53/0x60 [i915]
[ 9479.067978]  skl_commit_modeset_enables+0x25f/0x540 [i915]
[ 9479.068029]  intel_atomic_commit_tail+0x30e/0x12c0 [i915]
[ 9479.068050]  ? complete+0x2f/0x40
[ 9479.068052]  ? flush_workqueue_prep_pwqs+0x119/0x130
[ 9479.068054]  ? flush_workqueue+0x178/0x3c0
[ 9479.068103]  intel_atomic_commit+0x333/0x3b0 [i915]
[ 9479.068115]  drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper]
[ 9479.068135]  drm_mode_setcrtc+0x1d3/0x6f0 [drm]
[ 9479.068156]  ? touch_atime+0xcf/0x140
[ 9479.068172]  ? drm_mode_getcrtc+0x180/0x180 [drm]
[ 9479.068201]  drm_ioctl_kernel+0xaa/0xf0 [drm]
[ 9479.068221]  drm_ioctl+0x20f/0x3a0 [drm]
[ 9479.068254]  ? drm_mode_getcrtc+0x180/0x180 [drm]
[ 9479.068278]  ? vfs_read+0x150/0x180
[ 9479.068281]  __x64_sys_ioctl+0x83/0xb0
[ 9479.068284]  do_syscall_64+0x33/0x80
[ 9479.068286]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 9479.068289] RIP: 0033:0x7f7a8e2a0417
[ 9479.068290] RSP: 002b:00007ffda36507d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 9479.068309] RAX: ffffffffffffffda RBX: 00007ffda3650820 RCX: 00007f7a8e2a0417
[ 9479.068312] RDX: 00007ffda3650820 RSI: 00000000c06864a2 RDI: 0000000000000010
[ 9479.068314] RBP: 00000000c06864a2 R08: 00000000013d9750 R09: 0000000000000000
[ 9479.068316] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000013d9b10

colorpurple21859 · 01-02-2021, 09:05 PM

I get a lockup with 5.10 kernel with slackware64-current as a guest in vbox while compiling a kernel when "make_modules install" is invoked. Vbox locks up to the point it won't release the keyboard or touchpad back to the ubuntu desktop(host) The guest is only console, no xorg running. With the 5.4.84 kernel no lock up. A install to bare metal on same machine doesn't lock up.

edit: The vboxvga graphics controller was causing the crash. When I changed to vmsvga no crashes. I wonder why the 5.10 crashes with the vboxvga and the 5.4.84 doesn't.

qunying · 01-04-2021, 02:04 PM

5.10.4 just freeze the Xorg on me:

Code:

1304 root      20   0  685756 111624  89452 D  96.3   0.7   8:16.90 Xorg


cat /proc/1304/stack
[<0>] rcu_barrier+0x16a/0x1f0
[<0>] i915_gem_object_unbind+0x252/0x360 [i915]
[<0>] i915_gem_set_caching_ioctl+0x149/0x190 [i915]
[<0>] drm_ioctl_kernel+0xaa/0xf0 [drm]
[<0>] drm_ioctl+0x20f/0x3a0 [drm]
[<0>] __x64_sys_ioctl+0x83/0xb0
[<0>] do_syscall_64+0x33/0x80
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

echo "w"  > /proc/sysrq-trigger; dmesg
[ 6343.909870] Workqueue: events_highpri intel_atomic_cleanup_work [i915]
[ 6343.909872] Call Trace:
[ 6343.909876]  __schedule+0x207/0x810
[ 6343.909879]  schedule+0x46/0xb0
[ 6343.909881]  schedule_preempt_disabled+0xa/0x10
[ 6343.909884]  __ww_mutex_lock.constprop.0+0x2f9/0x760
[ 6343.909886]  ? sched_clock_local+0x60/0x80
[ 6343.909933]  intel_unpin_fb_vma+0x25/0xa0 [i915]
[ 6343.909946]  drm_atomic_helper_cleanup_planes+0x52/0x70 [drm_kms_helper]
[ 6343.909990]  intel_atomic_cleanup_work+0x67/0x110 [i915]
[ 6343.909993]  process_one_work+0x1d4/0x370
[ 6343.909995]  worker_thread+0x4d/0x3d0
[ 6343.909997]  ? rescuer_thread+0x3d0/0x3d0
[ 6343.909999]  kthread+0x11b/0x140
[ 6343.910001]  ? __kthread_bind_mask+0x60/0x60
[ 6343.910003]  ret_from_fork+0x22/0x30

baumei · 01-04-2021, 02:59 PM

I wonder whether the software work-arounds in the kernel for Meltdown, Spectre, and cousins have anything to do with the locking-up and other poor behavior.

My understanding is the Intel firmware patches to 'fix' the Meltdown-Spectre-&cousins problem, radically change the behavior of the Intel processor. I am wondering whether the 5.10.y series of kernels only work nicely with some versions of the Intel firmware patches.

Have any of you been comparing notes regarding the specific version of the Intel firmware patch which is running when the locking-up and other poor behavior occurs?

montagdude · 01-04-2021, 03:20 PM

Quote:

Originally Posted by qunying

I have encounter several times when screen saver could not get back (my screen saver is set to blank only and display power management is set to standby after 5 minutes, suspend after 6 minutes and off after 7 minutes ) and Xorg is in D state.

1352 is my Xorg process.

Code:

cat /proc/1352/stack
[<0>] sync_eld_via_acomp+0x3f/0x2e0 [snd_hda_codec_hdmi]
[<0>] check_presence_and_report+0x57/0x80 [snd_hda_codec_hdmi]
[<0>] intel_audio_codec_enable+0x12a/0x1a0 [i915]
[<0>] intel_enable_ddi+0x445/0x5a0 [i915]
[<0>] intel_encoders_enable+0x80/0xa0 [i915]
[<0>] hsw_crtc_enable+0x1ca/0x5d0 [i915]
[<0>] intel_enable_crtc+0x53/0x60 [i915]
[<0>] skl_commit_modeset_enables+0x25f/0x540 [i915]
[<0>] intel_atomic_commit_tail+0x30e/0x12c0 [i915]
[<0>] intel_atomic_commit+0x333/0x3b0 [i915]
[<0>] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper]
[<0>] drm_mode_setcrtc+0x1d3/0x6f0 [drm]
[<0>] drm_ioctl_kernel+0xaa/0xf0 [drm]
[<0>] drm_ioctl+0x20f/0x3a0 [drm]
[<0>] __x64_sys_ioctl+0x83/0xb0
[<0>] do_syscall_64+0x33/0x80
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Code:

echo w > /proc/sysrq-trigger; dmesg
[ 9479.067593] task:Xorg            state:D stack:    0 pid: 1352 ppid:  1351 flags:0x00404004
[ 9479.067597] Call Trace:
[ 9479.067601]  __schedule+0x207/0x810
[ 9479.067603]  schedule+0x46/0xb0
[ 9479.067606]  schedule_preempt_disabled+0xa/0x10
[ 9479.067608]  __mutex_lock.constprop.0+0x24b/0x490
[ 9479.067646]  ? fwtable_write32+0x4c/0x230 [i915]
[ 9479.067666]  sync_eld_via_acomp+0x3f/0x2e0 [snd_hda_codec_hdmi]
[ 9479.067671]  check_presence_and_report+0x57/0x80 [snd_hda_codec_hdmi]
[ 9479.067717]  intel_audio_codec_enable+0x12a/0x1a0 [i915]
[ 9479.067769]  intel_enable_ddi+0x445/0x5a0 [i915]
[ 9479.067822]  intel_encoders_enable+0x80/0xa0 [i915]
[ 9479.067874]  hsw_crtc_enable+0x1ca/0x5d0 [i915]
[ 9479.067926]  intel_enable_crtc+0x53/0x60 [i915]
[ 9479.067978]  skl_commit_modeset_enables+0x25f/0x540 [i915]
[ 9479.068029]  intel_atomic_commit_tail+0x30e/0x12c0 [i915]
[ 9479.068050]  ? complete+0x2f/0x40
[ 9479.068052]  ? flush_workqueue_prep_pwqs+0x119/0x130
[ 9479.068054]  ? flush_workqueue+0x178/0x3c0
[ 9479.068103]  intel_atomic_commit+0x333/0x3b0 [i915]
[ 9479.068115]  drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper]
[ 9479.068135]  drm_mode_setcrtc+0x1d3/0x6f0 [drm]
[ 9479.068156]  ? touch_atime+0xcf/0x140
[ 9479.068172]  ? drm_mode_getcrtc+0x180/0x180 [drm]
[ 9479.068201]  drm_ioctl_kernel+0xaa/0xf0 [drm]
[ 9479.068221]  drm_ioctl+0x20f/0x3a0 [drm]
[ 9479.068254]  ? drm_mode_getcrtc+0x180/0x180 [drm]
[ 9479.068278]  ? vfs_read+0x150/0x180
[ 9479.068281]  __x64_sys_ioctl+0x83/0xb0
[ 9479.068284]  do_syscall_64+0x33/0x80
[ 9479.068286]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 9479.068289] RIP: 0033:0x7f7a8e2a0417
[ 9479.068290] RSP: 002b:00007ffda36507d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 9479.068309] RAX: ffffffffffffffda RBX: 00007ffda3650820 RCX: 00007f7a8e2a0417
[ 9479.068312] RDX: 00007ffda3650820 RSI: 00000000c06864a2 RDI: 0000000000000010
[ 9479.068314] RBP: 00000000c06864a2 R08: 00000000013d9750 R09: 0000000000000000
[ 9479.068316] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000013d9b10

Sounds possibly similar to what I'm seeing. I've returned to my system twice today to find it unresponsive, with the screen black. Had to do a hard reboot. I'm also on 5.10.4 but haven't had any problems until today. This is also my first day returning to work and using a dual monitor setup, in case that has anything to do with it.

Petri Kaukasoina · 01-04-2021, 03:27 PM

Quote:

Originally Posted by qunying

Code:

cat /proc/1352/stack
[<0>] sync_eld_via_acomp+0x3f/0x2e0 [snd_hda_codec_hdmi]
[<0>] check_presence_and_report+0x57/0x80 [snd_hda_codec_hdmi]
...

Please try this. Create a file /etc/modprobe.d/snd_hda.conf like this

Code:

# /etc/modprobe.d/snd_hda.conf
options snd_hda_codec_hdmi enable_silent_stream=N

and then reboot to 5.10.4.

qunying · 01-05-2021, 11:15 AM

Thanks Petri, I have not test that, but since I disable the display power management, it does not freeze on me when coming back from screen saver.

The other freeze trigger by firefox or chrome has no solution yet.