[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: AMD K7 y compatibilidad en Linux



At 02:21 PM 1999-11-18 +0100, Ramiro Alba wrote:
>>         Nosotros en Bulma estamos igual :), queremos comprar un K7 para
>> montarlo de servidor de Bulma y empezar a dar servicios a lo bestia. Te
>> recomiendo que te pases por bulma (http://m3d.uib.es/bulma), donde
tienes un
>> artículo con enlaces sobre el tema (Busca Athlon, por ejemplo, y te
saldrá).
>> Por esta lista creo que fue alguien dijo algo sobre que tuvo que usar el
>> kernel tecra para poder meterle Debian e incluso así luego le fallaba al
>> verificar el disco o algo de eso (¿cuestión de placa, de HD, o de K7?)
>> 
>En principio, no hay ningun problema, era todo cuestion del disco duro
>(FUJITSU 10.2 Gb): estaba defectuoso ¿Alguien ha detectado algún
>problema con esta marca de discos?. Yo aparte del problema de que estaba
>defectuoso, me pasó que no me reconoció su capacidad REAL de 9.7 Gb si
>no le especificaba al kernel el siguiente parametro: hda=19858,16,63. En
>mi mensaje anterior a la lista, Ugo Enrico me contestó que esto no se
>debe hacer. ¿Porque? Yo en realidad es la primera vez que lo hago, pero
>sino como evito perder del orden de 1.5 Gb. Yo me estoy leyendo
>informacion relativa a todo esto (http://www.pcguide.com/ está muy
>bien), pero si alguien lo tiene muy claro y quiere hacer una explicacion
>al estilo de la del reloj del sistema hecha por Conrado Badenas (gracias
>Conrado!!!) creo que aclararía mucho las cosas a unos cuantos.
Puff... una explicación como la de Conrado, me quedaría algo dura :oP
Lo que pasa es que el BIOS, por sus limitaciones, no puede arrancar nada
que esté por encima de los 1024 cilindros. Todo estaba muy bien cuando los
discos duros no eran mayores de 500MB. Pero con el pasar de los años esto
cambió (y de que manera!) llegando a la capacidad que hoy conocemos.
Por ejemplo tu caso, un disco de 10.2GB, 19858 cilindros, 16 cabezas, y
63 sectores. En el peor de los casos, solo podrías tener acceso a 512MB,
pero utilizando el método LBA, puedes expresar los 10.2GB de tu disco,
como si en vez de 19858 cil. tuviera 1024, pero en vez de 16 cabezas,
tuviera 255.
El problema aquí es que (por lo visto) el LBA está limitado a 1024/255/63
lo cual es bastante preocupante, pues (no había caído en cuenta) esto
limita las capacidades de los discos duros a 8.4GB (para calcular la
capacidad del disco usa esto: Cilindros*Cabezas*Sectores*512)
Así que me corrijo, y vaya que si debes pasarle esos parámetros al kernel.
(o usar el modo NORMAL de direccionamiento del disco en el BIOS)

>Por otra parte el unico inconveniente que me he encontrado relativo al
>kernel 2.0.36 es que se me queda clavado en la linea:
>md driver 0.36.3 MAX_MD_DEV = 4, MAX_REAL=8
>razon por la cual he de utilizar el "tecra" para instalar. Esto me
>complica el proceso de instalacion, asi que si alguien me dice como
>podría evitarlo o que documentación debo mirarme, le estaría muy
>agradecido.
Mmm... pues sería cuestión de recompilar el kernel _sin_ RAID (md), y
reemplazarlo en los boot-floppies.

>Ahora mismo, y a la espera de recibir un nuevo disco estoy funcionando
>con uno pequeño provisional que me ha permitido instalarle los paquetes
>del perfil standard (aprox. 150 Mb) para poder compilar con gcc y g77.
>Estoy funcionado con el kernel 2.2.13 (Por cierto, que pasa algo
>referente al kernel 2.2.x y la corrupcion del sistema de ficheros?).
Sip. La saga continúa. Aunque son unos casos bastante raros (a mi nunca
me ha molestado, por lo menos)

>Estoy haciendo pruebas con una librería de sofware numérico hecha por
>nuestro Laboratorio en C y el rendimiento máximo del K7 500 con respecto
>al P III 500 es de un 23%. En algun que otro caso, este rendimiento
>desciende hasta prácticamente igualar el del P III 500, pero parece que
>la media se estabiliza en el 20%. En principio cabría (segun benchmarks
>que he mirado) llegar a un rendimiento cercano el 50%. Una de las
>explicaciones puede ser que el Kernel no está optimizado para el K7 (He
>leido en Linux Actual que el Kernel 2.4 sí tendrá optimizaciones
>específicas para el K7) y otra es que los benchmarks de Coma Flotante se
>refieran a numero de precision sencilla (float) y no de precision doble
>(double) que es nuestro caso.
Lo más posible es que las librerías no estén optimizadas para el K7,
(y tampoco para el PIII)

Un saludo.
Ugo Enrico Albarello López de Mesa
ugo.albarello@jol.net.co
A proud Debian GNU/Linux 2.1 User.


Reply to: