Я только что решил эту проблему, создав драйвер i915 в ядре(CONFIG_DRM_I915=y
)вместо модуля (CONFIG_DRM_I915=m
), который требовал CONFIG_DRM=y
вместо =m
.
Сделав два вышеуказанных изменения, вот что make nconfig
на самом деле изменилось в.config
:
---.config.old 2019-09-10 12:38:12.798272432 +0200
+++.config 2019-09-10 15:17:26.327144324 +0200
@@ -2279,7 +2279,7 @@ CONFIG_I2C_MUX=m
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_SMBUS=m
-CONFIG_I2C_ALGOBIT=m
+CONFIG_I2C_ALGOBIT=y
#
# I2C Hardware Bus support
@@ -3124,11 +3124,12 @@ CONFIG_AGP_INTEL=y
CONFIG_INTEL_GTT=y
# CONFIG_VGA_ARB is not set
# CONFIG_VGA_SWITCHEROO is not set
-CONFIG_DRM=m
+CONFIG_DRM=y
CONFIG_DRM_MIPI_DSI=y
CONFIG_DRM_DP_AUX_CHARDEV=y
+# CONFIG_DRM_DEBUG_MM is not set
# CONFIG_DRM_DEBUG_SELFTEST is not set
-CONFIG_DRM_KMS_HELPER=m
+CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_KMS_FB_HELPER=y
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
@@ -3160,7 +3161,7 @@ CONFIG_DRM_I2C_NXP_TDA998X=m
# end of ACP (Audio CoProcessor) Configuration
# CONFIG_DRM_NOUVEAU is not set
-CONFIG_DRM_I915=m
+CONFIG_DRM_I915=y
CONFIG_DRM_I915_ALPHA_SUPPORT=y
CONFIG_DRM_I915_FORCE_PROBE="*"
CONFIG_DRM_I915_CAPTURE_ERROR=y
@@ -3223,7 +3224,7 @@ CONFIG_DRM_PANEL_BRIDGE=y
# CONFIG_DRM_TINYDRM is not set
# CONFIG_DRM_VBOXVIDEO is not set
# CONFIG_DRM_LEGACY is not set
-CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=m
+CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y
#
# Frame buffer Devices
@@ -3236,11 +3237,11 @@ CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
-CONFIG_FB_SYS_FILLRECT=m
-CONFIG_FB_SYS_COPYAREA=m
-CONFIG_FB_SYS_IMAGEBLIT=m
+CONFIG_FB_SYS_FILLRECT=y
+CONFIG_FB_SYS_COPYAREA=y
+CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
-CONFIG_FB_SYS_FOPS=m
+CONFIG_FB_SYS_FOPS=y
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_MODE_HELPERS is not set
CONFIG_FB_TILEBLITTING=y
@@ -3265,7 +3266,6 @@ CONFIG_FB_VESA=y
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I740 is not set
# CONFIG_FB_LE80578 is not set
-# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
Я сохранил все аргументы ядра kexec из OP, и это работает! Я также удалил все аргументы i915
из OP, и он все еще работает, вот так:systemd.unit=kdump-save.service irqpoll nr_cpus=1 reset_devices ipv6.disable=1 loglevel=9
Теперь видеорежим сброшен, и я мог видеть все в ядре kexec с 0,2 секунды до загрузки.
Вероятно, поэтому он (уже )работал на AMD/Radeon и :имел DRM_RADEON=y
и CONFIG_DRM=y
.
ОБНОВЛЕНИЕ:Я нашел другой способ:
если вы хотите оставить i915
и drm
как модули ядра, просто убедитесь, что /etc/mkintcpio.conf
имеетMODULES=(i915 drm fbcon)
(не уверен, что все нужны, если честно )и (это, вероятно, не нужно)/etc/modules-load.d/i915.conf
содержит i915
в одной строке.
Этот метод также работает, но самая старая видимая строка dmesg находится через 4,3 секунды после загрузки (по сравнению с 0,2 секунды для -ядра i915/drm )
^ Другими словами, убедитесь, что в образе initrd/initramfs есть те модули, которые ядро kexec загружает на ранней стадии при запуске.
Во-первых, вы предполагаете, что медлительность вызвана полным RAM
, что не обязательно является первопричиной.Теоретически должны быть другие причины и узкие места, которые могли бы привести к замедлению, такие как чрезмерное I/O
, слишком много processes
ожидающих ЦП и т. д., и вы должны сначала исключить другие причины, прежде чем решить, что виновником является память. Вы можете использовать команду vmstat
, например:
$ vmstat -w 1
procs -----------------------memory---------------------- ---swap-- -----io---- -system-- --------cpu--------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 120951240 9412 8313416 0 0 0 2 0 0 0 0 100 0 0
0 0 0 120951248 9412 8313416 0 0 0 0 143 210 0 0 100 0 0
0 0 0 120950980 9412 8313416 0 0 0 20 116 238 0 0 100 0 0
0 0 0 120950980 9412 8313416 0 0 0 0 180 315 0 0 100 0 0
0 0 0 120951232 9412 8313416 0 0 0 0 145 285 0 0 100 0 0
Если вы видите относительно высокие числа в секции swap
-si
(swap in
)или so
(swap out
)-, это может указывать на то, что система работает над подкачкой страниц памяти из RAM
в или из swap
. Если значения там низкие, вероятно, есть другая причина медлительности (, которую вы, вероятно, могли видеть в procs
, io
илиcpu
).
Если предположить, что вы видите высокие значения swap in/out
в vmstat
, это указывает на то, что узким местом действительно является заполнение RAM
.
Вот описание swappiness
из документации ядра Linux:
swappiness
This control is used to define how aggressive the kernel will swap memory pages. Higher values will increase aggressiveness, lower values decrease the amount of swap. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone.
The default value is 60.
Во-первых, обратите внимание, что ваше swappiness
значение(10
)значительно ниже значения по умолчанию(60
).
Допустим, у вашего firefox
много вкладок; Большинство из них простаивают и мало используются. Если значение swappiness
низкое, машина будет стараться максимально удерживать свои данные в ОЗУ и избегать выгрузки, пока ей действительно не понадобится освободить часть памяти для новых страниц; Это означает, что машина начнет подкачку только в случае необходимости, и тогда может быть слишком поздно, и в этот момент вы увидите некоторое отставание в ожидании выгрузки старых страниц памяти.
Если значение swappiness
выше, система будет чаще и раньше времени выгружать старые и незанятые страницы памяти, оставляя больше свободной памяти для новых страниц. Когда вы снова получите доступ к этим вкладкам, они будут перемещаться по памяти с диска в ОЗУ, поэтому это может быть медленнее, но, поскольку вы не используете эти вкладки очень часто, лучше оставить их в свопе и оставить больше свободных страниц памяти для новых процессов..
Я бы предложил увеличить ваш swappiness
,поэтому старые и неиспользуемые страницы памяти выгружаются чаще, а не только тогда, когда память достигает своего предела.