Lo hice y lo entendí

El blog de Vicente Navarro
06 oct

Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux

Continuando con Sobre las VIA EPIA (IV): Placas con procesador C7 / La EX10000EG, vamos a ver las cosas que tenemos que tocar en nuestro Linux (en mi caso Debian Etch con un kernel 2.6.22.6 personalizado) para sacar el máximo provecho de esta placa.

IDE

Podemos empezar con la controladora de discos IDE/UDMA, que es la que yo estoy usando con un disco de 2.5″ de 120GB. El módulo necesario del kernel lo encontramos dentro del “make menuconfig” en:

Device Drivers → ATA/ATAPI/MFM/RLL support → Generic PCI bus-master DMA support → VIA82CXXX chipset support

via82cxx

El módulo que se crea es el via82cxxx. Durante la carga el chipset y la controladora son reconocidos, así como el mejor modo de transferencia admitido:

VP_IDE: IDE controller at PCI slot 0000:00:0f.0
VP_IDE: chipset revision 0
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA cx700 (rev 00) IDE UDMA133 controller on pci0000:00:0f.0
    ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:pio
hdc: WDC WD1200BEVE-11UYT0, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
hdc: max request size: 512KiB
hdc: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=16383/255/63, UDMA(100)
hdc: cache flushes supported
 hdc: hdc1 hdc2 <&lt:6>ACPI: PCI Interrupt 0000:00:10.1[B] -> GSI 22 (level, low) -> IRQ 17

El incremento de rendimiento es espectacular si lo comparamos con el que nos proporciona el kernel de Debian estándar (2.6.18-5-686), que no incluye este módulo:

# hdparm -tT /dev/hdc

/dev/hdc:
 Timing cached reads:   582 MB in  2.00 seconds = 290.56 MB/sec
 Timing buffered disk reads:   12 MB in  3.54 seconds =   3.39 MB/sec
# hdparm -tT /dev/hdc

/dev/hdc:
 Timing cached reads:   582 MB in  2.01 seconds = 290.08 MB/sec
 Timing buffered disk reads:  138 MB in  3.03 seconds =  45.55 MB/sec

Hay que tener en cuenta que en ambos casos las pruebas están hechas sin usar ninguna de las opciones del hdparm que podrían aumentar el rendimiento, muy especialmente en el primero de los casos.

Fijémonos, asimismo, en que el único conector IDE de la placa se corresponde al secundario de otras placas de tamaño estándar, ya que, como vemos, el disco adopta el fichero de dispositivo /dev/hdc y no el /dev/hda. Esto también lo podemos ver en la salida de la BIOS durante el arranque.

SATA

Si tenemos un disco SATA, el módulo necesario es el sata_via, que podemos habilitar en:

Device Drivers → Serial ATA (prod) and Parallel ATA (experimental) drivers → VIA SATA support

sata-via

Ethernet

Las placas VIA EPIA actuales pueden tener dos tipos de NIC, el VIA Rhine (100Mbps) y el VIA Velocity (1Gpbs). La EX10000G normalmente lleva un interfaz Rhine, pero se puede pedir con uno Velocity opcional.

Los respectivos módulos via_rhine y via_velocity se configuran en:

Device Drivers → Network device support → Ethernet (10 or 100Mbit) → EISA, VLB, PCI and on board controllers → VIA Rhine support

Device Drivers → Network device support → Ethernet (1000Mbit) → VIA Velocity support

via-rhine

via-velocity

Audio

El procesador de audio de esta placa es el VIA Vinyl VT1708A High Definition Audio Codec, que cumple con la Intel® High Definition Audio Rev. 1.0 specification, por lo que el módulo que necesitamos es el snd_hda_intel de ALSA, incluido en las últimas versiones del kernel. Podemos leer información detallada sobre este driver y su uso en ALSA: The module options for snd-hda-intel.

Device Drivers → Sound → Advanced Linux Sound Architecture → PCI Devices → Intel HD Audio

snd-hda-intel

Sensores

Ya habíamos comentado en el artículo anterior (Sobre las VIA EPIA (IV): Placas con procesador C7. La EX10000EG.) que esta placa no tiene sensores, pero si ejecutamos el sensors-detect, nos propone añadir los siguientes módulos al /etc/modules.

# Generated by sensors-detect on Tue Sep 11 20:27:19 2007
# I2C adapter drivers
i2c-viapro
eeprom

El primero (i2c-viapro) lo encontramos en:

Device Drivers → I2C support → I2C Hardware Bus support → VIA VT82C596/82C686/82xx and CX700

y el segundo (eeprom) en:

Device Drivers → I2C support → Miscellaneous I2C Chip support → EEPROM reader

¿Para qué los queremos? Pues como leemos en la ayuda del módulo eeprom, para poder leer la información de SPD de los módulos de memoria del sistema:

CONFIG_SENSORS_EEPROM:
  
   If you say yes here you get read-only access to the EEPROM data
   available on modern memory DIMMs and Sony Vaio laptops.  Such
   EEPROMs could theoretically be available on other devices as well. 

¿Y cómo podemos hacerlo? Pues con el script decode-dimms.pl incluido en el paquete lm-sensors en Debian, tal y como leemos en SPD information under Linux:

# /usr/share/doc/lm-sensors/examples/eeprom/decode-dimms.pl

Memory Serial Presence Detect Decoder
By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,
Jean Delvare and others
Version 2.10.1


Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/0-0050
Guessing DIMM is in                             bank 1

---=== SPD EEPROM Information ===---
EEPROM Checksum of bytes 0-62                   OK (0xE1)
# of bytes written to SDRAM EEPROM              128
Total number of bytes in EEPROM                 256
Fundamental Memory type                         DDR2 SDRAM
SPD Revision                                    1.0

---=== Memory Characteristics ===---
Maximum module speed                            930MHz (PC7400)
Size                                            512 MB
tCL-tRCD-tRP-tRAS                               5-4-4-12
Supported CAS Latencies                         5, 4, 3
Minimum Cycle Time (CAS 5)                      3.75 ns
Maximum Access Time (CAS 5)                     0.5 ns
Minimum Cycle Time (CAS 4)                      3.75 ns
Maximum Access Time (CAS 4)                     0.5 ns
Minimum Cycle Time (CAS 3)                      5 ns
Maximum Access Time (CAS 3)                     0.6 ns

---=== Manufacturing Information ===---
Manufacturer                                    MemorySolutioN
Manufacturing Location Code                     1
Part Number                                     TMS51B264C081534AE
Manufacturing Date                              0x070A


Number of SDRAM DIMMs detected and decoded: 1

CPU

Es importante también configurar el tipo correcto de CPU.

Processor type and features → Processor family → VIA C7

Kernel VIA C7

Generador de números aleatorios

El generador de números aleatorios por hardware del procesador VIA se activa con el módulo via_rng. El módulo no se carga automáticamente durante el arranque, de modo que lo mejor es que lo incluyamos en el /etc/modules.

Device Drivers → Character devices → Hardware Random Number Generator Core support → VIA HW Random Number Generator support

via-rng

Gestión de la frecuencia del procesador

No debemos olvidarnos del driver para poder modificar la frecuencia de reloj del procesador, aunque en esta placa es bastante innecesario, ya que dado su diseño de bajo consumo, apenas ahorramos en gasto eléctrico y sí perdemos mucho en prestaciones en un sistema en el que ya pueden ser de por sí justitas. Habilitamos el módulo e_powersaver en:

Power management options (ACPI, APM) → CPU Frequency scaling → VIA C7 Enhanced PowerSaver (EXPERIMENTAL)

VIA cpufreq driver

Y podemos comprobar que, sin el driver, el comando cpufreq-info no nos da ninguna información:

# cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to linux@brodo.de, please.
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU

Y una vez que lo cargamos ya nos es posible gestionar la frecuencia del procesador:

# modprobe e_powersaver
# cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to linux@brodo.de, please.
analyzing CPU 0:
  driver: e_powersaver
  CPUs which need to switch frequency at the same time: 0
  hardware limits: 800 MHz - 1.00 GHz
  available frequency steps: 800 MHz, 1.00 GHz
  available cpufreq governors: performance
  current policy: frequency should be within 800 MHz and 1.00 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 1.00 GHz (asserted by call to hardware).

En la salida del dmesg encontramos estas líneas tras cargar el módulo:

eps: Detected VIA C7
eps: Current voltage = 1004mV
eps: Current multiplier = 10
eps: Highest voltage = 1004mV
eps: Highest multiplier = 10
eps: Lowest voltage = 956mV
eps: Lowest multiplier = 8
Bit NX

El bit NX sirve para marcar las áreas de la memoria que son de datos, no de código. Un procesador que soporte este bit no ejecutará nunca código situado en áreas de datos previniendo así ataques de buffer overflow.

Los procesadores VIA C7 soportan el bit NX, y el kernel de Linux también lo hace por defecto en versiones recientes. Para controlar su uso, podemos usar el parámetro del kernel noexec, tal y como leemos en Documentation/kernel-parameters.txt:

noexec          [IA-32,X86-64]
                noexec=on: enable non-executable mappings (default)
                noexec=off: disable nn-executable mappings

Podemos verificar que el bit está disponible examinando el campo flags del fichero /proc/cpuinfo:

# cat /proc/cpuinfo
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 10
model name      : VIA Esther processor 1000MHz
stepping        : 9
cpu MHz         : 1000.044
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 nx up pni est rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en
bogomips        : 2001.56
clflush size    : 64

Sin embargo, un bug en las BIOS de las placas EX, versiones 1.01 (la disponible en la web de VIA) y 1.04 (la incluida en muchas placas recientes, incluida la mía, pero no disponible en Internet) causa que la opción:

Advanced BIOS Features → CPU Feature → Execute Disable Bit

siempre esté deshabilitada.

Si la habilitamos y arrancamos el sistema inmediatamente, el bit estará disponible, pero tan pronto como la apaguemos y la volvamos a arrancar volverá a estar deshabilitado. ¡Ya es hora de que VIA suministre una nueva BIOS que solucione este problema! El problema lo descubrió el usuario zoo de los foros de VIA:

VIA Padlock

Los procesadores VIA son capaces de acelerar por hardware determinados algoritmos usados en criptografía gracias al VIA PadLock Security Engine que llevan integrado. Los VIA C7, en concreto, soportan el RSA, el AES (128, 196 y 256 bits) y el SHA-1/SHA-256. De este Security Engine también forman parte el generador de números aleatorios y el bit NX de los que hemos hablado anteriormente.

Con la tecnología de PadLock, estos pequeños procesadores son capaces de tener mejores prestaciones encriptando que procesadores Intel y AMD de mucho más potentes en todos las otras áreas (Sobre las VIA EPIA (I): Introducción al formato Mini-ITX y a las placas EPIA).

El soporte de esta aceleración hardware ya viene incluido en el kernel:

Cryptographic options → Hardware crypto devices → Support for VIA PadLock ACE
Cryptographic options → Hardware crypto devices → Support for VIA PadLock ACE → PadLock driver for AES algorithm
Cryptographic options → Hardware crypto devices → Support for VIA PadLock ACE → PadLock driver for SHA1 and SHA256 algorithms

VIA PadLock

Como leemos en VIA PadLock support for Linux, las aplicaciones que quieran usar esta aceleración tienen que incluir estas líneas en su código:

#include <openssl/engine.h>

int main ()
{
	[...]
	/* Init available hardware crypto engines. */
	ENGINE_load_builtin_engines();
	ENGINE_register_all_complete();
	[...]
}

En VIA PadLock support for Linux también encontramos parches para habilitar este soporte hardware en OpenSSL y OpenSSH, así como parches contribuídos para habilitarlo en Apache, Postfix , Courier-IMAP, LigHTTPd y mini_httpd.

Para aplicar estos parches a los paquetes oficiales de Debian, podemos seguir las indicaciones de Gentooizar Debian con apt-build. Si lo hacemos con el openssl, por ejemplo, podemos comprobar la espectacular mejora de rendimiento al usar el PadLock, llegando a ser 82 veces mayor (8192 bytes/aes128) en los siguientes ejemplos:

# modprobe padlock-aes
# modprobe padlock-sha

# dmesg | grep -i padlock
padlock: Using VIA PadLock ACE for AES algorithm.
padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms.

# openssl speed -evp aes-128-ecb
[...]
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-ecb      12845.06k    13951.41k    16148.61k    18033.43k    15721.52k

# openssl speed -evp aes-128-ecb -engine padlock
engine "padlock" set.
[...]
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-ecb      67402.22k   269420.15k   656469.08k  1059444.40k  1290476.66k

# openssl speed -evp sha256
[...]
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256            1586.98k     4218.91k     7690.52k    10568.70k    10534.85k

# openssl speed -evp sha256 -engine padlock
engine "padlock" set.
[...]
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256            2096.53k     7761.68k    32652.56k    85811.20k   168421.80k

VIA pone a nuestra disposición herramientas y SDKs (Free Security Software, Development Tools) para sacar el máximo provecho al PadLock.

Gráficos, vídeo acelerado por HW

La configuración del procesador gráfico UniChrome™ Pro II es, sin duda alguna, la tarea con más enjundia a la hora de dejar nuestra placa EX funcionando. Por ese motivo, dejamos este parte para la siguiente entrada, que trata, entre otras cosas, del driver openChrome, el driver oficial de VIA y la aceleración de vídeo por hardware:

Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG

:wq

Entradas relacionadas

16 Comentarios a “Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux”

  • pulpito dice:

    Hola
    enhorabuena por el blog
    Casi todo lo has marcado como módulo… ¿es por una razón de preferencia personal o hay otra explicación? Lo digo porque tengo entendido (aunque es posible que me equivoque) que tampoco está mal dejar ciertos empotrados directamente en el kernel, en vez de dejarlos como módulos.

    saludos

  • pulpito ¡Gracias!

    Pues en ese aspecto, yo he pasado de un extremo al otro… Hace unos años compilaba el soporte de TODO lo que tuviera en el PC en el kernel y no en módulos. De hecho, no usaba ningún módulo: si me hacía falta, directamente al kernel. Al fin y al cabo, ya que era mi kernel personalizado, para eso hacía el esfuerzo de ir quitando todo lo innecesario.

    Hoy en día hago prácticamente lo contrario. A menos que sean cosas realmente necesarias en el kernel, lo dejo todo como módulo. Me gusta ver lo que se ha cargado durante el arranque en el lsmod y lo que se va cargando cuando va haciendo falta. A veces, incluso resulta útil poder quitar ciertos módulos para hacer pruebas.

    El el Linux Loadable Kernel Module HOWTO puedes encontrar la sección 2.3. The Case For Loadable Kernel Modules que te cuenta los beneficios de usar módulos en términos generales.

  • Ivan dice:

    Hola!

    cada día me gustan más los artículos y cómo los cuentas. Aunque no tengo una Epia (ni creo que vaya a tener una en un futuro cercano) me he leído el artículo con detalle porque siempre se aprende algo.
    Ya que parece que tienes dominada la compilación del kernel, te sugiero un artículo sobre eso, cómo compilarlo, las distintas formas, lo que hay que tener en cuenta,… Creo que le resultaría útil a mucha gente porque aunque hay muchos tutoriales sobre cómo hacerlo, seguro que tu aportas mucho más valor añadido.

    Saludos, Iván.

  • Ivan ¡Muchas gracias! Me alegro mucho de que te haya gustado el artículo :-)

    La compilación y personalización del kernel es una buena idea para una entrada. ¡La pongo en la cola! ¡Gracias!

  • Ringmaster dice:

    Coco, quería comentarte que yo no recomendaría activar la regulación “enhanced powersave” para el C7, ya que es experimental y no mejora apenas el ahorro que se consigue con el Via Cyrix III longhaul, yo al menos no he notado diferencia alguna; sigue escalando la velocidad como cuando lo tenía activado y ya no se me cuelga en uso normal.
    Ahora sólo se me cuelga si me empeño en usar el 3D con mi CN700, cuyo controlador que mantiene el grupo Mesa aún tiene bugs (no así el 2D que mantiene Openchrome, que va perfecto).

  • Ringmaster Muchísimas gracias por compartir tu valiosa experiencia.

    En realidad, como ya comento en la entrada, no tiene sentido usar el escalado de frecuencia ni en EX10000EG ni en la SP8000E. En estos procesadores el consumo ya es el mínimo posible y las prestaciones ya son muy justitas para como para poder permitirnos el lujo de andar bajando la frecuencia.

    He comentado la existencia de ese driver porque no podía dejar de repasar todas las facilidades del kernel para esta placa, pero la verdad es que no me he entretenido mucho probándolo. Ya ves que sólo acepta como frecuencias 800MHz y 1GHz, así que su utilidad es mínima.

    En la SP8000E sí estuve probando mucho con el LongHaul y la verdad es que según lo que probara, el sistema se podía colgar, así que lo dejé estar.

    También es cierto que en tu placa Jetway con procesador C7 de 2GHz el escalado de frecuencia tiene más sentido, ¿no?

  • miguel dice:

    ola m gustaria saber si con la tarjeta graficaVIA Chrome9 HC DX9 de 256 mb cmpartidos funcionan bien los juegos,porque a mi n m van.le agradeceria una rspuesta.1 saludo

  • miguel Entiendo que te refieres a juegos 3D en Windows. No lo he probado, pero estoy seguro de que ese procesador gráfico no tiene la potencia necesaria.

  • Ringmaster dice:

    Super Coco, sí que tiene más sentido en mi placa, porque escala entre 800 mhz (más que suficiente para un uso “ofimático”) y 2 Ghz, pero el problema que encuentro (tanto con LongHaul como con Enhanced Powersave) es que el cambio entre frecuencias es lento, y si estás viendo mpeg2 sin aceleración los cambios entre escenas estáticas y de movimiento hace que se salte algunos frames la primera fracción de segundo, por lo que al final no tiene sentido activarlo (consume casi lo mismo, el mayor ahorro se produce con la istrucción Halt, que hace que el procesador “apague” algunos circuitos internos). Yo lo tuve una temporada en estado powersave (utilizando el kpowersave, que está muy maduro) para poder contribuir con el Boinc a “romper” el SHA1 sin consumir de más y a la vez poder seguir utilizando normalmente el ordenador, pero eso ya es muy friki…
    Bueno, creo que pondré un artículo sobre los modos de ahorro de energía en el blog… Un saludo!!

  • Ringmaster Como siempre, muchas gracias por tan detallada información y por ampliar la entrada. Si te decides a escribir ese artículo, ten por seguro que me contarás entre sus lectores :)

    Y si lo haces, por favor, ¡no dejes de dejar un enlace por aquí!

  • fustrado dice:

    buenas, llevo dos dias y media con un problema con un equipo precisamente con una via epia ex, es para un tema de trabajo, bueno me han dado un mini pc con esta placa con un gentoo ya instalado, el tema es que instale gnome para tener entorno grafico y bueno todo funciona correctamente menos el ratón que aunq operativo no se ve el puntero…he probadop la configuracion del sorg.conf con las X “X -config /root/X11/xorg.conf” y weno se ve el ratón se mueve perfectamente y todo correcto, pero al retornar al gnome nada…

    se que no es sitio para esta pregunta pro bueno he mirado en todos sitios y se me han acabado las ideas….

    sólo quiero saber si te suena de algo un error asi….

    gracias.

  • @fustrado ¡Ni idea de qué puede ser! Nunca me ha pasado nada parecido…

  • talibanO dice:

    Hola Super Coco, quería preguntarte si ves alguna razón sólida para comprar EPIA de VIA en lugar de una JETWAY con un C7.

    El uso a dar es un NAS casero para servidor multimedia y backup de un par de pcs. El apartado gráfico es obviable. Necesito al menos un par de SATAs (más mejor) y un puerto gigabit. La VIA EPIA SN10000EG se va de precio (y prefiero un más maduro CN700) y dudo entre VIA EPIA EN12000EG (alrededor de 250€) y Jetway J7F4K1G2E (sobre los 130€).

    Estoy prácticamente decidido por esta última placa, pero me gustaría saber tu opinión.

    Perdona el ladrillo y si este no es el lugar adecuado.

    Un saludo.

  • taliban0 Yo te puedo hablar de las EPIA. Excepto en el apartado de vídeo y gráficos en el que ya ves lo que hay, como servidor doméstico como el que comentas, mi experiencia con las dos que tengo es que van extraordinariamente bien, no hacen nada de ruido (nada quiere decir nada de nada, sólo el ruido que haga el disco), consumen muy poco y son muy estables. Se tiran meses en marcha sin ningún problema.

    De las EPIA creo que también tienes más recursos disponibles en la web, pero casi todo es aplicable a placas con la misma combinación de CPU-Chipset. Las Jetway son más baratas pero habría que ver si es porque sus componentes son peores, no lo sé.

    Puedes preguntarle a Ringmaster que él tiene una Jetway de 2GHz:

    Tutorial: Proyecto reproductor multimedia Reloaded
    Instalar el controlador para el chipset VIA CN700 en Ubuntu linux

    Él estuvo haciendo comentarios en la entrada Sobre las VIA EPIA (III): Linux en una SP8000E y parece que lo que más le disgustaba era la calidad de la salida de audio.

Trackbacks y pingbacks:

Tema LHYLE09, creado por Vicente Navarro