LINUX.ORG.RU

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

 , ,


1

2

В драйвер ACPI CPU внесена регрессия, которая попала в ядра версий 5.15.35, 5.16.11, 5.17 и не исправлена в этих ветках по сей день.

Проблема приводит к спонтанным зависаниям на 32-битных процессорах (отмечены на Pentium 3 / Pentium M / VIA C7).

Ошибка внесена патчем ACPI: processor idle: Allow playing dead in C3 state, устранена ACPI: processor: idle: Avoid falling back to C3 type C-states, который пока вошел только в 5.18-rc5.

★★★★★

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


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

Sylvia ★★★★★
()


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/

gag ★★★★★
()
Ответ на: комментарий от Sylvia

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

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

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

Pinkbyte ★★★★★
()

устранена

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. Это говнокод, господа. И много там такого?

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

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

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

Sylvia ★★★★★
()
Ответ на: комментарий от ox55ff

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

ValdikSS ★★★★★
() автор топика
Ответ на: комментарий от ox55ff

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

gremlin_the_red ★★★★★
()
Последнее исправление: gremlin_the_red (всего исправлений: 1)
Ответ на: комментарий от gremlin_the_red

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

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

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

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

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

gremlin_the_red ★★★★★
()
Ответ на: комментарий от gremlin_the_red

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

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

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

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

state->enter_dead = acpi_idle_play_dead;

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

gag ★★★★★
()
Ответ на: комментарий от gag

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

alegz ★★★★
()

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

realbarmaley ★★
()
Ответ на: комментарий от realbarmaley

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

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

firkax ★★★★★
()
Ответ на: комментарий от ox55ff

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

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

firkax ★★★★★
()

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

ValdikSS ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.