He visto algunos informes de errores y preguntas (en stackexchange y en otros lugares) con respecto a una molestia "BUG: soft lockup - CPU#<n> stuck for <dt>s!". Hasta ahora, no he encontrado ninguna pista sobre qué hacer o probar (más bien, las pistas que he encontrado y seguido no han impedido que esto suceda). Estoy más preocupado por esto porque:
- La frecuencia de estos eventos parece haber aumentado lentamente últimamente (más de 700 por mes),
yum updatey reiniciar lo ralentizó un poco por un tiempo, pero he visto que algunos bloqueos comienzan a suceder nuevamente,- varios procesos (si no todo el host, es difícil de distinguir), sin duda, incluso todos mis shells interactivos están congelados durante un cierto tiempo cuando sucede,
- No estoy seguro de si está relacionado, pero veo muchos registros / mensajes relacionados con ntpd que no pueden actualizar el reloj.
Lo siguiente es un extracto de $(grep 'soft lockup' /var/log/messages*):
Mar 22 10:02:35 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [kjournald:1048]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:40 localhost kernel: BUG: soft lockup - CPU#15 stuck for 25s! [swapper:0]
Mar 22 15:42:16 localhost kernel: BUG: soft lockup - CPU#8 stuck for 25s! [kjournald:1048]
Mar 22 18:22:13 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [postgres:21356]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#7 stuck for 10s! [java:8653]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#8 stuck for 72s! [kjournald:1048]
Mar 22 21:21:37 localhost kernel: BUG: soft lockup - CPU#12 stuck for 29s! [kjournald:1048]
Mar 22 21:22:07 localhost kernel: BUG: soft lockup - CPU#12 stuck for 27s! [kjournald:1048]
Mar 23 02:01:47 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [kblockd/8:276]
Mar 23 02:02:22 localhost kernel: BUG: soft lockup - CPU#8 stuck for 34s! [kblockd/8:276]
Esto le sucede a los procesos aleatorios y parece estar bastante bien distribuido en los 16 "núcleos" de ese host virtual.
El host es una instancia de AWS EC2 "cc1.4xlarge", con un AMI llamado "EC2 CentOS 5.5 GPU HVM AMI (Driver 260.19.29) (ami-42a2532b)". Parece estar virtualizado con Xen.
cat /etc/redhat-releaserendimientos CentOS release 5.9 (Final). 'free'reporta 21G de RAM.
El jefe de dmesges:
Linux version 2.6.18-348.3.1.el5 ([email protected]) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)) #1 SMP Mon Mar 11 19:39:25 EDT 2013
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tty0 console=ttyS0,115200n8
BIOS-provided physical RAM map:
BIOS-e820: 0000000000010000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 00000005dd800000 (usable)
DMI 2.4 present.
DMI: Xen HVM domU, BIOS 3.4.3-2.6.18 08/29/2012
ACPI: RSDP (v002 Xen ) @ 0x00000000000ea020
ACPI: XSDT (v001 Xen HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0062b0
ACPI: FADT (v004 Xen HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005ee0
ACPI: MADT (v002 Xen HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005fe0
ACPI: SRAT (v001 Xen HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0060c0
ACPI: SLIT (v001 Xen HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006240
ACPI: HPET (v001 Xen HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006270
ACPI: DSDT (v002 Xen HVM 0x00000000 INTL 0x20090220) @ 0x(null)
A continuación se muestra un recuento acumulativo de estos bloqueos "blandos" en el tiempo reciente (la línea roja es cuando lo hice la última yum updateseguido de reboot):
.
A continuación se muestra el histograma de duración (cuánto tiempo se ha quedado atascado el anfitrión):
.
fuente
Respuestas:
También tengo este problema en Xen 4.2 con 3.6 y 3.8 Kernel (AlpineLinux).
Busqué en Google y al agregar clocksource = jiffies a mi kernel lo arreglé. En lugar de jiffies, también puedes probar "hoyo".
También hay informes de deshabilitación de estados C en el BIOS .
fuente
Tuve el mismo problema con mi Thinkpad T520. Pero en lugar de cortar el kernel, hice algo más simple. En primer lugar, estoy usando Centos7, instalé el sistema base, todo funcionó bien. Luego agregué la GUI de GNOME más tarde, que es cuando comencé a tener los problemas mencionados anteriormente. Noté que muchos fabricantes configuraron las instalaciones de Windows. La tarjeta gráfica generalmente está configurada para Win7 (NVIDIA OPTIMUS). La restablecí al modo gráfico integrado y no colgué más errores. ¿Cómo hacerlo? Reinicie su Thinkpad presione F1 o el botón azul thinkvantage para ingresar al BIOS. Vaya a gráficos, seleccione gráficos integrados y luego F10 para guardar y salir. Hay 3 configuraciones para esta tarjeta: integrada, discreta y NVIDIA OPTIMUS (¿solo Win7?) ¿Espero que esto ahorre algo de tiempo?
fuente