LINUX.ORG.RU

Ноутбук виснет несколько раз в день только под Linux'ом, достало :(

 , ,


0

5

Всем привет! Прошу помощи.

Суть проблемы. Есть у меня ноут, который по совместительству - основная рабочая лошадка. И иногда он у меня зависает.

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

Например, с ядром 4.9, с которым летом «зарелизился» Debian Stretch, была абсолютно стабильная работа. Потом я полез пробовать Mint, который в определенный момент обновился до 4.10, и пошли зависоны. Откатился назад на 4.9 - все стало прекрасно.

В теме, ссылку на которую дал выше, посоветовали вернуться на Debain Stable, что я и сделал. Все было прекрасно где-то до конца декабря, а потом, после очередного обновления ядра в Debian, он стал виснуть и под ним. Причем откат на более старое ядро не помог (хотя раньше это помогало всегда). Сейчас ситуация такая, что виснет на любых ядрах. Причем в аппаратной части компа ничего не менялось.

Исходные данные:

Ноутбук Acer V3-772G - Intel Core i7-4702MQ, Intel HM86, GeForce GTX 760M, оперативки 32 гига 4-мя планками по 8.

Зависает бессистемно, может зависнуть через час, два, три, может через 10 минут работы.

Зависание не связано с нагрузкой на процессор и температурой.

Последнее время смотрел /var/log/syslog после каждого зависания - каких-то закономерностей выявить не удалось.

Разные дистрибутивы (как минимум разные версии Ubuntu \ Mint и Debian) один хрен зависают.

Пробовал ставить свободный или проприетарный драйвера для видео - один хрен, зависает. Пробовал ставить \ не ставить дрова для интеловской видюхи - никакого эффекта.

Дальше уже из области шаманства, наверное, но с интересом заметил, что эта гнида практически никогда не виснет, если я играю. Зато если работает браузер или VirtualBox, шанс зависания увеличивается.

Грешил на память. С интересом обнаружил, что если вынуть две любые планки, т.е. оставить 16 гигов - он не виснет. Решил, что есть битая планка, стал ставить по две планки в разных сочетаниях и тестировал каждый вариант - никак не виснет. Ставлю назад 4 планки - виснет.

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

Назад в винды не хочу, но если не разберусь - придется, линух за рабочий день успевает раза 3 - 4 заиснуть, это уже банально мешает работать. Вынимать память тоже не хотелось бы, так как есть необходимость запускать несколько виртуалок, а с 16-ю гигами это не так вольготно, как с 32-мя.

В общем и целом понимаю, что проблема, видимо, какая-то нетипичная и конкретное посоветовать что-то, наверное, сложно. Но за мысли куда копать \ где посмотреть \ что попробовать - буду признателен.

Раз от перестановки памяти зависит, то 100 внутрь, выдохнуть тонким слоем и протереть.

anonymous ()

у меня с выходом ядер 4.10 и выше 4-е пни стали виснуть - ну так им сто лет в обед и ram 512 метров...

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

Это цитата с вендофорума. А ты чем помог ТС?

anonymous ()

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

robotron5 ()

Пробовал ли запускать какие-нибудь стресс тесты стчтемы? Также интересно, как ведет себя данное железо на генту/калкулат/арч?

rumgot ★★★★★ ()

прочисти контакты для начала.

А второй момент, конечно сейчас уже сложно будет, но вдруг, сравнить конфиги того старого ядра которое нормально работало и текущего. Наверняка какой-нибудь CONFIG_MEMORY_HOTPLUG в NO выставили стабильнозавры.

Gramozeka ★★ ()
Последнее исправление: Gramozeka (всего исправлений: 1)

Пробовал самый свежий 4.14.*? Хотя с убунту и дебиан это может быть нетривиально

anonymous ()

Ну пальцем в небо сейчас укажу, а что если это интегрированная графика? У intel на открытые дрова обычно много нареканий. Она же заберет часть оперативной памяти под свои нужды, а когда ты играешь наверное переключаешь на GeForce.

Aber ★★★★★ ()

Решил, что есть битая планка, стал ставить по две

для нормальных людей есть memtest. для исключения битого региона из общего объёма допиши к параметрам ядра memmap=<сколько>$<адрес>, например, для grub это будет выглядеть так: memmap=0x1000\$0x123ab000. лучше, чтобы числа были кратны размеру страницы, обычно это 4096 байт (0x1000).

anonymous ()

Висла Ubuntu 16.04 беспричинно и тоже как-то вроде чаще с работающим Vbox, обновил Vbox из их реп до 5.2 и активировал swap-file (из коробки походу было без swap). Перестал виснуть.

mikeuser ()
Ответ на: комментарий от micronekodesu

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

Gnom-s-toporom ()
Ответ на: комментарий от rumgot

Стресс тесты специально - не пробовал. Несколько раз ради интереса гонял Unigine Valley, но не долго. И, что характерно, в эти моменты он никогда не вис. А вот по поводу чего-то генту или арчеподобного - мысль интересная, попробую.

Gnom-s-toporom ()
Ответ на: комментарий от Aber

а когда ты играешь наверное переключаешь на GeForce.

Точно, но это сейчас я сижу на Bumblebee (ибо в Debian нет пакета Nvidia-Prime), т.е. переключаюсь именно когда играю. А когда был Mint я использовал Nvidia-Prime, который весь сеанс запускает на карточке Nvidia, все равно зависания были... Так что видимо нет.

Gnom-s-toporom ()
Ответ на: комментарий от Gramozeka

конфиги того старого ядра которое нормально работало

Ваш совет пока выглядит самым интересным. Про конфиги ядра я только вчера узнал, в виду своего начального уровня в Linux.

Изучил вопрос. Как минимум в /boot нашлись конфиги для 4.9.0.4, которое висло иногда, и для 4.9.0.5 (текущего), которое виснет значительно чаще. Сейчас буду смотреть, в чем отличия, и если таковые найдутся - дальше в этом направлении копать. Спасибо!

Gnom-s-toporom ()
Ответ на: комментарий от mikeuser

Висла Ubuntu 16.04 беспричинно и тоже как-то вроде чаще с работающим Vbox, обновил Vbox из их реп до 5.2 и активировал swap-file (из коробки походу было без swap). Перестал виснуть.

А я ведь тоже, в следствии того, что оперативки много, а система на SSD - без свопа работаю... Надо попробовать!

Gnom-s-toporom ()

для таких мощных фиксия разрабатывается

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

В общем, поднял на виртуалке Debian 9.0.0, в нем было ядро 4.9.30 и с ним все было прекрасно. Сейчас ядро 4.9.65 и с ним все не так прекрасно.

Сравнил конфиги из папки /boot, разница между ними не большая - diff выдал:

3c3 < # Linux/x86 4.9.30 Kernel Configuration ---

# Linux/x86 4.9.65 Kernel Configuration

849d848 < CONFIG_KEYS_COMPAT=y 1349a1349

# CONFIG_NET_DSA is not set

7549a7550

CONFIG_KEYS_COMPAT=y

7550a7552

# CONFIG_BIG_KEYS is not set

7556a7559

CONFIG_PAGE_TABLE_ISOLATION=y

Насколько я понимаю последнее - это привет от Meltdown, про остальное буду гуглить =)

Gnom-s-toporom ()
Ответ на: комментарий от Gnom-s-toporom

Если прям сильно хочется разобраться, можно склонировать git репозиторий ядра и через git bisect попробовать найти коммит, который все сломал

false ★★★★★ ()

Ноутбук Acer V3-772G - Intel Core i7-4702MQ, Intel HM86, GeForce GTX 760M, оперативки 32 гига 4-мя планками по 8.

Крутая печка.

Deleted ()
Ответ на: комментарий от Aber

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

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

Крутая печка.

Одна небольшая доработка в СО + регулярное удаление пыли и никаких проблем...

Ну а так из сводок с фронтов - создание свопа не помогло. Прогнал еще раз мемтест - за ночь два прохода, ошибок нет.

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

Gnom-s-toporom ()
Ответ на: комментарий от mir-inoy

Пока ничего нового =) Вчерашний подозреваемый не подтвердился, все зависло и без него, ближе к вечеру.

На глубокие ковырялки с этим вопросом, если и будет время, то в выходные. Пока две рабочие мысли - попробовать принципиально другой дистр (Арч не потяну, думаю про Manjaro) и попробовать использовать что-то другое вместо VirtualBox'а.

Ну и не отпускает меня зацепка с тем, что он не виснет, когда на нем играют.

Тут опять вроде как прослеживается связь - VirtualBox используется для работы - машина зависает, когда работаю...

Только вот недавно пробрала меня ностальгия, и я играл в третьих героев. Причем в том же виртуалбоксе. И что-то я не припомню, что бы хоть раз был «зависон» в это время.

Или вот у меня дети иногда берут этот комп, чтобы в Minecraft по сетке поиграть. Причем в выходные сидят по несколько часов, и я не помню, чтобы он в это время зависал.

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

Gnom-s-toporom ()
Ответ на: комментарий от Gnom-s-toporom

Исходите из того, что с вероятностью 90% проблема в видеодрайвере или в сочетании с неявным дефектом в железе. Как бы вам на первый взгляд ни казалось иное.

vaddd ★☆ ()

Добавь в

/etc/systemd/journald.conf

строки:

Storage=persistent
SyncIntervalSec=5s

Затем в консоли:

systemctl restart systemd-journald

Скорее всего при зависании всё самое интересное из логов просто не успевает сброситься на диск и ты там точно ничего не увидишь, ведь по умолчанию у сустемды время синка 1 раз в 5 минут (кто это только придумал?" %;;№"!) После того, как в очередной раз зависнет смотри лог, там должно быть что-то информативное. После рпешения проблемы советую параметр SyncIntervalSec поменять в большую сторону, 1 минута например, чтоб диск чильно не дёргать.

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

Спасибо большое. Установил предложенные настройки.

Собственно, действительно вырисовывается нечто общее. Словил за прошедшее время 7 зависаний (из них три - сегодня).

Всегда последние строки перед тем, как он виснет - нечто вроде:

Jan 31 11:17:14 ACER PackageKit: refresh-cache transaction /17060_adadcabb from uid 1000 finished with failed after 1519ms Jan 31 11:17:18 ACER PackageKit: get-updates transaction /17061_adadbbcb from uid 1000 finished with success after 1383ms Jan 31 11:17:18 ACER PackageKit: get-updates transaction /17062_ddeecdcd from uid 1000 finished with success after 449ms Jan 31 11:23:14 ACER PackageKit: refresh-cache transaction /17064_ceabcdec from uid 1000 finished with failed after 1505ms Jan 31 11:23:18 ACER PackageKit: get-updates transaction /17065_abcbeedd from uid 1000 finished with success after 1729ms Jan 31 11:23:19 ACER PackageKit: get-updates transaction /17066_bbcbaddb from uid 1000 finished with success after 453ms

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

Gnom-s-toporom ()
Ответ на: комментарий от Gnom-s-toporom

Пардон, на абзацы побил

Jan 31 11:17:14 ACER PackageKit: refresh-cache transaction /17060_adadcabb from uid 1000 finished with failed after 1519ms

Jan 31 11:17:18 ACER PackageKit: get-updates transaction /17061_adadbbcb from uid 1000 finished with success after 1383ms

Jan 31 11:17:18 ACER PackageKit: get-updates transaction /17062_ddeecdcd from uid 1000 finished with success after 449ms

Jan 31 11:23:14 ACER PackageKit: refresh-cache transaction /17064_ceabcdec from uid 1000 finished with failed after 1505ms

Jan 31 11:23:18 ACER PackageKit: get-updates transaction /17065_abcbeedd from uid 1000 finished with success after 1729ms

Jan 31 11:23:19 ACER PackageKit: get-updates transaction /17066_bbcbaddb from uid 1000 finished with success after 453ms

Gnom-s-toporom ()

Попробуй добавить acpi_osi='!Windows 2012' в параметры ядра при загрузке.

i-rinat ★★★★★ ()

Багованый пекеджкит, можно его грохнуть целиком с корнем, если у вас нет проблем с установкой софта из консоли. Можно попробовать сменить дистр, например на opensuse у меня такой проблемы нет. С другой стороны, уверен у тысяч пользователей Ubuntu/Mint/Debian тоже нет такой проблемы, значит она железячная, да и пекеджкит не должен ложить всю систему целиком, может в журнале есть ещё что-то подозрительное?

на всякий случай покажите

smartctl -a /dev/sda

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

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

Собственно, нового пока ничего нет. Зависать продолжает, в логах все так же в последних строчках PackageKit.

Предложенное acpi_osi='!Windows 2012' в параметрах ядра при загрузке - не влияет.

BIOS стоит 1.13, вроде как жалобы на зависания были в 1.11. Есть еще 1.15, но там значится поддержка GF 850 и изменение настроек системы охлаждения. Собственно, из-за этих настроек на него и не перехожу - ноут начинает молотить куллером как больной, а температура и на 1.13 нормальная держится, со старыми настройками. Ради интереса и для чистоты эксперимента обновлюсь на него в выходные.

В выходные же надеюсь выбрать время и все-таки перебраться в какой-нибудь Manjaro. Тоже для чистоты эксперимента. Ну и интересно просто.

smartctl -a /dev/sda -

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-5-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     SandForce Driven SSDs
Device Model:     KINGSTON SV300S37A240G
Serial Number:    50026B7257062949
LU WWN Device Id: 5 0026b7 257062949
Firmware Version: 603ABBF0
User Capacity:    240 057 409 536 bytes [240 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS, ACS-2 T13/2015-D revision 3
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Thu Feb  8 17:04:43 2018 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever 
                                        been run.
Total time to complete Offline 
data collection:                (    0) seconds.
Offline data collection
capabilities:                    (0x7d) SMART execute Offline immediate.
                                        No Auto Offline data collection support.
                                        Abort Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   1) minutes.
Extended self-test routine
recommended polling time:        (  48) minutes.
Conveyance self-test routine
recommended polling time:        (   2) minutes.
SCT capabilities:              (0x0025) SCT Status supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x0032   095   095   050    Old_age   Always       -       0/2974615
  5 Retired_Block_Count     0x0033   100   100   003    Pre-fail  Always       -       0
  9 Power_On_Hours_and_Msec 0x0032   095   095   000    Old_age   Always       -       4717h+12m+06.540s
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       1394
171 Program_Fail_Count      0x000a   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
174 Unexpect_Power_Loss_Ct  0x0030   000   000   000    Old_age   Offline      -       352
177 Wear_Range_Delta        0x0000   000   000   000    Old_age   Offline      -       2
181 Program_Fail_Count      0x000a   100   100   000    Old_age   Always       -       0
182 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
187 Reported_Uncorrect      0x0012   100   100   000    Old_age   Always       -       0
189 Airflow_Temperature_Cel 0x0000   034   064   000    Old_age   Offline      -       34 (Min/Max 10/64)
194 Temperature_Celsius     0x0022   034   064   000    Old_age   Always       -       34 (Min/Max 10/64)
195 ECC_Uncorr_Error_Count  0x001c   120   120   000    Old_age   Offline      -       0/2974615
196 Reallocated_Event_Count 0x0033   100   100   003    Pre-fail  Always       -       0
201 Unc_Soft_Read_Err_Rate  0x001c   120   120   000    Old_age   Offline      -       0/2974615
204 Soft_ECC_Correct_Rate   0x001c   120   120   000    Old_age   Offline      -       0/2974615
230 Life_Curve_Status       0x0013   100   100   000    Pre-fail  Always       -       100
231 SSD_Life_Left           0x0000   098   098   011    Old_age   Offline      -       21474836481
233 SandForce_Internal      0x0032   000   000   000    Old_age   Always       -       654
234 SandForce_Internal      0x0032   000   000   000    Old_age   Always       -       4294
241 Lifetime_Writes_GiB     0x0032   000   000   000    Old_age   Always       -       4294
242 Lifetime_Reads_GiB      0x0032   000   000   000    Old_age   Always       -       6190
244 Unknown_Attribute       0x0000   099   099   010    Old_age   Offline      -       6291509

SMART Error Log not supported

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Gnom-s-toporom ()
Ответ на: комментарий от Gnom-s-toporom

Диск хороший... Кроме обновления биоса больше ничего в голову не лезет, ну и конечно манипуляция ядрами-драйверами до посинения =(

Pyzia ★★★★★ ()

Есть вероятность, что это Intel C-State чудит. Попробуй загрузиться с опцией ядра intel_idle.max_cstate=1 и жестко потестируй. Если поможет, пробуй увеличивать число.

anonymous ()

1. Под линуксом сколько объем ОЗУ? Может неверно определяется.

2. У винды есть хаки на глючные платы.

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

Про ОЗУ - Kinfocenter кажет: «Всего физической памяти: 33609748480 байтов = 31,30 ГиБ».

Но вообще тут новость нарисовалась. Таки поставил я в четверг вечером Manjaro. И с тех пор - пока ни одного зависона. Ядро 4.14.16-1.

Пока меня это радует, буду посмотреть дальше, либо в зависимости от версии ядра опять начнется свистопляска, либо нет. Но 4 дня без зависаний, хоть пока и не 100% - серьезная заявка на то, что проблема решена (чтобы быть уверенным, конечно, надо бы еще дней 10).

Было бы, конечно, интересно погонять Debian или Ubuntu с этим же ядром, чтобы внести окончательную ясность... Но боюсь, просто времени не хватит.

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