Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: Tumbleweed: Очень медленно выключается, начиная с ядра 4.12

  1. #1

    Default Tumbleweed: Очень медленно выключается, начиная с ядра 4.12

    Здравствуйте, коллеги

    Никак не могу понять, что случилось с моим Tumbleweed: он выключается по полчаса, начиная с момента, когда я обновил ядро до 4.12 (это предположительно, точно я не засекал).
    Выглядит проблема так: когда я даю команду "Выключить", в консоли очень долго висят сообщения о выключении Postfix, NTPD и еще некоторых процессов, далее, спустя полчаса, я вижу "watchdog didn't stop" и, спустя примерно минут 3-5, ноут выключается.
    Проблема не зависит от DE: проверял в Plasma и Cinnamon. Симптомы одинаковые.
    journalctl смотрел, в нем ничего нет: получается, что куска времени размером примерно в полчаса просто нет. Т.е. события происходят, но в журнале они не фиксируются.
    Подскажите, плз, как посмотреть лог остановки процессов и выгрузки ядра. Сказать точно, что проблема в ядре, я не могу, т.к. понятно, что, помимо ядра, в системе обновлялось много чего. Но вот как-то так совпало, что проблема возникла после обновления ядра до 4.12. Сейчас установлено 4.13.4-1-default.
    Ноутбук: MSI GS40 6QE Phantom, i7 Skylake, Intel HM170. Все firmware обновлены вкрай, дальше обновлять нечем

  2. #2
    Join Date
    Jun 2008
    Location
    Moscow, Russia
    Posts
    3,050
    Blog Entries
    1

    Default Re: Tumbleweed: Очень медленно выключается, начиная с ядра 4.12

    Посмотрите в 10-ю консоль (Ctrl + Alt + F10).

  3. #3
    Join Date
    Aug 2009
    Location
    Russia
    Posts
    2,247

    Default Re: Tumbleweed: Очень медленно выключается, начиная с ядра 4.12

    Я за вас немного погуглил: https://unix.stackexchange.com/quest...ot-stop#249660

    Никак не могу понять, что случилось с моим Tumbleweed
    Вы хотели rolling? - кушайте))

    Посмотрите в 10-ю консоль
    Это неудобно. Проще добавить в конфиг syslog-ng перенаправление в файл дополнительно к выводу в десятую консоль. Ах journalctl? Ну надо думать.. лень.

    Подскажите, плз, как посмотреть лог остановки процессов и выгрузки ядра.
    Зарывайтесь в доки по systemd наверно. У меня была похожая проблема, она была связана с драйвером nvidia, но это было в логе прямым текстом.

  4. #4
    Join Date
    Jun 2008
    Location
    Moscow, Russia
    Posts
    3,050
    Blog Entries
    1

    Default Re: Tumbleweed: Очень медленно выключается, начиная с ядра 4.12

    Quote Originally Posted by joneone View Post
    конфиг syslog-ng
    rsyslog по умолчанию идёт.

  5. #5
    Join Date
    Aug 2009
    Location
    Russia
    Posts
    2,247

    Default Re: Tumbleweed: Очень медленно выключается, начиная с ядра 4.12

    rsyslog по умолчанию идёт.
    Он мне не нравится)) и элементарно меняется на syslog-ng. И journalctl`у очень просто сказать, чтобы использовал сторонний логгер (раз у топикстартера "journalctl смотрел, в нем ничего нет"). Но вообще да, для начала можно и на 10ую консоль посмотреть.

  6. #6

    Default Re: Tumbleweed: Очень медленно выключается, начиная с ядра 4.12

    Покажите, где я возмущался rolling Он меня всем устраивает - кроме этой проблемы.

    По поводу консолей - это было первым, что я попробовал. Нигде (вообще нигде, кроме первой консоли) нет ничего вообще. Ну т.е. там моргает курсор и все. Касаемо syslog - разве он не в journalctl смотрится? Ежели да - туда я тоже смотрел (как и написал с самого начала), там пусто. Такое впечатление, что с момента ввода reboot до перезагрузки ничего вообще не происходит.
    Может какой параметр подкрутить надо? К сожалению, не силен по части тонкостей настройки ядра и т.д., потому совета и спрашиваю.
    Пока думаю, что проблема связана с ACPI: при загрузке матюки по поводу невозможности загрузки таблиц, ссылка по поводу watchdog намекает, опять же, на ACPI. С Nvidia у меня тоже были проблемы, я просто занес nouveau в blacklist, nvidia не ставил. Мне i915 вполне хватает - тем более, что в 4.12 вылечили, наконец, глюк этого модуля, из-за чего при работе в LO X-сессия намертво висла.

  7. #7
    Join Date
    Jan 2011
    Location
    Vladivostok
    Posts
    679

    Default Re: Tumbleweed: Очень медленно выключается, начиная с ядра 4.12

    приветствую

    ACPI можно отключить при загрузке параметром acpi=off

    нагуглил такую штуку https://github.com/farseerfc/systemd-shutdown-diagnose

    1. делалось под Арч
    2. автор предупреждает, что можно прострелить ногу

  8. #8

    Default Re: Tumbleweed: Очень медленно выключается, начиная с ядра 4.12

    Попробовал с acpi=off: плазма почему-то просто не загрузилась, но выключение из экрана gdm - практически моментально (56 сек против 35 минут - отлично, как по мне). Таки дело, видимо, действительно в ACPI. Подскажите, плз, как, что и где подкрутить, чтобы дальше отследить, в чем грабля? Я, к сожалению, не настолько силен, чтобы своими силами даже с помощью гугеля осилить, что именно нужно сделать.

  9. #9
    Join Date
    Jan 2011
    Location
    Vladivostok
    Posts
    679

    Default Re: Tumbleweed: Очень медленно выключается, начиная с ядра 4.12

    биос свежий?
    я когда-то правил таблицы у своего недобука, ничё сверхъестественного, хоть и нудно
    https://wiki.archlinux.org/index.php/DSDT

    для начала можно поэкспериментировать с параметром ядра acpi_os_name=

  10. #10

    Default Re: Tumbleweed: Очень медленно выключается, начиная с ядра 4.12

    BIOS крайний доступный, он для GS40 6QE вообще единственный, выпущенный в 2016 году. С этим ноутом вообще все странно: до него был GE62 6QC, который, как мне казалось, практически клон по железу. При этом с GE62 не было таких проблем: с самого начала c GS40 существует проблема с Bluetooth (которой не было у GE62 на той же версии TW), плюс эта ерунда с ACPI и т.д.
    Попробовал по совету по ссылке сдернуть и декомпилировать/рекомпилировать таблицы ACPI:
    - при декомпиляции получил сообщение
    Code:
    iASL Warning: There were 18 external control methods found during
     disassembly, but only 0 were resolved (18 unresolved). Additional
     ACPI tables may be required to properly disassemble the code. This
     resulting disassembler output file may not compile because the
     disassembler did not know how many arguments to assign to the
     unresolved methods. Note: SSDTs can be dynamically loaded at
     runtime and may or may not be available via the host OS.
    - рекомпиляция вообще не пошла из-за синтаксической ошибки.

    Вообще этот ноут рассчитан только на W10 (GE62 того же времени выпуска был W7/W10), может, дело в этом? Какой именно параметр acpi_os_name надо указывать, чтобы система думала, что это W10? Пробовал acpi_os_name="Windows 2012", разницы никакой вообще. Ну и, опять же, что делать дальше: трепать MSI на предмет свежего бивиса или постить багрепорт в багзиллу по поводу проблем ACPI (в которых я, опять же, на 100% не уверен)?

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •