Зависание системы из-за Chromium

В последнее время (может около месяца) наблюдается зависание системы при работе в браузере Chromium.
Зависает “наглухо” - то есть ни в консольный режим не переходит, ни отвечает на комбинации с PrtScr.
Проблема возникает либо после просмотра большого количества страниц, либо меньшего количества, но “тяжелых”.

  • была у кого нибудь аналогичная проблема?
  • с какого места начинать “копать”?

какие ядро,видюха, версия хрома?
# uname -r
# lspci |grep -i vga
# eix -IC www chrom

3.18.11-calculate
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde PRO [Radeon HD 7750 / R7 250E]
www-client/chromium Available versions: 42.0.2311.9
все версии стабильные/обновленные

но проблема была и на предыдущих версиях ядра/хрома
возможно (но точно не помню) она стала появляться после перехода на бинарный профиль
файла подкачки в системе нет

Надеюсь, у вас есть возможность с другой машины в той же сети запустить ssh на вашу, со следующими параметрами:
# ssh <IP_of_monitored_PC> dmesg -wTe --color=always | tee /tmp/dmesg_of_<monitored_hostname>
и продолжить работать до очередного вылета.
Это сильно упростило-бы “разбор полетов”
После вылета, даже если прокрутить на нужную “глубину” лог не получится (мало-ли, ограничение глубины прокрутки термиала и т.п.), у вас останется копия лога в /tmp/dmesg_of_<monitored_hostname>
@
@
PS
думаю, что вместо <IP_of_monitored_PC> и <monitored_hostname> прописать, вы и сами догадаетесь

PPS
даже если нет такой возможности - можно то же самое выполнить на локальной машине, только вместо /tmp указать не очищаемую директорию. К примеру вот так

# dmesg -wTe --color=always | tee /root/dmesg

Это удобнее, чем разбираться в dmesg, что сыплет в /var/log/messages, т.к. таймстампы проще читать в коротком виде, и цветовая дифференцировка уровня критичности сообщения упрощает разбор логов.
Но в случае, если проблема с hdd, как вы понимаете, лог что в /root/dmesg, что в /var/log/messages, не сохранятся.
Так что по ssh надежнее.

Все сделал…
Это файл с машины на которой зависание и происходит.
Файл полученный на другой машине по ssh оканчивается на том же месте.

dmesg (62.5 KB)

и это все? но в нем же совсем ничего об обвале системы!?
действительно мистика

файла подкачки в системе нет

попробуйте создать/подключить где-нибудь на sdb своп, или отключить zswap:
добавьте параметр ядра zswap.enabled=0
@
@
второй вариант что я вижу:
Судя по всему используется проприетарный драйвер. Что если переключить на открытый? ошибка сохранится?

Михаил Гагауз wrote:

попробуйте создать/подключить где-нибудь на sdb своп, или отключить zswap:
Судя по всему используется проприетарный драйвер. Что если переключить на открытый? ошибка сохранится?

можно попозже попробовать

разбираться в dmesg, что сыплет в /var/log/messages

а после перезагрузки “кнопкой” какие то логи могли остаться?
где их поискать?

а после перезагрузки “кнопкой” какие то логи могли остаться?
где их поискать?

собственно, в /var/log/messages (смотри сообщения от kernel), но, по понятным причинам, они могут не сохраниться, если отвалится syslog или подглючит hdd, либо драйвер fs.
Поэтому я и предложил забирать dmesg-сообщения по ssh (когда-то я таким образом на удаленной машине диагностировал отваливание hdd от перегрева)

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

вот из /var/log/messages за сегодняшнее утро
как минимум было 2 зависания
примерно можно определить время - это до и после запуска ssh

ничего подозрительного

log (28.6 KB)

Еще раз повторю - зачем используете fglrx, и пробовали ли просто radeon

Использую wine и steam
Они вроде как с проприетарными драйверами лучше работают?

озу проверяли? может у вас железо (точнее мосты) греются?

Посмотрите список процессов, случаем не gnome-keyring отъедает?

Николай Бочков wrote:

озу проверяли? может у вас железо (точнее мосты) греются?

нет - во время работы, игр и т.п. никогда зависаний не было
только интернет и только Хром (до этого долго сидел на Опере - так же проблем не было)

Alexander Tratsevskiy wrote:

Посмотрите список процессов, случаем не gnome-keyring отъедает?

в настоящий момент:

  • gnome-keyring занимает в памяти менее 1 Мб (разделенной - 9 Мб)
  • у Хрома десяток процессов с суммарным использованием памяти более 500 Мб

Как отловить, что происходит в момент зависания - не знаю (все логи, что мог - уже показал)

ну попробуй запустить хром с терминала, поковыряй его опции может есть какая с дебагом, либо уровнем логов. Если не получиться выловить, то начни с видео драйвера, откатить версию, или размаскировать другую.

У меня подобные зависания были связаны, как я понял с 8-головым амд 8350 на кривой матери. Но вроде перестало после того, как я установил app-portage/cpuinfo2cpuflags, добавил соответствующую строку в make.conf и пересобрал мир.

Всем привет.Решил calculate попробовать.
В XFCE c проприетарными ati запуск chromium выбрасывает из сеанса.
Помогло добавление в xorg.conf (aticonfig --initial какой-то ущербный создает):

.............
Section "Module"
  Load "dri"
  Load "dbe" # Double buffer extension
  Load "extmod" # Misc. required extensionlibpng warning: iCCP: known incorrect sRGB profile
EndSection
.............
EndSection

Section "DRI"
    Group        "video"
    Mode         0666
EndSection

Section "Extensions"
    Option      "Composite" "On"
EndSection
....

из старого xorg.conf

PS на нетбуке еее РС со свободными дровами - это + 6-7 градусов t при простое и вентилятор уже сразу в другом тоне.

переход на fglrx в кальке намного проще :

emerge ati-drivers && cl-setup-video --video fglrx

и конфиг нормальный будет :slight_smile: