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 [EMAIL PROTECTED] A proud Debian GNU/Linux 2.1 User.
