PSA: 32-битные процессоры зависают на 5.15.35, 5.16.11, 5.17.

даже не удивительно,
мало кто пытается тестировать новый софт на старом железе.


Я тут сравнительно недавно отловила баг в openssh на 32-битных системах, очень удивилась что никто.. реально никто не чесался,
хотя вообще-то там еще и ARM задет.

…
R. J. W.: Or IOW how likely is this change to break anything on legacy platforms?
…
L. L.: Found the original patch thread, unfortunately there is no discussion on why C3 was skipped or not allowed
…
L. L.: Do you recall why C3 was not considered for offline/play dead scenarios in the original patch?
…
B.O.: Not really. Perhaps processors from that time (at least AMD ones) did not support C3?
…
R.J. W.: I guess the only way to find out is to try it and see then.

(22-29 сентября 2021)

https://lore.kernel.org/linux-acpi/20210922133116.102-1-richard.gong@amd.com/t/

вообще-то там еще и ARM задет

Ну так ARMv8 уже тоже не прям новье. А он однако 64-битный :-)

32-бит всё больше и больше переходит из разряда легаси в разряд дремучего легаси. Что печально конечно, но, увы, неизбежно

32-битных процессорах

Где они их нашли, а главное зачем?

устранена

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 4556c86c34659..5f296e099bce0 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -795,7 +795,8 @@ static int acpi_processor_setup_cstates(struct acpi_processor *pr)
 		if (cx->type == ACPI_STATE_C1 || cx->type == ACPI_STATE_C2 ||
 		    cx->type == ACPI_STATE_C3) {
 			state->enter_dead = acpi_idle_play_dead;
-			drv->safe_state_index = count;
+			if (cx->type != ACPI_STATE_C3)
+				drv->safe_state_index = count;
 		}
 		/*
 		 * Halt-induced C1 is not good for ->enter_s2idle, because it

Сначала в if проверяем, что cx->type == ACPI_STATE_C3, а потом внутри этого if проверяем обратное cx->type != ACPI_STATE_C3. Это говнокод, господа. И много там такого?

я знаю одно место где есть P4 Northwood, на нем 4 гига памяти
вполне работает, xUbuntu

Когда-то (очень давно) это был мой домашний комп )

Проблему обнаружил и забисектил я, потом уже понял, что она устранена. Тонкий клиент с VIA C7 начал зависать на новых ядрах.

Ммм. Мусье не знает си? Там || обозначает логическое «или», если что.

А, главное, нафига туда вкорячили новые ядра, хотя для этого старья есть проект с поддержкой ядра 4.4 до 2036 года.

Мусье знает что обозначает логическое или. Проблема в том, что код сначала требует ACPI_STATE_C3, а потом исключает его. Работать будет правильно, но выглядит не логично => говнокод. Ревью не должно пропустить.

Этот патч выглядит как костыль. Просто вонзили условие и насрать как это выглядит в целом. Со временем от таких патчей код превратиться в лапшу.

Проблема в том, что код сначала требует ACPI_STATE_C3

Но он не требует. «C1 или C2 или C3». И только в случае «C1 или C2, но не C3» появляется дополнительное действие.

«или или», внутри которого корявый «или, но не» как бы намекает, что C3 должен обрабатывать отдельный блок кода. [С1, C2] и [С3] обрабатывать раздельно раз уж они разные.

обрабатывать раздельно раз уж они разные

Не совсем. Основная цель этого кусочка кода у них одинаковая:

state->enter_dead = acpi_idle_play_dead;

Дублировать такой код нельзя, поэтому выбрали дополнительный вложенный if для кое-какого дополнительного исключения.

Вообще-то это идеальный случай для switch с fallthrough, но есть особо одарённые, которые и такое посчитают «говнокодом», особенно в ядре.

Это саботаж.

А кто знает, как вообще ядро дебажить? Типа если kernel panic, что делать? Все логи на экране не видны же

netconsole/pstore/ramoops.

crashdump можно смотреть

ну и не знаю как в линуксе а в freebsd в ядре есть встроенный отладчик, который запускается (в ядерной консоли) при панике, если ядро собрано с ним (остальная работа ОС, включая весь юзерспейс, при этом разумеется останавливается)

Это говнокод, господа. И много там такого?

Это «linux-way» в разработке. Соответственно он там везде. В ответственных местах надо использовать только настоящие юниксы, например бсд.

Не первый раз, кстати, 32-bit only bug.

Исправлено в 5.15.38, 5.17.6.