Al configurar manualmente un kernel puede encontrarse con muchas opciones con las que aun haciendo uso de la ayuda no que totalmente claro que es o para que sirve. Un ejemplo de esto es la opción [ ] MTRR (Memory Type Range Register) support que se encuentra dentro del menú Processor type and features.
1.- ¿Qué es MTRR (Memory Type Range Register)?
MTRR es un método de dividir los recursos de memoria con el objetivo de manejar-la de forma más efectiva y eficientemente. Puede verificar como su procesador tiene este característica simplemente comprobando los flags del mismo; con el comando cat /proc/cpuinfo lo que le arrojará algo similar a:
agd-desktop # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping : 5 cpu MHz : 2664.602 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips : 5329.20 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
MTRR también se encarga de mapear las localizaciones de los componentes PCI y AGP del sistema así como habilitar la escritura combinada, lo que a veces se puede traducir en aumentos de rendimientos.
MTRR posee cuatro modos de acceso a la memoria:
- uncachable, se deshabilita el acceso a la cache y los buffers; es por tanto el modo menos eficiente. Se utiliza normalmente para la memoria de mapeado E/S.
- write-through, los datos se escriben simultáneamente en la cache de la CPU y la memoria RAM.
- Write-combining, los datos en lugar de ser enviados inmediatamente como pequeños bloques de bits individuales, se almacenan y combinan temporalmente en un buffer para posteriormente ser enviados en ráfagas. Es un modo que da buenos resultados con tarjetas gráficas AGP
- write-protect, no se permite la escritura.
- write-back, los datos se escriben en la cache de la CPU, y en caso de ser necesario pasan a la memoria RAM. Es el modo más eficiente.
Los procesadores actuales de Intel y AMD pueden operar con un máximo de ocho regiones MTRR. Puede obtener más información en la documentación del kernel: Linux Kernel Documentation :: mtrr.txt.
2.- Obtener información de la regiones MTRR definidas por el kernel
Para obtener información acerca de las regiones MTRR puede comenzar por consultar el archivo de registro generado durante el arranque del kernel. En el caso que nos ocupa, este registro se almacena en /var/log/kernel.log. Si desea aprender más sobre el registro de eventos del sistema, puede leer el artículo Gestión de archivos de registro del sistema.
A continuación se muestra la información, en relación a MTRR, arrojada por un kernel no configurado correctamente:
[ 0.000000] MTRR default type: uncachable [ 0.000000] MTRR fixed ranges enabled: [ 0.000000] 00000-9FFFF write-back [ 0.000000] A0000-BFFFF uncachable [ 0.000000] C0000-CDFFF write-protect [ 0.000000] CE000-EFFFF uncachable [ 0.000000] F0000-FFFFF write-through [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 000000000 mask F00000000 write-back [ 0.000000] 1 base 0E0000000 mask FE0000000 uncachable [ 0.000000] 2 base 0D0000000 mask FF0000000 uncachable [ 0.000000] 3 base 100000000 mask F00000000 write-back [ 0.000000] 4 base 1C0000000 mask FC0000000 uncachable [ 0.000000] 5 base 1B0000000 mask FF0000000 uncachable [ 0.000000] 6 disabled [ 0.000000] 7 disabled [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106Como puede observar, el kernel ha activado seis de las ocho regiones MTRR posibles, y desactivado dos de ellas.
Además puede consultar el archivo mtrr del sistema de archivos virtual /proc. A continuación se muestra la información contenida en este archivo en un sistema cuyo kernel no tiene activada la limpieza de regiones MTRR.
agd-desktop # cat /proc/mtrr reg00: base=0x000000000 ( 0MB), size= 4096MB, count=1: write-back reg01: base=0x0e0000000 ( 3584MB), size= 512MB, count=1: uncachable reg02: base=0x0d0000000 ( 3328MB), size= 256MB, count=1: uncachable reg03: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back reg04: base=0x1c0000000 ( 7168MB), size= 1024MB, count=1: uncachable reg05: base=0x1b0000000 ( 6912MB), size= 256MB, count=1: uncachable
Esta configuración no es óptima porque tiene demasiadas regiones uncachable, las cuales, como ya se ha visto, ofrecen un rendimiento menor a las regiones de tipo write-back.
3.- Configurar el kernel
A continuación podrá ver como deben quedar fijadas las opciones.
┌────────────────────── Processor type and features ──────────────────────┐ │ Arrow keys navigate the menu. <Enter> selects submenus --->. │ │ Highlighted letters are hotkeys. Pressing <Y> includes, <N> excludes, │ │ <M> modularizes features. Press <Esc><Esc> to exit, for Help, </> │ │ for Search. Legend: [*] built-in [ ] excluded <M> module < > │ │ ┌────^(-)─────────────────────────────────────────────────────────────┐ │ │ │ -*- MTRR (Memory Type Range Register) support │ │ │ │ [*] MTRR cleanup support │ │ │ │ (1) MTRR cleanup enable value (0-1) │ │ │ │ (1) MTRR cleanup spare reg num (0-7) │ │ │ │ [ ] EFI runtime service support │ │ │ │ [*] Enable seccomp to safely compute untrusted bytecode │ │ │ │ [*] Enable -fstack-protector buffer overflow detection (EXPERIMEN│ │ │ │ Timer frequency (1000 HZ) ---> │ │ │ │ [ ] kexec system call │ │ │ │ [ ] kernel crash dumps │ │ │ └────v(+)─────────────────────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────────────────────┤ │ <Select> < Exit > < Help > │ └─────────────────────────────────────────────────────────────────────────┘
Y lo que queda registrado, respecto a MTRR, en /var/log/kernel.log al iniciarse el kernel:
[ 0.000000] MTRR default type: uncachable [ 0.000000] MTRR fixed ranges enabled: [ 0.000000] 00000-9FFFF write-back [ 0.000000] A0000-BFFFF uncachable [ 0.000000] C0000-CDFFF write-protect [ 0.000000] CE000-EFFFF uncachable [ 0.000000] F0000-FFFFF write-through [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 000000000 mask F00000000 write-back [ 0.000000] 1 base 0E0000000 mask FE0000000 uncachable [ 0.000000] 2 base 0D0000000 mask FF0000000 uncachable [ 0.000000] 3 base 100000000 mask F00000000 write-back [ 0.000000] 4 base 1C0000000 mask FC0000000 uncachable [ 0.000000] 5 base 1B0000000 mask FF0000000 uncachable [ 0.000000] 6 disabled [ 0.000000] 7 disabled [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] original variable MTRRs [ 0.000000] reg 0, base: 0GB, range: 4GB, type WB [ 0.000000] reg 1, base: 3584MB, range: 512MB, type UC [ 0.000000] reg 2, base: 3328MB, range: 256MB, type UC [ 0.000000] reg 3, base: 4GB, range: 4GB, type WB [ 0.000000] reg 4, base: 7GB, range: 1GB, type UC [ 0.000000] reg 5, base: 6912MB, range: 256MB, type UC [ 0.000000] total RAM covered: 6144M [ 0.000000] Found optimal setting for mtrr clean up [ 0.000000] gran_size: 64K chunk_size: 64K num_reg: 6 lose cover RAM: 0G [ 0.000000] New variable MTRRs [ 0.000000] reg 0, base: 0GB, range: 2GB, type WB [ 0.000000] reg 1, base: 2GB, range: 1GB, type WB [ 0.000000] reg 2, base: 3GB, range: 256MB, type WB [ 0.000000] reg 3, base: 4GB, range: 2GB, type WB [ 0.000000] reg 4, base: 6GB, range: 512MB, type WB [ 0.000000] reg 5, base: 6656MB, range: 256MB, type WBPor último podemos comprobar como los modos y tamaños definidos por el kernel para los cinco rangos MTRR activos han cambiado:
agd-desktop # cat /proc/mtrr reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x0c0000000 ( 3072MB), size= 256MB, count=1: write-back reg03: base=0x100000000 ( 4096MB), size= 2048MB, count=1: write-back reg04: base=0x180000000 ( 6144MB), size= 512MB, count=1: write-back reg05: base=0x1a0000000 ( 6656MB), size= 256MB, count=1: write-back
4.- Optimizar el valor de MTRR cleanup spare reg num
El valor por defecto para esta opción es 1, sin embargo se pueden usar otros valores para optimizar aun más la gestión de memoria. Sin embargo deberá tener cuidado ya que valores superiores a 5 suelen derivar en un funcionamiento incorrecto y el kernel arrojará errores en su arranque:
[ 0.000000] mtrr_cleanup: can not find optimal value [ 0.000000] please specify mtrr_gran_size/mtrr_chunk_size
Si desea buscar valores óptimos, la mejor opción es dejar en compilado el spare reg num en 1 -(1) MTRR cleanup spare reg num (0-7)- y cambiar estos valores durante el arranque del propio kernel a través de grub. Para ello tan solo deberá de añadir mtrr_spare_reg_nr=X. A continuación podrá ver un ejemplo:
Sin pasar ninguna opción al kernel:
title Gentoo Linux 3.0.6-V.0.2 root (hd0,0) kernel /boot/kernel-3.0.6-V.0.2 root=/dev/sda2 init=/sbin/bootchartdIndicando al kernel que modifique el spare reg num a 2:
title Gentoo Linux 3.0.6-V.0.2 root (hd0,0) kernel /boot/kernel-3.0.6-V.0.2 root=/dev/sda2 init=/sbin/bootchartd mtrr_spare_reg_nr=2
PD: No espere que este tipo de micro-optimización haga que su ordenador vuele.
9 comentarios:
#-
danitool
dijo...
-
-
sábado, 12 de noviembre de 2011, 14:14:00 CET
#
-
Unknown
dijo...
-
-
lunes, 14 de noviembre de 2011, 19:38:00 CET
#
-
danitool
dijo...
-
-
lunes, 14 de noviembre de 2011, 23:35:00 CET
#
-
Unknown
dijo...
-
-
martes, 15 de noviembre de 2011, 19:30:00 CET
#
-
danitool
dijo...
-
-
martes, 15 de noviembre de 2011, 21:48:00 CET
#
-
Unknown
dijo...
-
-
miércoles, 16 de noviembre de 2011, 16:43:00 CET
#
-
danitool
dijo...
-
-
miércoles, 16 de noviembre de 2011, 18:36:00 CET
#
-
Unknown
dijo...
-
-
miércoles, 16 de noviembre de 2011, 20:43:00 CET
#
-
laptop toshiba
dijo...
-
-
martes, 7 de febrero de 2012, 1:26:00 CET
Y que hay de crear manualmente las entradas MTRR?
Ejemplo, basándome en la información que devuelve lspci -v sobre la tarjeta gráfica
01:00.0 VGA compatible controller: nVidia Corporation NV31M [GeForce FX Go5650] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Dell Device 019c
Flags: bus master, VGA palette snoop, 66MHz, medium devsel, latency 248, IRQ 11
Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
Memory at d0000000 (32-bit, prefetchable) [size=256M]
[virtual] Expansion ROM at fd000000 [disabled] [size=128K]
Capabilities:
Kernel driver in use: nvidia
Kernel modules: nvidia, nvidiafb, nouveau
echo "base=0xd0000000 size=0x10000000 type=write-combining" >| /proc/mtrr
Aunque según la gente de Nvidia
if you are using the NVIDIA Linux graphics driver, you do not need to manually configure MTRRs, the driver will take the steps necessary to ensure mappings of both system memory and GPU BARs have the correct memory types.
Además, otra cosa interesante, PAT que es una instrucción de procesador íntimamente relacionada con MTRR, en los últmos kernels lo han deshabilitado en procesadores antiguos (el caso de mi Pentium M)
arch/x86/kernel/cpu/intel.c :
/*
* There is a known erratum on Pentium III and Core Solo
* and Core Duo CPUs.
* " Page with PAT set to WC while associated MTRR is UC
* may consolidate to UC "
* Because of this erratum, it is better to stick with
* setting WC in MTRR rather than using PAT on these CPUs.
*
* Enable PAT WC only on P4, Core 2 or later CPUs.
*/
if (c->x86 == 6 && c->x86_model < 8)
clear_cpu_cap(c, X86_FEATURE_PAT);
Parece ser que por seguridad está deshabilitado por un posible fallo en algunos modelos. El pentium M es un modelo 9, por tanto he cambiado la linea x86_model < 8
para impedir que deshabilite PAT. El resultado es que compilando de nuevo el kernel, tengo esa instruccion habilitada, y parece que mejora ligeramente el funcionamiento del la tarjeta gráfica.
Más informacion en profundidad sobre este tema seria interesante, a veces no sé si realmente cambiar estos parametros vale la pena
Si estas usando el driver de nvidia, ejecutar el comando echo "base=0xd0000000 size=0x10000000 type=write-combining" >| /proc/mtrr no tiene ningún efecto puesto que el propio driver se encarga de crear dicha región mtrr.
Puedes comprobar-lo reiniciando el PC y ejecutando cat /proc/mtrr, verás como ya existe dicha región sin necesidad de ejecutar ningún comando.
Respecto a activar PAT, de acuerdo a los responsables del kernel no es buena idea hacerlo en tu micro; aunque obviamente si lo has probado y no te da problemas; perfecto.
Pues no, usando el driver de nvidia no se crean esas regiones para la gráfica, al menos no aparecen en /proc/mtrr
Comprobado en dos ordenadores con driver nvidia, en uno con una nvidia de última generación.
cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x0c0000000 ( 3072MB), size= 128MB, count=1: write-back
sin embargo las direcciones donde habría una de esas regiones no se corresponden con ninguna de la gráfica
Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at ce000000 (64-bit, prefetchable) [size=32M]
además de que sería una región tipo write-combining..
Tal vez, y me da la sensación de que es así, los drivers de nvidia efectúan esa "reserva" de memoria pero a su forma y sin mostrarlo en la tabla /proc/mtrr.
Sobre PAT, activado y ni un solo problema, compilando en el ordenador, con una carga al 100 por cien de memoria y de cpu. Incluso la suspensión y reanudación funcionan perfectamente. Simplemente pienso que como es imposible detectar que CPUs se ven afectadas exactamente por los posibles bugs lo han deshabilitado.
Otra instrucción que también está deshabilitada aunque no tiene que ver con la gestión de memoria es NOPL, Deshabilitado en la arquitectura de 32 bits, solo disponible para 64 bits. Yo la he habilitado para probar, aunque me da que la instrucción no es usada por ningún software (creo que los compiladores también lo han deshabilitado para arquitecturas de 32 bits...)
La verdad que estos temas son un poco oscuros, aunque interesantes.
Saludos
Correcto, fallo mio, en /proc/mtrr no aparece nada. Parece ser que, como tu mismo has indicado, el driver de nvidia lo hace todo solo, sin informar al kernel.
En referencia al PAT, no se si será el caso pero miré en un viejo portátil, con un Pentium M, y no tenía soporte para PAT.
root@notebook:/# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.73GHz
stepping : 8
cpu MHz : 800.000
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts est tm2
bogomips : 1599.04
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:
Respecto a la instrucción NOPL, si tu procesador es de 32 bits, activar dicha opción no debería tener sentido; puesto que tu procesador no tendrá dicha instrucción. Verifica-lo en las flags que te arroja /proc/cpuinfo.
Bien, empezaré diciendo que si no habilitas PAT, no aparecerá en los flags /proc/cpuinfo. Solo cuando lo habilitas es cuando mostrará esa instrucción, así que..
Lo mismo con NOPL, o cualquier otra instrucción, si el kernel no la habilita no aparece en cpuinfo...
Quizás la forma correcta sería usando dmidecode. Como bien apuntas no parece que mi procesador tenga NOPL
Pero desde luego sí que tiene PAT.
[root@tool dani]# dmidecode |grep PAT
PAT (Page attribute table)
[root@tool dani]# dmidecode |grep NOPL
[root@tool dani]#
Las flags que aparecen en /proc/cpuinfo son cualidades del procesador e indican que instrucciones especiales posee, como por ejemplo una unidad de coma flotante (fpu), un juego de instrucciones de virtualización (vmx|svm) o el juego de instrucciones mtrr y pat. Es decir, si tu procesador tiene instrucciones para mtrr y pat, independientemente de que tengas o no compilado en el kernel soporte para mtrr y pat, dicha flags siempre estará presente. Aunque si no compilas el soporte para la flag X, no podrás sacar partido de ellas.
¿Cómo se genera la información contenida en /proc/cpuinfo?
El kernel, a través de CPUID (man cpuid), le pregunta al procesador que tipo de procesador es, familia, modelo, cache... y por supuesto pregunta que juegos de instrucciones posee. Toda esta información se almacena en /proc/cpuinfo y /sys/devices/system/cpu para que sea accesible facilmente. NOTA: Para que el kernel pueda preguntarle al procesador por sus características, debe compilarse el soporte para cpuid: <*> /dev/cpu/*/cpuid - CPU information support .
El procesador devuelve un identificador de instrucción cpuid (un número). Y el kernel se encarga de traducir este número a una palabra legible por humanos; de tal forma que si el procesador devuelve 0*32+12 el kernel lo traduce como MTRR, 0*32+16 es traducido como PAT... NOTA: En /usr/src/linux/arch/x86/include/asm/cpufeature.h hay una lista con las traducciones del código cpuid devuelto por el procesador.
Resumiendo, el kernel pregunta al procesador por los flags de los que dispone (cpuid), traduce el valor devuelto por la cpu a una palabra (cpufeature.h) y posteriormente coloca esta información en /proc/cpuinfo. No importa si no tienes compilado el soporte para X flag, si el procesador posee dicha flag aparecerá reflejado en /proc/cpuinfo. Aunque obviamente si no compilas el soporte para la flag X no podrás hacer uso de ella.
Por otro lado dmidecode obtiene su información de la placa base, a quien pregunta por el hardware instalado. En situaciones normales la salida de dmidecode -t processor y /proc/cpuinfo deben ser idénticas; aunque pueden aparecer divergencias cuanto se hace overclock o si usas un kernel xen.
Sí, dmidecode puede no informar acerca de todos los flags (APIC por ejemplo no me lo muestra), pero de todos los que informa al menos sí que son flgags que la cpu tiene.
Todo lo que explicas es una teoria muy bonita pero, cojamos un ejemplo práctico donde hago un par de cambios en el código del kernel (3.0):
sed -i "108s/15/8/g" arch/x86/kernel/cpu/intel.c
sed -i "731s/clear/set/g" arch/x86/kernel/cpu/common.c
Cambios que no fuerzan la habilitacion, ni son un "maquillaje" sino que simplemente impiden la desabilitación de estos flags. No tenia ni PAT ni NOPL en cpuinfo. Una vez hecha la modificacion y compilado el kernel tengo en mi viejo Pentium M tenemos lo siguiente:
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 9
model name : Intel(R) Pentium(R) M processor 1500MHz
stepping : 5
cpu MHz : 600.000
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe bts nopl est tm2
bogomips : 1199.05
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
Bien en el caso de PAT está más que claro que es soportada la instrucción, y únicamente mostrada si la habilitamos en el kernel.
Acerca de cpuid, no sé como interactua con el kernel la verdad, desde luego el modulo lo tengo por defecto compilado... La utilidad cpuid también muestra que PAT está presente, aunque sobre NOPL no parece haber nada.
Resumiendo, cpuinfo muestra lo que le da la gana al kernel mostrar, dmidecode muestra lo que le da la gana a la placa (bios) mostrar, y la utilidad cpuid pues mostrara todo si es que hace lo que dice y le pregunta al procesador, pero si resulta que le pregunta al procesador a través del kernel estaremos en las mismas (realmente le estaria preguntando al kernel.. y quien sabe éste como implementa la "pregunta").
No he probado a meter un kernel no modificado y ejecutar cpuid para ver si muestra el flag PAT como disponible, supongo que me diria lo que ya sé, que dispongo de esa instruccion, o bien, no aparecería por tener un kernel que la deshabilita.
Resumiendo tengo PAT, el cual si que mejora el rendimiento (ligeramente), y NOPL tal vez aunque sería una instrucción inutil para mi sistema.
El ejemplo práctico que has tomado ni es real ni justo. Estas modificando el código fuente para alterar el comportamiento normal del kernel. En cualquier caso entiendo lo que quieres decir: que el kernel puede bloquear el uso de determinadas instrucciones del procesador, pero es algo normal e incluso el usuario puede puede desactivar una flag determinada en tiempo de arranque pasando el parámetro clearcpuid=XXX al kernel.
Pero no lo considero un ejemplo válido, sino más bien una excepción. Una excepción que tiene sus motivos y que están documentadas dentro del propio código fuente del kernel. En él, los hackers explican que bloquean las instrucciones PAT en los procesadores X debido a un bug de dicha instrucción.
Sin embargo es obvio que los programadores no supieron determinar que procesadores estaban afectados por dicho bug y decidieron inhabilitar la instrucción PAT en todos los modelos de procesadores anteriores a los Pentium 4 (modelo 15). Porque tal y como tu has dicho, has quitado el bloqueo, y actualmente usas PAT sin problemas.
Respecto a la triquiñuela para mostrar NOPL como una flag válida, no deja de ser una triquiñuela, y eso no es lo que discutimos. No tiene sentido que modifiquemos el kernel para que informe que la cpu funciona a 100 Ghz y después afirmemos que el kernel informa mal de las especificaciones de la cpu.
Las flags del procesador siempre aparecen en /proc/cpuinfo, sin necesidad de activar nada en el kernel aunque como tu mismo has demostrado existen casos excepcionales y algunas flags son bloqueadas y desactivadas a conciencia por los programadores del kernel por X motivos.
De hecho te propongo una prueba para ver que las flags que aparecen en /proc/cpuinfo no las proporciona el kernel sino la cpu. Compila un kernel sin soporte para mtrr, arranca dicho kernel y comprueba las flags que arroja /proc/cpuinfo. Comprobarás que seguirá informando de que tiene soporte para mtrr, aunque el kernel no sepa qué es o que hacer con esa instrucción.
Respecto a que tienes PAT activo, no cabe ninguna duda. Y con tu caso veo claro que he de dar más importancia a dmidecode. Ya que si existen discrepancias entre lo que dice dmidecode y lo que dice /proc/cpuinfo está claro que algo raro esta ocurriendo. E imagino que así es como te diste cuenta de que algo pasaba con las instrucciones pat de tu procesador. En cualquier caso chapó por ti, primero por darte cuenta (que es lo más difícil) y después por eliminar el bloqueo.
Buen aporte, queria optimizar mi kernel
Publicar un comentario