Bug 4506 - Зависают процессы, работающие на Raid-Контроллере [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller
: Зависают процессы, работающие на Raid-Контроллере [AMD/ATI] SB7x0/SB8x0/SB9x0...
Status: UNCONFIRMED
Product: Desktop Bugs
Classification: ROSA Desktop
Component: Main Packages
: Fresh
: All Linux
: Normal normal
: ---
Assigned To: Eugene Shatokhin
: ROSA Linux Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-11 10:00 MSD by Yaroslav
Modified: 2016-01-19 21:30 MSK (History)
4 users (show)

See Also:
RPM Package: Kernel
ISO-related:
Bad POT generating:
Upstream:


Attachments
syslog (367.16 KB, text/plain)
2014-10-16 19:16 MSD, Yaroslav
Details
'ps aux' Logs, /proc/$PID/stat log (3.63 KB, application/gzip)
2014-10-18 10:48 MSD, Yaroslav
Details
dmesg 3.16.rc2 (95.15 KB, text/x-log)
2014-10-20 18:57 MSD, Yaroslav
Details
'ps aux' Logs, /proc/$PID/stat log, dmesg (94.36 KB, text/x-log)
2014-10-22 17:46 MSD, Yaroslav
Details
'ps aux' Logs, /proc/$PID/stat log, dmesg (94.26 KB, text/x-log)
2014-10-23 18:23 MSD, Yaroslav
Details
'ps aux' Logs, /proc/$PID/stat log, dmesg (95.63 KB, text/x-log)
2014-10-26 17:55 MSK, Yaroslav
Details
Logs from kernel 3.15 with debug (149.85 KB, application/gzip)
2014-10-27 21:28 MSK, Yaroslav
Details
'ps aux' Logs, /proc/$PID/stat log, dmesg (97.56 KB, text/x-log)
2014-10-28 19:41 MSK, Yaroslav
Details
'ps aux' Logs, /proc/$PID/stat log, dmesg (92.47 KB, text/x-log)
2014-10-29 17:11 MSK, Yaroslav
Details
Patch to enable smb_mb__*_atomic() (4.32 KB, patch)
2014-11-05 14:20 MSK, Eugene Shatokhin
Details
drakut install log (3.77 KB, text/plain)
2014-11-05 19:02 MSK, Yaroslav
Details
patch-smp-atomics-01.patch (92.20 KB, patch)
2014-11-07 13:03 MSK, Eugene Shatokhin
Details
dmesg log (93.61 KB, text/x-log)
2014-11-07 21:57 MSK, Yaroslav
Details
ps aux , dmesg (94.79 KB, text/x-log)
2014-11-10 21:50 MSK, Yaroslav
Details
ps aux , dmesg (92.76 KB, text/x-log)
2014-11-12 22:13 MSK, Yaroslav
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yaroslav 2014-10-11 10:00:47 MSD
Используется Raid-массив на контроллере
00:11.0 RAID bus controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [RAID5 mode] (rev 40)
в режиме зеркала.

На текущем ядре имеется проблема зависания операций при использовании этого массива.
Несколько файлов системе удается считать и записать, а потом процесс зависает. KDE-шный менеджер процессов для зависшего процесса, работающего на raid-массиве, говорит, что процесс "в ожидании на диске". Из-за этого портится ФС (в моем случае BTRFS и EXT4).
Проблема присутствует как на 64-хбитной системе, так и на 32-хбитной, в Live и установленном. На других (старых) ядрах (Rosa Fresh R3 с последними обновлениями, MagOS августовской сборки) этого не наблюдается.

Плюс присутствует проблема с тем, что raid-массивы становятся доступны только после монтирования корневой ФС.
Comment 1 Yaroslav 2014-10-11 18:10:24 MSD
Пока проблема выявлена на ядрах
kernel-nrj-desktop-3.14.15-1rosa-1-1-rosa2014.1.x86_64
kernel-nrj-desktop-3.15.9-1rosa-1-1-rosa2014.1.x86_64

На ядре kernel-desktop-devel-3.10.51-1rosa-1-1-rosa2012.1.x86_64 в Rosa Fresh R4 проблема не наблюдается.

В логах ошибок при зависании нет.
Comment 2 Yaroslav 2014-10-11 18:49:39 MSD
http://hw.rosalinux.ru/index.php?probe=61c2e36d21
Конфигурация ПК.
Comment 3 Yaroslav 2014-10-11 21:00:21 MSD
На ванильном 3.17 тоже работает все нормально.
(make oldconfig от конфига 3.15.9)
Comment 4 Eugene Shatokhin 2014-10-16 13:07:43 MSD
(In reply to comment #3)
> На ванильном 3.17 тоже работает все нормально.
> (make oldconfig от конфига 3.15.9)

Сейчас готовим обновление ядра до 3.14.22 - туда много исправлений по части RAID вошло. Когда выйдет, стоит проверить, останется ли проблема.
Comment 5 Eugene Shatokhin 2014-10-16 17:27:52 MSD
Проверьте, пожалуйста, проявляется ли проблема с зависанием на ядре 3.14.22. Взять его можно отсюда: 
http://abf-downloads.rosalinux.ru/rosa2014.1/container/2305846/x86_64/main/release/
Comment 6 Yaroslav 2014-10-16 19:16:54 MSD
Created attachment 3343 [details]
syslog

Не помогло. Зависло на 16 мегабайт чтения.

В аттаче лог при загрузки ядра 3.14.22 и затем 3.17 (извините, но я забл посмотреть на время, в которое была загрузка системы)
Comment 7 Eugene Shatokhin 2014-10-17 12:31:12 MSD
(In reply to comment #6)
> В аттаче лог при загрузки ядра 3.14.22 и затем 3.17 (извините, но я забл
> посмотреть на время, в которое была загрузка системы)

Да, в логе ничего особо подозрительного не видно.

1.
А что 'ps aux' говорит про состояние зависших процессов (столбец STAT в выводе)? 'D', скорее всего?

Что для этих процессов выдаёт 'cat /proc/<PID процесса>/stack' ?

2.
На наших тестовых системах мы пока с такой проблемой не сталкивались. 

В 3.17, по сравнению с 3.14, не меньше сотни изменений, касающихся работы с RAID, сложно сказать сходу, как именно там проблема исправлена. И в этих ли патчах вообще дело.

Если Вы согласны нам помочь в этом деле, думаю, решение найдётся быстрее.

Вы знакомы с git bisect? Если да, то, думаю, догадались уже, как можно найти то изменение в коде ядра, которое всё исправило. Или хотя бы то, которое всё сломало.

Если не знакомы, то суть в том, чтобы раз за разом деля набор изменений между, скажем, ядром 3.15 (где всё плохо) и 3.17 (где всё хорошо) пополам, найти нужное нам. 

Для начала стоит установить git (если он ещё не установлен) и склонировать себе репозиторий с исходниками ядра:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-upstream

На диске это потребует около 2 Gb, скорее всего.

Затем стоит перейти в склонированном репозитории к версии ядра 3.15:

cd linux-upstream
git checkout v3.15

Теперь можно собрать ядро 3.15 из этих исходников, как Вы уже сделали для 3.17. Лучше, конечно, отдельный каталог для сборки использовать, а не прямо в linux-upstream собирать.

После этого - проверить, проявляется ли проблема на свежесобранном ядре 3.15. Если проявляется, то дальше пойдём аналогично для других ядер между 3.15 и 3.17: я скажу тогда, какие собирать. 

Когда найдём то изменение в ядре, которое всё починило (за 15-20 итераций должны найти, а может, и раньше), я его адаптирую для нашего ядра. 

Если что-то будет непонятно в процессе, будут вопросы - обращайтесь, я подскажу что и как сделать.
Comment 8 Yaroslav 2014-10-17 16:35:54 MSD
1. К сожалению сейчас я не могу посмотреть вывод ps aux.
ТаскМенеджер KDE писал "в ожидании на диске".
Попробовать смогу только завтра.

2. Проблема не наблюдается и в 3.10.51 из репозитория Update к R3.

3. Git-репозиторий ядра клонирую сейчас. Завтра соберу и отпишусь.

В случае чего, как быстро удалить ядро и все модули? make uninstall?
Comment 9 Eugene Shatokhin 2014-10-17 16:43:24 MSD
(In reply to comment #8)
> В случае чего, как быстро удалить ядро и все модули? make uninstall?

make uninstall там не поддерживается. 

Лучше удалить из /boot всё, что касается, данной версии ядра (vmlinuz-<version>*, initrd-<version>*, symvers-<version>*, config-<version>*, System.map-<version>*, ...), а также - /lib/modules/<version>.

Затем сделать update-grub2.
Comment 10 Yaroslav 2014-10-17 16:59:00 MSD
(In reply to comment #9)
> (In reply to comment #8)
> > В случае чего, как быстро удалить ядро и все модули? make uninstall?
> 
> make uninstall там не поддерживается. 
> 
> Лучше удалить из /boot всё, что касается, данной версии ядра
> (vmlinuz-<version>*, initrd-<version>*, symvers-<version>*,
> config-<version>*, System.map-<version>*, ...), а также -
> /lib/modules/<version>.
> 
> Затем сделать update-grub2.

Спасибо! Сейчас собираю ядро 3.15
Но результаты теперь уже смогу дать только завтра.
Comment 11 Eugene Shatokhin 2014-10-17 17:21:22 MSD
(In reply to comment #10)
> Но результаты теперь уже смогу дать только завтра.

Нестрашно: я всё равно их увижу только в понедельник.
Comment 12 Yaroslav 2014-10-18 10:48:21 MSD
Created attachment 3357 [details]
'ps aux' Logs, /proc/$PID/stat log

Действительно, проблема в ядре.
3.15 ванилия та же проблема. Завис на 16 МБ.

В архиве логи PS Logs, /proc/$PID/stat log для двух ядер, а так же скрипт, которым я выдергивал состояние.
Comment 13 Eugene Shatokhin 2014-10-20 11:32:26 MSD
(In reply to comment #12)
> Действительно, проблема в ядре.
> 3.15 ванилия та же проблема. Завис на 16 МБ.

Хорошо. Т.е. посмотрим, где именно проблему исправили (это м.б. попроще, чем искать, где всё сломалось). 

В 3.15 она есть, в 3.17 её нет. Проверьте теперь, пожалуйста, revision d5c1c93 (это примерно "середина" между 3.15 и 3.17, кстати):

* Ядро 3.15, которое Вы проверили, можно удалить. Содержимое каталога, где Вы его собрали - тоже.
* В каталоге с git-репозиторием ядра выполните команду
  git checkout d5c1c93
* Теперь можно из этих исходников собрать и установить ядро, так же, как Вы сделали для 3.15.

После проверки, пожалуйста, выложите и лог (вывод dmesg) для нового ядра.

> В архиве логи PS Logs, /proc/$PID/stat log для двух ядер, а так же скрипт,
> которым я выдергивал состояние.

Спасибо! Это ценная информация. По крайней мере, видно, что процессы, действительно, пытаются получить монопольный доступ к странице памяти, которую кто-то другой "взял и не отдаёт".
Comment 14 Yaroslav 2014-10-20 18:57:40 MSD
Created attachment 3362 [details]
dmesg 3.16.rc2

На ядре 3.16 rc2 проблема не наблюдается.
60 GB спокойно считалось. Потом прервал.
Comment 15 Eugene Shatokhin 2014-10-21 11:13:01 MSD
(In reply to comment #14)
> На ядре 3.16 rc2 проблема не наблюдается.
> 60 GB спокойно считалось. Потом прервал.

Хорошо, считаем, что тут проблемы уже нет. Теперь давайте проверим revision f57a19a:

* git checkout f57a19a
* дальше можно собрать ядро из этих исходников, как Вы делали выше.
Comment 16 Yaroslav 2014-10-21 19:19:48 MSD
(In reply to comment #15)
> (In reply to comment #14)
> > На ядре 3.16 rc2 проблема не наблюдается.
> > 60 GB спокойно считалось. Потом прервал.
> 
> Хорошо, считаем, что тут проблемы уже нет. Теперь давайте проверим revision
> f57a19a:
> 
> * git checkout f57a19a
> * дальше можно собрать ядро из этих исходников, как Вы делали выше.

Я ставил 3.15 ядро из этого репозитория 
http://abf-downloads.rosalinux.ru/kernels_3_15x_personal/repository/rosa2014.1/x86_64/main/release/

А именно kernel-nrj-desktop-3.15.9-1rosa-1-1-rosa2014.1.x86_64.rpm

Глюк был.
Comment 17 Eugene Shatokhin 2014-10-22 10:09:00 MSD
(In reply to comment #16)
> Я ставил 3.15 ядро из этого репозитория 
> Глюк был.

Это совсем другое. 3.15.9 из репозитория и то 3.15, что соответствует ревизии f57a19a, - совсем разные ядра, там разный код.

Проверьте, пожалуйста, f57a19a всё-таки. 

У меня есть подозрение, что там проблема тоже проявится, т.к. все основные исправления по части RAID были после него (кроме двух), но гадать тут вредно. 

Задача найти именно то изменение, которое всё исправило, чтобы я мог его портировать в 3.14. 

Кстати, всего между 3.15 и 3.16 - более 200000 (!) изменений, и из них, как минимум, 600 с лишним могут касаться RAID. Поэтому сходу угадать, как именно проблему исправили, очень непросто.

За несколько шагов "бисекции" с Вашей помощью, надеюсь, удастся сузить область поиска до приемлемых размеров.
Comment 18 Yaroslav 2014-10-22 17:46:56 MSD
Created attachment 3371 [details]
'ps aux' Logs, /proc/$PID/stat log, dmesg

Ядро проверил - зависает.

f57a19a - это 3.15.rс8
Comment 19 Eugene Shatokhin 2014-10-23 11:12:20 MSD
(In reply to comment #18)
> Created attachment 3371 [details]
> 'ps aux' Logs, /proc/$PID/stat log, dmesg

Спасибо! Там только dmesg в этот раз - но его достаточно, остальные логи пока не нужны.

> 
> Ядро проверил - зависает.

Т.е. всё идёт по плану. Хорошо. Следующим проверьте, пожалуйста, ядро с ревизии 0430e49.
Comment 20 Yaroslav 2014-10-23 16:30:09 MSD
(In reply to comment #19)
> (In reply to comment #18)

> Спасибо! Там только dmesg в этот раз - но его достаточно, остальные логи
> пока не нужны.
Тьфу блин... Ступил... Забыл пид процесса передать скрипту.

> Т.е. всё идёт по плану. Хорошо. Следующим проверьте, пожалуйста, ядро с
> ревизии 0430e49.
Через несколько минут поставлю на сблорку.

Проблема проявилась на Asus M2 Crosshair. Там чипсет совершенно другой, nforce570
Comment 21 Yaroslav 2014-10-23 18:23:29 MSD
Created attachment 3376 [details]
'ps aux' Logs, /proc/$PID/stat log, dmesg

Это ядро тоже повесило mc при копировании с рейд-массива.
Comment 22 Eugene Shatokhin 2014-10-24 11:17:42 MSD
(In reply to comment #21)
> Created attachment 3376 [details]
> 'ps aux' Logs, /proc/$PID/stat log, dmesg
> 
> Это ядро тоже повесило mc при копировании с рейд-массива.

Судя по логу, это не то ядро, а предыдущее (3.15-rc8). В 0430e49 должна быть версия 3.15.0. Проверьте, пожалуйста.
Comment 23 Eugene Shatokhin 2014-10-24 11:22:55 MSD
Полезно перед проверкой свежесобранного ядра все или часть старых ядер поудалять, как я описывал выше. А то запутаться легко, особенно, когда версии близкие. 

Либо - после make oldconfig открыть файл .config в каталоге, где идёт сборка, и задать/отредактировать CONFIG_LOCALVERSION (это будет добавлено к версии ядра). Например, - вписать туда номер revision. Или - test01/test02/... Или ещё что-то, что позволит легко находить нужные ядра.
Comment 24 Yaroslav 2014-10-26 17:55:51 MSK
Created attachment 3383 [details]
'ps aux' Logs, /proc/$PID/stat log, dmesg

Завис.

В прошлый раз я, видимо вместо удаления каталога сборки переместил его на место склонированного Git-репозитория. После того как второй раз склонировал репозиторий, сырцы 3.15 rc-8 перестали вылазить.
Comment 25 Eugene Shatokhin 2014-10-27 14:37:45 MSK
(In reply to comment #24)
> В прошлый раз я, видимо вместо удаления каталога сборки переместил его на
> место склонированного Git-репозитория. После того как второй раз склонировал
> репозиторий, сырцы 3.15 rc-8 перестали вылазить.

Да, скорее всего. 

Странно, что зависло и сейчас: все основные изменения в RAID-подсистеме ядра в этом revision уже есть. Значит, ещё в чём-то дело, будем искать дальше.

Перед тем, как следующую ревизию проверять, попробуйте, пожалуйста, пересобрать ядро из тех же исходников с ревизии 0430e49, включив проверку на deadlock'и. Проверим, может, в этом дело.

Включить эти проверки можно в файле конфигурации ядра (.config) перед сборкой туда нужно добавить следующее:

CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y

Либо - использовать 'make <...> menuconfig' вместо 'make <...> oldconfig' и в разделе "Kernel hacking" => "Lock Debugging" включить "Lock debugging: prove locking correctness". Сохранить .config, а дальше - собрать ядро, как обычно (make, make modules_install и пр.).

Выложите тогда вывод dmesg с этого ядра, когда процессы опять зависнут. lockdep может показать что-то интересное.

Затем продолжим bisection c ревизии 88bbfb4.
Comment 26 Yaroslav 2014-10-27 21:28:00 MSK
Created attachment 3385 [details]
Logs from kernel 3.15 with debug

Ядро зависает на этапе загрузки. Пробовал три раза.
После каждого раза с установочного диска Rosa Fresh R4 проверял разделы.

Второе ядро не успею за сегодня подготовить.

В аттаче все логи после первой первой загрузки.
Comment 27 Eugene Shatokhin 2014-10-28 11:28:15 MSK
(In reply to comment #26)
> Ядро зависает на этапе загрузки. Пробовал три раза.

Ясно. Что ж, тогда продолжим поиск. Попробуйте ревизию 88bbfb4.
Comment 28 Yaroslav 2014-10-28 19:41:14 MSK
Created attachment 3386 [details]
'ps aux' Logs, /proc/$PID/stat log, dmesg

То же самое. Зависание.
Comment 29 Eugene Shatokhin 2014-10-28 19:53:54 MSK
(In reply to comment #28)
> То же самое. Зависание.

Ясно. Теперь попробуйте, пожалуйста, ревизию d7933ab.
Comment 30 Eugene Shatokhin 2014-10-28 20:07:42 MSK
Ещё заметил в логах, что система время от времени хочет запустить /sbin/fsck.btrfs и не находит, т.к. у нас fsck.btrfs - в /usr/sbin/

Пока можно сделать симв. ссылку (под root):

ln -s /usr/sbin/fsck.btrfs /sbin/fsck.btrfs

В дальнейшем - поправим на нашей стороне.
Comment 31 Yaroslav 2014-10-29 07:38:54 MSK
Сегодня вечером (gостараюсь до 17 по МСК) проверю ядро из этой ревизии.

Монтирование раздела на Raid-девайсе на тестовых ядрах я провожу в ручную после входа в систему от рута.
Да и в обычных случаях все разделы на рейд-девайсах в fstab прописанны с параметром noauto (при загрузки системы, ядро не видит рейд-контроллер, похоже соответсвующий модуль не вшит в ядро). Монтирую потом скриптом в /etc/rc.5 перед запуском иксов.

/usr у меня на BTRFS разделе не рейд-девайса.
Comment 32 Yaroslav 2014-10-29 17:11:52 MSK
Created attachment 3394 [details]
'ps aux' Logs, /proc/$PID/stat log, dmesg

А тут все нормально.
Зависаний нет.
Comment 33 Eugene Shatokhin 2014-10-29 19:40:16 MSK
(In reply to comment #32)
> А тут все нормально.
> Зависаний нет.

Это хорошо. Из тех изменений, что осталось проверить, особенно интересными кажутся исправления в Btrfs.

Проверьте, пожалуйста, вот эту ревизию: 5fbc7c5. Посмотрим, что сейчас будет.
Comment 34 Eugene Shatokhin 2014-10-30 11:35:47 MSK
(In reply to comment #31)
> Монтирование раздела на Raid-девайсе на тестовых ядрах я провожу в ручную
> после входа в систему от рута.

Это, похоже, из-за проблемы с генерацией initrd - в initrd не попали необх. драйверы для RAID контроллеров. Тоже разбираемся сейчас.
Comment 35 Eugene Shatokhin 2014-10-30 14:50:22 MSK
(In reply to comment #34)
> Монтирование раздела на Raid-девайсе на тестовых ядрах я провожу в ручную
> после входа в систему от рута.

А попробуйте-ка dracut отсюда: http://abf-downloads.rosalinux.ru/rosa2014.1/container/2325849/x86_64/main/release/

Посмотрите, найдёт ли система теперь RAID-контроллер после перезагрузки.
Comment 36 Yaroslav 2014-11-04 19:56:56 MSK
5fbc7c5 вообще не собраалось

  LD      fs/autofs4/built-in.o
  CC [M]  fs/autofs4/init.o
  CC [M]  fs/autofs4/inode.o
  CC [M]  fs/autofs4/root.o
  CC [M]  fs/autofs4/symlink.o
  CC [M]  fs/autofs4/waitq.o
  CC [M]  fs/autofs4/expire.o
  CC [M]  fs/autofs4/dev-ioctl.o
  LD [M]  fs/autofs4/autofs4.o
  CC      fs/btrfs/super.o
  CC      fs/btrfs/ctree.o
  CC      fs/btrfs/extent-tree.o
  CC      fs/btrfs/print-tree.o
  CC      fs/btrfs/root-tree.o
  CC      fs/btrfs/dir-item.o
  CC      fs/btrfs/file-item.o
  CC      fs/btrfs/inode-item.o
  CC      fs/btrfs/inode-map.o
  CC      fs/btrfs/disk-io.o
  CC      fs/btrfs/transaction.o
fs/btrfs/transaction.c: В функции «record_root_in_trans»:
fs/btrfs/transaction.c:293:3: ошибка: неявная декларация функции «smp_mb__before_atomic» [-Werror=implicit-function-declaration]
   smp_mb__before_atomic();
   ^
fs/btrfs/transaction.c: В функции «commit_fs_roots»:
fs/btrfs/transaction.c:1063:4: ошибка: неявная декларация функции «smp_mb__after_atomic» [-Werror=implicit-function-declaration]
    smp_mb__after_atomic();
    ^
cc1: some warnings being treated as errors
scripts/Makefile.build:318: ошибка выполнения рецепта для цели «fs/btrfs/transaction.o»
make[2]: *** [fs/btrfs/transaction.o] Ошибка 1
scripts/Makefile.build:465: ошибка выполнения рецепта для цели «fs/btrfs»
make[1]: *** [fs/btrfs] Ошибка 2
Makefile:878: ошибка выполнения рецепта для цели «fs»
make: *** [fs] Ошибка 2

dracut пока не смотрел. Пока не могу себе позволить на основной системе эксперементировать с такими вещами. Завтра попробую на ПК дочери (Asus M2 Crosshair - там те же самые проблемы с raod).
Comment 37 Eugene Shatokhin 2014-11-05 14:20:44 MSK
Created attachment 3405 [details]
Patch to enable smb_mb__*_atomic()
Comment 38 Eugene Shatokhin 2014-11-05 14:25:14 MSK
(In reply to comment #36)
> 5fbc7c5 вообще не собраалось
>   CC      fs/btrfs/transaction.o
> fs/btrfs/transaction.c: В функции «record_root_in_trans»:
> fs/btrfs/transaction.c:293:3: ошибка: неявная декларация функции
> «smp_mb__before_atomic» [-Werror=implicit-function-declaration]

Я взял соотв. изменения из ядра в виде патча patch-d00a5692.patch ("Patch to enable smb_mb__*_atomic()"). Добавьте его так:

1) перейдите в каталог с исходниками ядра;
2) выполните 
    patch -p1 < путь_к_patch-d00a5692.patch

Если не будет ругаться, что failed, попробуйте ещё раз собрать ядро. Надеюсь, теперь соберётся.
Comment 39 Yaroslav 2014-11-05 18:20:10 MSK
Теперь другое вылезло:

  HOSTCC  scripts/mod/file2alias.o
  HOSTCC  scripts/mod/modpost.o
  HOSTCC  scripts/mod/sumversion.o
  HOSTLD  scripts/mod/modpost
  HOSTCC  scripts/kallsyms
  HOSTCC  scripts/conmakehash
  HOSTCC  scripts/bin2c
  HOSTCC  scripts/recordmcount
  HOSTCC  scripts/sortextable
In file included from scripts/sortextable.c:194:0:
scripts/sortextable.c: В функции «main»:
scripts/sortextable.h:176:3: предупреждение: «relocs_size» may be used uninitialized in this function [-Wmaybe-uninitialized]
   memset(relocs, 0, relocs_size);
   ^
scripts/sortextable.h:106:6: замечание: «relocs_size» was declared here
  int relocs_size;
      ^
In file included from scripts/sortextable.c:192:0:
scripts/sortextable.h:176:3: предупреждение: «relocs_size» may be used uninitialized in this function [-Wmaybe-uninitialized]
   memset(relocs, 0, relocs_size);
   ^
scripts/sortextable.h:106:6: замечание: «relocs_size» was declared here
  int relocs_size;
      ^
  HOSTCC  scripts/asn1_compiler
  CC      init/main.o
In file included from include/linux/kernel_stat.h:8:0,
                 from init/main.c:32:
include/linux/interrupt.h: В функции «tasklet_unlock»:
include/linux/interrupt.h:494:2: ошибка: неявная декларация функции «smp_mb__before_clear_bit» [-Werror=implicit-function-declaration]
  smp_mb__before_clear_bit(); 
  ^
include/linux/interrupt.h: В функции «tasklet_disable_nosync»:
include/linux/interrupt.h:542:2: ошибка: неявная декларация функции «smp_mb__after_atomic_inc» [-Werror=implicit-function-declaration]
  smp_mb__after_atomic_inc();
  ^
include/linux/interrupt.h: В функции «tasklet_enable»:
include/linux/interrupt.h:554:2: ошибка: неявная декларация функции «smp_mb__before_atomic_dec» [-Werror=implicit-function-declaration]
  smp_mb__before_atomic_dec();
  ^
cc1: some warnings being treated as errors
scripts/Makefile.build:318: ошибка выполнения рецепта для цели «init/main.o»
make[1]: *** [init/main.o] Ошибка 1
Makefile:878: ошибка выполнения рецепта для цели «init»
make: *** [init] Ошибка 2

Патч наложился без ошибок.
Comment 40 Yaroslav 2014-11-05 19:02:37 MSK
Created attachment 3406 [details]
drakut install log

Этот drakut не помог.
Система задумывается на фразе что-то типа Start a job a dev-mapper-nvidia_<raid_uid>.device. Потом несколько предупреждений, что устройство к /home не смонтировано. После чего система не позволяет больше ничего сделать, кроме как нажать на Ctrl+Alt+Delete. Но и тут снова система зависает на ранее названной фразе. Размер файла boot.log при этом нулевой.
Comment 41 Eugene Shatokhin 2014-11-05 19:33:29 MSK
(In reply to comment #39)
> Теперь другое вылезло:

Хорошо, тогда пойдём другим путём. Попробуйте revision 47a306a. В каталоге с исходниками ядра выполните для этого:

git reset --hard 47a306a

Затем попробуйте собрать это ядро, как раньше (без доп. патчей и пр.).
Comment 42 Eugene Shatokhin 2014-11-05 19:34:47 MSK
(In reply to comment #40)
> После чего система не позволяет больше
> ничего сделать, кроме как нажать на Ctrl+Alt+Delete.

А по Ctrl+Alt+F2 в вирт. консоль перейти при этом тоже не получается?
Comment 43 Yaroslav 2014-11-06 17:44:13 MSK
Вылетает с ошибкой

fs/btrfs/transaction.c: В функции «record_root_in_trans»:
fs/btrfs/transaction.c:293:3: ошибка: неявная декларация функции «smp_mb__before_atomic» [-Werror=implicit-function-declaration]
   smp_mb__before_atomic();
   ^
fs/btrfs/transaction.c: В функции «commit_fs_roots»:
fs/btrfs/transaction.c:1063:4: ошибка: неявная декларация функции «smp_mb__after_atomic» [-Werror=implicit-function-declaration]
    smp_mb__after_atomic();
    ^
cc1: some warnings being treated as errors
scripts/Makefile.build:318: ошибка выполнения рецепта для цели «fs/btrfs/transaction.o»
make[2]: *** [fs/btrfs/transaction.o] Ошибка 1
scripts/Makefile.build:465: ошибка выполнения рецепта для цели «fs/btrfs»
make[1]: *** [fs/btrfs] Ошибка 2
Makefile:878: ошибка выполнения рецепта для цели «fs»
make: *** [fs] Ошибка 2

Наложил патч
In file included from include/linux/kernel_stat.h:8:0,
                 from init/main.c:32:
include/linux/interrupt.h: В функции «tasklet_unlock»:
include/linux/interrupt.h:494:2: ошибка: неявная декларация функции «smp_mb__before_clear_bit» [-Werror=implicit-function-declaration]
  smp_mb__before_clear_bit(); 
  ^
include/linux/interrupt.h: В функции «tasklet_disable_nosync»:
include/linux/interrupt.h:542:2: ошибка: неявная декларация функции «smp_mb__after_atomic_inc» [-Werror=implicit-function-declaration]
  smp_mb__after_atomic_inc();
  ^
include/linux/interrupt.h: В функции «tasklet_enable»:
include/linux/interrupt.h:554:2: ошибка: неявная декларация функции «smp_mb__before_atomic_dec» [-Werror=implicit-function-declaration]
  smp_mb__before_atomic_dec();
  ^
cc1: some warnings being treated as errors
scripts/Makefile.build:318: ошибка выполнения рецепта для цели «init/main.o»
make[1]: *** [init/main.o] Ошибка 1
Makefile:878: ошибка выполнения рецепта для цели «init»
make: *** [init] Ошибка 2

До ревизии обновляюсь с чистой копии репозитория. Два раза в одной копии репозитория не выполняю ни чекаут, ни сборку ядра.
Использую конфиг от linux-3.14.22-nrj-desktop-3rosa
Comment 44 Yaroslav 2014-11-06 17:47:03 MSK
Сейчас клонирую репозиторий по новой.

(In reply to comment #42)
> А по Ctrl+Alt+F2 в вирт. консоль перейти при этом тоже не получается?
Это я пытасля сделать прежде всего.
Даже переключения в пустую консоль без приглашения не происходит.
Comment 45 Eugene Shatokhin 2014-11-06 18:04:11 MSK
(In reply to comment #43)
> Вылетает с ошибкой

Хорошо, постараюсь подготовить нормальный патч, чтобы это всё собралось.
Comment 46 Yaroslav 2014-11-06 19:46:22 MSK
Перекачал репозиторий заново.
То же самое.

  CC      fs/btrfs/transaction.o
fs/btrfs/transaction.c: В функции «record_root_in_trans»:
fs/btrfs/transaction.c:293:3: ошибка: неявная декларация функции «smp_mb__before_atomic» [-Werror=implicit-function-declaration]
   smp_mb__before_atomic();
   ^
fs/btrfs/transaction.c: В функции «commit_fs_roots»:
fs/btrfs/transaction.c:1063:4: ошибка: неявная декларация функции «smp_mb__after_atomic» [-Werror=implicit-function-declaration]
    smp_mb__after_atomic();
    ^
cc1: some warnings being treated as errors
scripts/Makefile.build:318: ошибка выполнения рецепта для цели «fs/btrfs/transaction.o»
make[2]: *** [fs/btrfs/transaction.o] Ошибка 1
scripts/Makefile.build:465: ошибка выполнения рецепта для цели «fs/btrfs»
make[1]: *** [fs/btrfs] Ошибка 2
Makefile:878: ошибка выполнения рецепта для цели «fs»
make: *** [fs] Ошибка 2
Comment 47 Eugene Shatokhin 2014-11-07 13:03:39 MSK
Created attachment 3421 [details]
patch-smp-atomics-01.patch

Попробуйте снова вернуться к ревизии 5fbc7c5 и наложить на неё patch-smp-atomics-01.patch. У меня сейчас это ядро собралось, как минимум.

Кстати, возможно, получится сэкономить время, если не выкачивать каждый раз git-репозиторий заново, а просто собирать ядро в другом каталоге. Плюс, пользоваться git reset --hard <ревизия>, чтобы в каталоге с исходниками переходить на соотв. ревизию, убирая все лишние изменения. Впрочем, это кому как удобнее.
Comment 48 Yaroslav 2014-11-07 21:57:39 MSK
Created attachment 3422 [details]
dmesg log

Ядро собралось. Ошибка присутсвует.

PS:
Репозиторий выкачиваю только один раз.
При обновлении до ревизии использую копию репозитория сделанную с локальной версии.
Comment 49 Eugene Shatokhin 2014-11-10 13:27:03 MSK
(In reply to comment #48)
> Ядро собралось. Ошибка присутсвует.

Хорошо. Попробуйте теперь ревизию 8408c71 с тем же патчем patch-smp-atomics-01.patch.

Если проблема здесь не проявится, значит, дело, скорее всего, в btrfs. Я тогда эти исправления портирую нам.

Если проявится - что ж, будем исследовать дальше.

> PS:
> Репозиторий выкачиваю только один раз.

Да, это тоже вариант.
Comment 50 Yaroslav 2014-11-10 21:50:59 MSK
Created attachment 3432 [details]
ps aux , dmesg

А это ядро с патчем сработало. Зависаний не было.
Comment 51 Yaroslav 2014-11-10 21:57:16 MSK
(In reply to comment #49)

> Если проблема здесь не проявится, значит, дело, скорее всего, в btrfs. Я
> тогда эти исправления портирую нам.

Как-то странно будет, если проблема с btrfs окажется. Использование btrfs-разделов не на Raid-массиве не вызывало зависаний процессов на тех ядрах. BTFS у меня используется на /usr-разделе, разделе, где собираю и откуда ставлю ядра.
Comment 52 Eugene Shatokhin 2014-11-11 13:48:00 MSK
Попробуйте теперь ядро ревизии 46fefe4 с тем же патчем. Осталось уже немного: если всё пойдёт хорошо, итерации за 3-4 найдём нужное изменение в ядре.

(In reply to comment #51)
> Как-то странно будет, если проблема с btrfs окажется.

Да, неочевидно. Тем не менее, все изменения, которые осталось проверить в ядре, относятся как раз к btrfs.

Плюс, если учесть, что модуль ядра для btrfs - один из самых больших среди модулей файловых систем, а протестирован до сих пор не так хорошо, как, например, ext4, то не так уж и удивительно выйдет. 

Главное, чтобы эту проблему с зависанием удалось исправить.
Comment 53 Yaroslav 2014-11-12 22:13:06 MSK
Created attachment 3448 [details]
ps aux , dmesg

Ошибка повторилась.

PS: Два раза собирал не то ядро. Оба раза замечал только на этапе загрузки системы. :(
Comment 54 Eugene Shatokhin 2014-11-13 12:48:51 MSK
(In reply to comment #53)
> Ошибка повторилась.

Хорошо. Круг подозреваемых стал ещё уже. 
Попробуйте теперь ревизию ced96ed с тем же патчем, что и раньше.

> 
> PS: Два раза собирал не то ядро. Оба раза замечал только на этапе загрузки
> системы. :(

Да, у меня такое тоже бывает, особенно когда много ядер собирать приходится.
Comment 55 Yaroslav 2014-11-13 22:21:57 MSK
И это повесило процесс.
Comment 56 Eugene Shatokhin 2014-11-14 13:12:56 MSK
(In reply to comment #55)
> И это повесило процесс.

Спасибо за терпение!

Попробуйте теперь ревизию e990f16 с тем же патчем, что и раньше. Очень вероятно, что и оно будет виснуть, но надо проверить. 

После этого "подозреваемых" останется всего двое (2 commit'а, т.е.).
Comment 57 Yaroslav 2014-11-14 15:08:56 MSK
Сегодня поставлю на собираться этот "коммит".
Что бы не терять время на выходных, может быть Вы сразу скажете названий этих двух ревизий? :)
Comment 58 Eugene Shatokhin 2014-11-14 15:23:08 MSK
(In reply to comment #57)
> Что бы не терять время на выходных, может быть Вы сразу скажете названий
> этих двух ревизий? :)

Да, конечно.

Если на ревизии e990f16 всё тоже зависнет, то нужно будет проверить c55f139.

Если на ревизии e990f16 зависаний не будет, то нужно будет проверить 298a8f9.

В обоих случаях patch-smp-atomics-01.patch нужен для сборки, как и раньше.
Comment 59 Yaroslav 2014-11-14 15:30:59 MSK
Спасибо.
Сейчас собираю e990f16
Comment 60 Yaroslav 2014-11-16 21:49:54 MSK
e990f16 - зависание.
c55f139 - работает.
Comment 61 Eugene Shatokhin 2014-11-17 12:45:03 MSK
(In reply to comment #60)
> e990f16 - зависание.
> c55f139 - работает.

Отлично! Спасибо за информацию.

Теперь понятно, где именно проблему исправили:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c55f13964008bfea7c5bee268f28b699cbad7f00

Я постараюсь портировать это изменение нам в ядро 3.14.x.
Comment 62 Eugene Shatokhin 2014-11-20 21:23:52 MSK
Проверьте, пожалуйста, будут ли зависания на ядре kernel-nrj-desktop-3.14.22-4rosa.

Установить его можно так:

urpmi.addmedia kernel-test http://abf-downloads.rosalinux.ru/import_personal/container/2335368/x86_64/main/release/
urpmi kernel-nrj-desktop-3.14.22-4rosa kernel-nrj-desktop-devel-3.14.22-4rosa

Я в это ядро добавил то исправление для Btrfs. Посмотрим, будет ли его достаточно.
Comment 63 Yaroslav 2014-11-20 22:11:55 MSK
Ядро просто повисло при загрузке:
[  OK  ] Found device Hitachi_HDS721050CLA362.
[  OK  ] Started dracut initqueue hook.
         Starting dracut pre-mount hook...
[  OK  ] Started dracut pre-mount hook.
         Mounting /sysroot...
[  OK  ] Mounted /sysroot.
[  OK  ] Reached target Initrd Root File System.
         Starting Reload Configuration from the Real Root...
         Starting File System Check on /dev/disk/by-uuid/2a07d237-6fd5-4fb6-9a48-d7121c9fdb02...
[  OK  ] Started File System Check on /dev/disk/by-uuid/2a07d237-6fd5-4fb6-9a48-d7121c9fdb02.
         Mounting /sysroot/usr...
[  OK  ] Started Reload Configuration from the Real Root.
[  OK  ] Started Show Plymouth Boot Screen.
[  OK  ] Reached target Paths.
[  OK  ] Reached target Basic System.

ФС, вроде не пострадала.
Root - ext4, не рейд.
/usr - btrfs, не рейд.
Comment 64 Eugene Shatokhin 2014-11-21 11:43:36 MSK
(In reply to comment #63)
> Ядро просто повисло при загрузке:

1. Так при каждой загрузке с этим ядром происходит?

2. В вирт. консоль по ctrl-alt-f2 при этом не удаётся перейти? Если да - что в выводе dmesg?

3. Получится ли в single-user mode загрузиться? Для этого нужно добавить "single" (без кавычек) в параметры ядра при загрузке.

4. По дискам и разделам. Всё-таки, какие файловые системы где используются? Что я вижу по последним логам:

BTRFS: sda8, sda7, sda6, а также dm-0, dm-1 (эти два, вероятно, как раз к RAID имеют отношение)

EXT4: sda5, sda3

FAT: sda2 - Это EFI-раздел или что? Кстати, на нём fsck запустить хорошо бы. В последнем логе есть такое: "FAT-fs (sda2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck."
Comment 65 Eugene Shatokhin 2014-11-21 11:48:28 MSK
Ещё хорошо бы проверить ядро 3.17.2 отсюда:
http://abf-downloads.rosalinux.ru/kernels_3_17x_personal/repository/rosa2014.1/x86_64/main/release/

Пакеты: kernel-nrj-desktop-3.17.2-1rosa, kernel-nrj-desktop-devel-3.17.2-1rosa
Comment 66 Yaroslav 2014-11-21 16:20:43 MSK
(In reply to comment #64)
> (In reply to comment #63)
> > Ядро просто повисло при загрузке:
> 
> 1. Так при каждой загрузке с этим ядром происходит?
Я пробовал три раза. Все время останавливается на фразе
Reached target Basic System.
Винт "не шуршит" при этом

> 2. В вирт. консоль по ctrl-alt-f2 при этом не удаётся перейти? Если да - что
> в выводе dmesg?
Реакции даже на ctrl+alt+delete нет

> 3. Получится ли в single-user mode загрузиться? Для этого нужно добавить
> "single" (без кавычек) в параметры ядра при загрузке.
Не пробовал еще.

> 4. По дискам и разделам. Всё-таки, какие файловые системы где используются?
> Что я вижу по последним логам:

> BTRFS: sda8, sda7, sda6, а также dm-0, dm-1 (эти два, вероятно, как раз к
> RAID имеют отношение)
Так и есть.
sda6 - /usr /opt /usr/local (подтома)
sda7 - /mnt/Zone/Steam -для установок игр из Steam
sda8 - диск, где я собирал ядра.
dm-0, dm-1 - устройства в raid. Без таблицы разделов.

> EXT4: sda5, sda3
Root  /boot соответсвено

> FAT: sda2 - Это EFI-раздел или что? Кстати, на нём fsck запустить хорошо бы.
> В последнем логе есть такое: "FAT-fs (sda2): Volume was not properly
> unmounted. Some data may be corrupt. Please run fsck."
Имеено так.
При попытке выключить ПК с зависшим разделом, происходит зависание при отмонтировании этого раздела.

Спасибо, что сказали про ошибки. Исправлю.
Comment 67 Yaroslav 2014-11-21 16:55:15 MSK
(In reply to comment #65)
> Ещё хорошо бы проверить ядро 3.17.2 отсюда:
> http://abf-downloads.rosalinux.ru/kernels_3_17x_personal/repository/rosa2014.
> 1/x86_64/main/release/
> 
> Пакеты: kernel-nrj-desktop-3.17.2-1rosa,
> kernel-nrj-desktop-devel-3.17.2-1rosa

Перешел на 3.17.2.
Linux pc.belykh.me 3.17.2-nrj-desktop-1rosa #1 SMP PREEMPT Sat Nov 1 12:33:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

По ощущениям, первая загрузка чуть меделеннее ванильного 3.17, а KDE загрузился быстрее.

PS: От радости, что появилась возможность поставить 3.17 NRJ не увидел, что Вы просили посмотреть kernel-nrj-desktop-3.17.2-1rosa *confused*.
Comment 68 Eugene Shatokhin 2014-11-24 12:22:08 MSK
Т.е. на ядре 3.17.2-nrj-desktop всё пока работает без зависаний? 

Если так, то пока можно остаться на нём. А я, когда разберусь с текущими делами, всё же попробую воспроизвести проблему на какой-нибудь из наших машин.

Когда будет время, хорошо бы ещё проверку дисков сделать чем-то вроде Victoria, MHDD или аналогичными вещами. Это требует времени, но хотя бы покажет, всё ли в порядке на уровне железа. Скорее всего, в порядке, раз в некоторых конфигурациях работает, но мало ли.
Comment 69 Eugene Shatokhin 2014-11-25 12:08:33 MSK
Ещё один момент. 
Можете как-нибудь (в BIOS или ещё как-то) проверить, в каком режиме работает RAID controller на этой машине? 

lspci пишет, что RAID5, но не знаю, насколько этому можно верить. 

Если, действительно, RAID5, то там, если не ошибаюсь, нужно не менее 3 дисков, а в Вашем случае их 2, так? Если так, то, возможно, контроллер считает, что RAID-массив degraded, и от этого всякие "неожиданности" могут проявляться.
Comment 70 Yaroslav 2014-11-25 13:38:00 MSK
Вообще должен в Raid-1.
По крайней мере, я так настраивал, и так на этапе загрузки ПК (до загрузки GRUB2) пишет система.
Да и среди устройст два dev-mapper с объеммом равным объему одного из дисков, из которых оно собрано. (Понятное дело, что сами диски в каждом устройстве одинаковые).
Comment 71 Eugene Shatokhin 2015-03-03 21:23:28 MSK
Проблемы актуальны для ядра 3.14.33-nrj-desktop в ROSA R5?
Comment 72 Denis Silakov 2016-01-17 23:13:33 MSK
Нынче у нас уже ядро 4.1 и ряд других обновлений, есть ли эта проблема в R6?
Comment 73 Yaroslav 2016-01-19 21:30:00 MSK
(In reply to comment #72)
> Нынче у нас уже ядро 4.1 и ряд других обновлений, есть ли эта проблема в R6?

К сожалению все по прежнему:
Целые Raid-устройства видит только после ручного вызова 
dmraid -ay
и ручного монтирования устройств.

http://hw.rosalinux.ru/index.php?probe=98d2dcccbe