Bug soft lockup linux

watchdog: BUG: soft lockup — CPU#0 stuck for 23!

ACER A315-41-R8X. BIOS 1.13

AMD Ryzen 5 2500U Mobile Processor with Radeon Vega 8 Graphics

BUG при загрузке/установке linux, останавливающий загрузку:

Временное решение прописать noapic в grub

Какая версия ядра?

5.0 — наверное, было самое новое, что пробовал (в Ubuntu 19.04).

• выруби secure boot
• пробуй дописать nomodeset и/или acpi=off и/или pci=noacpi в параметры загрузки ядра

но вообще с такими вопросами куда результативнее обращаться в поддержку Acer и AMD

а чтобы не попадать в такие ситуации изначально, имеет смысл выбирать девайс, ориентируясь на https://certification.ubuntu.com/desktop/models/?release=18.04%20LTS&category=Laptop

В acer мне ответили, что не занимаются поддержкой opensource и установкой OS (почти дословно). Наверное, поэтому ноутбуков acer и нет на этом сайте. Хотя сайт полезный, спасибо.

Занятное ещё то, что сам ноут шёл с дистрибутивом linpus. Напишу им тоже и в amd, может однозначно ответят. Так как ошибка очень популярная. Но, к сожалению, пока те решения которые помогли другим, мне не помогли.

Источник

Чьи глюки? BUG: soft lockup — CPU#0 stuck for 61s! [swapper:0]

Периодически, если оставить ноут на ночь включённым, то он впадает в коматозное состояние. Не виснет полностью, ещё можно достучатся до X’го окна разблокировки хранителя экрана, но на этом дело и заканчивается. Приходится ресетить.

В логах полно вот таких вот сообщений:

======================= Jul 25 03:35:10 fobos BUG: soft lockup — CPU#0 stuck for 61s! [swapper:0] Jul 25 03:35:10 fobos Jul 25 03:35:10 fobos Pid: 0, comm: swapper Tainted: P (2.6.25-ARCH #1) Jul 25 03:35:10 fobos EIP: 0060:[ ] EFLAGS: 00000282 CPU: 0 Jul 25 03:35:10 fobos EIP is at _spin_unlock_irqrestore+0x6/0x30 Jul 25 03:35:10 fobos EAX: 00000282 EBX: 00000001 ECX: fffff000 EDX: 00000282 Jul 25 03:35:10 fobos ESI: ffffffff EDI: dad72808 EBP: 00000000 ESP: c03bdf20 Jul 25 03:35:10 fobos DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Jul 25 03:35:10 fobos CR0: 8005003b CR2: bfd59094 CR3: 1adc4000 CR4: 000006d0 Jul 25 03:35:10 fobos DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 Jul 25 03:35:10 fobos DR6: ffff0ff0 DR7: 00000400 Jul 25 03:35:10 fobos [ ] tick_notify+0x275/0x3b0 Jul 25 03:35:10 fobos [ ] notifier_call_chain+0x36/0x70 Jul 25 03:35:10 fobos [ ] raw_notifier_call_chain+0x17/0x20 Jul 25 03:35:10 fobos [ ] clockevents_notify+0x1e/0x70 Jul 25 03:35:10 fobos [ ] acpi_idle_enter_simple+0x1c7/0x21e [processor] Jul 25 03:35:10 fobos [ ] pm_qos_requirement+0x23/0x30 Jul 25 03:35:10 fobos [ ] cpuidle_idle_call+0x73/0xd0 Jul 25 03:35:10 fobos [ ] cpuidle_idle_call+0x0/0xd0 Jul 25 03:35:10 fobos [ ] cpu_idle+0x65/0x110 Jul 25 03:35:10 fobos =======================

Кто может быть источиком неприятностей? Железл — Dell inspiron 1501 (Sempron Mobile 3500+, видяха ati RS485 [Radeon Xpress 1100 IGP]).

Источник

watchdog: BUG: soft lockup — CPU#0 stuck for 22s! [swapper/0:0]

(Dual boot с 10 виндой)
Поставил вчера арч по инструкции, запустилось всё установил xfce, посидел чуток. Потом система намертво зависла, не работал ни Ctrl+Alt+Backspace ни Alt+PrintScreen R E I S U B не помогло, ребутнулся кнопкой на компе.
Запустил опять, всё ок, спустя время опять тоже самое, перезагрузил, ввёл пароль оно опять залагало. Ребутнулся снова но теперь уже просто мигал курсор.
Снёс арч, решил поставить манжару, там при запуске выписало , забил.

Сегодня опять арч поставил, прошла установка, всё отлично. Ребутнулся уже в систему написал пошла загрузка, и тут мне вылезло это ждал, ничего, нажал Ctrl+C написал мне выбило что не установлено ничего, снова попробовал скачать, вылетела туча ошибок типа *файл* пуст, потом попытался скачать lightdm вышло тоже самое.

Как быть, что делать? Хотелось арч второй системой поставить, но тут такая дичь. Был установлен Дебиан, на нём тоже были подобные лаги как в начале написанного, но после переустановки всё было ок.

# 8 месяцев, 3 недели назад (отредактировано 8 месяцев, 3 недели назад) какое железо,проц,видеокарта?может сильно старое или слишком новое?
может ядро lts надо поставить.в общем напиши какое железо.
вот еще

CPU: AMD Athlon II X2 250 (2 ядра 3гц)
GPU: GT 710 DDR3 1gb
ОЗУ: 6 гб DDR3

Комп старый, но дело в том что до этого я уже ставил ту же манжару всё было окей, а сейчас не пашет.

Рекомендую не лениться и по гуглить, чтобы понять саму причину этих логов …

heylc
watchdog: BUG: soft lockup — CPU#0 stuck for 22s!

heylc
Alt+PrintScreen R E I S U B не помогло

Источник

BUG: soft lockup — CPU# stuck for 22s! [z_wr_iss] #7042

Comments

samuelbernardo commented Jan 13, 2018 •

System information

Type	Version/Name
Distribution Name	Gentoo
Distribution Version	—
Linux Kernel	4.14.12
Architecture	x86_64
ZFS Version	0.7.5
SPL Version	0.7.5

Describe the problem you’re observing

zfs thread lock after some intensive IO. It allows to continue to access data, but all writes won’t be commited to disk, since reboot needs ctrl+shift+sysreq reisub. It remains locked after trying soft reboot, and the only solution is a forced reboot with sysreq.
The zfs lock is registered systematically after some intensive IO on each OS reboot.

Describe how to reproduce the problem

This is the configuration of zfs volume that has the deadlock (using deduplication and lz4 compression):

NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zfs 21.8T 5.69T 16.1T — 6% 26% 1.07x ONLINE —
raidz1 10.9T 2.85T 8.03T — 6% 26%
ata-TOSHIBA_DT01ACA300_Z5RS6H0KS — — — — — —
ata-TOSHIBA_HDWD130_678KR5JAS — — — — — —
ata-TOSHIBA_DT01ACA300_16QUEEEKS — — — — — —
ata-TOSHIBA_HDWD130_678KPYLAS — — — — — —
raidz1 10.9T 2.85T 8.03T — 6% 26%
ata-TOSHIBA_HDWD130_678KTDUAS — — — — — —
ata-TOSHIBA_DT01ACA300_16QUDE3KS — — — — — —
ata-WDC_WD40EZRX-75SPEB0_WD-WCC4E2YAA98J-part6 — — — — — —
ata-TOSHIBA_HDWD130_678KPP7AS — — — — — —
cache — — — — — —
sdc 699G 79.7M 699G — 0% 0%
sde 699G 78.2M 699G — 0% 0%

pool: zfs
state: ONLINE
scan: resilvered 75.5G in 0h38m with 0 errors on Mon Oct 16 03:45:53 2017
config:
NAME STATE READ WRITE CKSUM
zfs ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-TOSHIBA_DT01ACA300_Z5RS6H0KS ONLINE 0 0 0
ata-TOSHIBA_HDWD130_678KR5JAS ONLINE 0 0 0
ata-TOSHIBA_DT01ACA300_16QUEEEKS ONLINE 0 0 0
ata-TOSHIBA_HDWD130_678KPYLAS ONLINE 0 0 0
raidz1-1 ONLINE 0 0 0
ata-TOSHIBA_HDWD130_678KTDUAS ONLINE 0 0 0
ata-TOSHIBA_DT01ACA300_16QUDE3KS ONLINE 0 0 0
ata-WDC_WD40EZRX-75SPEB0_WD-WCC4E2YAA98J-part6 ONLINE 0 0 0
ata-TOSHIBA_HDWD130_678KPP7AS ONLINE 0 0 0
cache
sdc ONLINE 0 0 0
sde ONLINE 0 0 0

capacity | operations | bandwidth | total_wait | disk_wait | syncq_wait | asyncq_wait | scrub

pool	alloc	free	read	write	read	write	read	write	read	write	read	write	read	write	wait
zfs	5.69T	16.1T	81	109	500K	950K	4us	1us	4us	543ns	187ns	2ns	1us	1us	723ns

Include any warning/errors/backtraces from the system logs

The text was updated successfully, but these errors were encountered:

array42-zz commented Jan 17, 2018 •

I see similar soft lockups, but with a different OS and and inside a vm. When you reboot, does it scrub? I see that it scrubs the fs and kill the complete linux system (running as vm) every time it does that. After that I can see no network and no disk activity, while high memory and continuous high cpu load on that virtual machine. So I just attach that observation to your report. Maybe you also have a scrub running while it happens? The load on the disk is already ‘too much’ when it boots and starts the services again. Only way to stop that is to cancel the scrub. But so I can’t ever scrub it. Well.
Also the backtraces are different depending on the other things the kernel does. Some are very clearly about zfs internals. Some are not.
Increasing the vcpu count does not change the situation.

samuelbernardo commented Jan 17, 2018 •

hi @array42
The failure that I reported seems to be related with an old issue #2708.

I didn’t verify if a scrub operation was going on during the lock. I suspect that the problem is related to a race condition in the access to data block maybe because of a metadata inconsistency because of a cache out of sync related issue. The reason I suspect about this is because the lock happens when accessing the same subvolume where I have ccache files (16GB and above a million files). This subvolume is using deduplication, lz4 compression and have sync disabled. The pool was created using zfs 0.6 with clonezilla ubuntu stable version in the last zfs crash, since I have subvolumes that are needed for the OS boot.

It also cloud be related to kernel 4.14 that is not mature enough and could help to achieve the race condition. I could boot the OS after forcelly restarting it and could write to zfs without any problem as long as the ccache subvolume is not used.

To solve the problem the only solution I found was to create the pool again, so the possible metadata inconsistency could be corrected. I could safeguard all data importing the pool in rescue mode from the clonezilla live cd. Than I copied all data for each subvolume.

I also have zfs fatal errors in previous 0.7 versions and when I try to run scrub it locked up when accessing the inconsistent files. Because this time I was with less available time I went immediately for the rescue and create operations.

samuelbernardo commented Jan 17, 2018 •

I forget to mention in last message that I’m using kernel 4.9.76 now and even after a very big build using ccache over the file system I couldn’t reproduce the same problem until now.

Let see if it’s a linux kernel related problem like it was in issue #2708:

h1z1 commented Jan 28, 2018

There are a few rather nasty regressions in newer kernels like https://marc.info/?l=linux-kernel&m=151638176727612&w=2

yuri-ccp commented Oct 23, 2018

I have the similar problem but with Kernel 3.10.0-714.10.2.lve1.5.19.7.el7.x86_64 from CloudLinux.

During the backup operation to another pool it’s hangs with CPU# stuck for 22s! [z_wr_iss] errors. I don’t have the same errors when I used the old 7.4 kernel, maybe I regression?

Harvie commented Jan 7, 2019 •

I have lockups on zfs 0.7.12 on 4.15.18-9-pve and 4.15.18-11-pve kernels

stale bot commented Aug 24, 2020

This issue has been automatically marked as «stale» because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

Harvie commented Aug 25, 2020

@h1z1 do you think it will be fixed by now?

plantroon commented Oct 24, 2020

This happened on:

4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux
ZFS on Linux 0.7.12

Is this possibly fixed on 0.8?

Were you using gzip compression by any chance?

morotti commented Mar 4, 2021

confirming the issue is present on ZFS 0.8.3

pquan commented Mar 22, 2021

This bug should not go stale. It is still present for zfs 0.8.5. I got it during a zfs receive from a FS with approximately 1.5GB of data. It has been impossible to sync this system for a week now. It locks up when arriving at around 680GB

Источник

Linux Mint Forums

Welcome to the Linux Mint forums!

Bug: soft lockup cpu#4 stuck[SOLVED]

Bug: soft lockup cpu#4 stuck[SOLVED]

Post by stovs » Mon Oct 10, 2016 10:56 pm

MSI GE72 apache pro (skylake board)
Nvidia gxt960m

Bios settings:
-boot UEFI with CSM
-Safe boot disabled

Any ideas anyone

EDIT: just seen how bad that pic is..one line reads

NMI watchdog: BUG: soft lockup — CPU#4 stuck for 22s ! [gpu manager:1496]

Re: Bug: soft lockup cpu#4 stuck

Post by deepakdeshp » Tue Oct 11, 2016 1:48 am

If I have helped you solve a problem, please add [ SOLVED] t o your first post title , it helps other users looking for help, and keeps the forum clean.
Regards,
Deepak

Mint 20.1 Cinnamon 64 bit with AMD A8/7410 / 8GB
Mint 20.1 Cinnamon AMD Ryzen3500U/8gb

Re: Bug: soft lockup cpu#4 stuck

Post by Laurent85 » Tue Oct 11, 2016 8:54 am

Re: Bug: soft lockup cpu#4 stuck

Post by stovs » Tue Oct 11, 2016 5:39 pm

I was looking at that before but cpu bit fooled me. Managed to get it installed atleast

Re: Bug: soft lockup cpu#4 stuck[SOLVED]

Post by lgandras » Thu Jul 20, 2017 3:58 pm

Re: Bug: soft lockup cpu#4 stuck[SOLVED]

Post by Neutrino » Fri Mar 02, 2018 6:33 pm

Re: Bug: soft lockup cpu#4 stuck[SOLVED]

Post by Mute Ant » Fri Mar 02, 2018 8:15 pm

Источник