Назад | Перейти на главную страницу

Гости Windows 10 KVM вызывают сбой хоста Ubuntu 20.04 (пересмотрено)

Я сильно запуталась и решила переписать вопрос с нуля, так что если некоторые комментарии не имеют смысла, то вот почему. Апоплогии ко всем, чье время я зря потратил.

У меня проблема с зависанием всей моей системы при использовании виртуальных машин KVM (как с сквозной передачей PCI). Хост - Ubuntu 20.04, работающий на Threadripper 1950X с материнской платой ASRock x399 Taichi.

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

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

В любом случае моя стратегия состоит в том, чтобы вставить описание того, что я делаю, в journalctl, помеченное как "### Admin note:", используя

 echo '###Admin note: test' | systemd-cat

Результат при просмотре с journalctl -b -1 после перезагрузки: https://pastebin.com/fi1iR8Zx

Последнее сообщение, которое я отправил в journalctl, похоже, не было сохранено, но появилось в терминале:

И выход journalctl -k -b -1 https://pastebin.com/1t38WsWh

Есть ли другие журналы, в которых я должен заглянуть? Какая дополнительная информация будет полезна? Я собирался опубликовать информацию о своих PCI-устройствах и моем XML-файле virsh, но не хочу перегружать этот пост ненужными материалами.

Изменить: я замечаю, что у меня высокая температура на чем-то под названием SMBUSMASTER. Пока что я нашел только предположения о том, что именно. Если максимальная безопасная температура такая же, как для CPUTIN (68C), значит, у меня проблема.

Кроме того, помимо сквозной передачи PCI графических процессоров, одной необычной особенностью моей системы является то, что все USB-устройства Windows подключены к карте PCI USB-C, которая проходит через нее. Я не вижу ничего, что могло бы указать на это в журнале, но, похоже, стоит упомянуть.

Возможное решение?

Думаю, я понял это.

Просматривая свои журналы, я заметил много таких записей:

Jul 10 23:43:20 virtland kernel: [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

Поиск в Google привел меня к этой ошибке Ryzen: https://bugzilla.kernel.org/show_bug.cgi?id=196683

что привело меня к этой теме: http://forum.asrock.com/forum_posts.asp?TID=11690&title=x370-taichi-c-states

Теперь я мог поклясться, что отключился suspend to memory давным-давно, но, конечно же, было установлено auto. В любом случае я выключил и теперь слушаю музыку из Windows и работаю в Kubuntu.

Возможно, настройка вернулась к значениям по умолчанию, когда я обновил прошивку перед настройкой хоста, но я до сих пор не понимаю, почему это может быть проблемой. Может это быть связано с властью? У нас жара, иногда мерцают огни. Я использую ИБП APC именно по этой причине, но он издает много щелкающих звуков, когда у меня включен кондиционер. Я, конечно, не пытался приостановить работу ОЗУ в какой-либо момент, но могли ли колебания мощности, которые ИБП не исправил достаточно быстро, каким-то образом спровоцировали что-то, связанное с этим.

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

На самом деле я говорил слишком рано, вот логи с того сеанса. Несколько часов я без проблем пользовался Windows и Kubuntu, что было рекордом. Ошибки MWAIT все еще существуют:

journalctl -b -1 : https://pastebin.com/1feLq19U

Изменить: я заметил, что последний журнал, кажется, обрезается задолго до того, как на самом деле происходит сбой, поэтому я воспроизвел сбой еще раз. Выход journalctl -b -1 после перезагрузки отрубается больше десяти минут до вылета. К счастью, я запускал `journalctl -f ', и это фактически захватило все до моего последнего комментария (сбой произошел менее чем через минуту). К сожалению, в момент сбоя я не вижу ошибок.

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

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

  1. Выход journalctl -b -1 : Прекращается на 10 минут раньше, но включен для сравнения. https://pastebin.com/mKu4bBzL

  2. Текст сохранен из journalctl -f > file.txt, что завершено: https://pastebin.com/kSXDRkBp

  3. Изображение экрана

Изменить: еще одна деталь, которая может иметь значение, заключается в том, что виртуальная машина Windows была создана с помощью предыдущей установки хоста (она была создана с помощью Arch, но с более ранней версией QEMU, так что это не должно быть проблемой, верно?)

Изменить: отключенные C-состояния на моей материнской плате, не повезло

Изменить: я настроил аварийные дампы ядра, как описано здесь: https://ubuntu.com/server/docs/kernel-crash-dump Там много всего, но я заметил вот что:

[  463.983070] vfio-pci 0000:09:00.0: vfio_ecap_init: hiding ecap 0x1b@0x2d0
[  463.983308] vfio-pci 0000:09:00.0: vfio_ecap_init: hiding ecap 0x1e@0x370
[  465.131213] vfio-pci 0000:0a:00.0: vfio_ecap_init: hiding ecap 0x19@0x280
...
[ 1047.680144] vfio-pci 0000:43:00.0: enabling device (0000 -> 0003)
[ 1047.680422] vfio-pci 0000:43:00.0: vfio_ecap_init: hiding ecap 0x19@0x900

Это идентификаторы PCI всех карт, через которые я прохожу (43 для Kubuntu, 09 и 0a в Windows). Поиск в Google hiding ecap нашел темы о проблемах с похожим на мое оборудование (AMD CPU + AMD GPU passthrough): https://forums.gentoo.org/viewtopic-t-1070816-start-0.html https://forum.level1techs.com/t/rx-470-stuck-in-d3-single-gpu-passthrough/147401

Я перешел через RX470 на Windows и смог выключить или запустить снова без проблем в течение нескольких месяцев. Я давно отказался от попыток заставить его работать с Linux из-за ошибки сброса AMD. Возможно ли, что эта ошибка снова проявляется в другой форме?