LINUX.ORG.RU
решено Форум — General  

Вечный сон на 3.17.3

 , ,


0

1

Приветствую!

17.11 прилетело обновление ядра 3.17.3 и после этого машина перестала просыпаться. Откатил на 3.17.2 и все заработало нормально.
Далее нашел баг репорт, где отписался про свою проблему и проголосовал.
https://bugs.archlinux.org/task/42820

Проблема возникает только на i686.
Сегодня еще нашел другой баг репорт https://bugzilla.kernel.org/show_bug.cgi?id=88391, уже на kernel.org. И там просят:

Regression from v3.17.2->v3.17.3 for i386 edition
Can you please do a git bisect to find the offending commit?

Собственно неясно где и что с чем сравнивать, чел что сделал баг репорт тоже не в курсе :)
Насколько я понял репа арча есть на https://projects.archlinux.org

Далее я нашел https://projects.archlinux.org/svntogit/packages.git/commit/?h=packages/linux...

Но я понятия не имею верно ли я смотрю.
Собственно, как правильно делать регрессии?

П.С. Опыта в ядре ноль

★★★★

Последнее исправление: cetjs2 (всего исправлений: 2)
← 4Tb-диск и Centos 5.6
Что-то грузит HDD и CPU веб-сервера. В чём не прав? →

ну он же попросил сделать бисект

допустим у тебя версия 16 глючит, а 4 - не глючит. Значит баг нужно искать в промежутке от 4 до 16 версии.

4+(16-4)/2 = 4+6 = 10. Версия 10 находится ровно посередине между 4 и 16. Откатываешься гитом до версии 10, собираешь бинарник, и смотришь, глючит или нет.

допустим не глючит. Тогда надо искать в промежутке от 10 до 16. 10+(16-10)/2=13. Проверяем версию 13. Повторяем так до тех пор, пока не найдем ту версию, на которой прилетел баг.

в гите для этого вроде специальная команда есть :)

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

Ну тут же все просто с этим, версия 3.17.3 глючит, версия 3.17.2 работает.
Я правильно понял, что делаем бисект, компилим ядро, и если все нормально продолжаем двигаться ближе к 3.17.3. Но ядро придется на каждый бисект заново компилить?

в гите для этого вроде специальная команда есть :)

Ага, раньше не приходилось использовать.
Надеялся обойтись онлайновым просмотром, чтобы не чекаутить себе

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

Но ядро придется на каждый бисект заново компилить?

не шарю в ядре. наверное, да.

учитывая природу бисекта, таких сборок должно быть совсем немного. Надо не просто «продолжать двигаться ближе к», а постоянно делить рассматриваемый отрезок на 2.

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

Надеялся обойтись онлайновым просмотром, чтобы не чекаутить себе

Не, чтобы бисектить, придётся много раз чекаутить и много раз собирать :)

Между 3.17.2 и 3.17.3 находится 320 ревизий, следовательно, тебе придётся сделать ceil(log2(320)) = 9 пересборок ядра.

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

я бы посмотрел сначала только то, что x86. Без учета kvm - таких всего 7. Одно изних относится к ACPI и x86

IMHO если смотреть, то эти 

ACPI / EC: Fix regression due to conflicting firmware behavior between Samsung and Acer.	Lv Zheng	1	-7/+18
ACPI, irq, x86: Return IRQ instead of GSI in mp_register_gsi()	Jiang Liu	1	-1/+1
x86: ACPI: Do not translate GSI number if IOAPIC is disabled	Jiang Liu	1	-5/+9
ACPI: invoke acpi_device_wakeup() with correct parameters

vel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← 4Tb-диск и Centos 5.6
General
Что-то грузит HDD и CPU веб-сервера. В чём не прав? →