>Al compilar el kernel 2.2.17 (el paquete de potato) salen estos avisos:
>/tmp/ccWUW6W7.s: Assembler messages:
>/tmp/ccWUW6W7.s:109: Warning: using `%eax' instead of `%ax' due to `l'
>suffix

No s� si ser� debido a estos avisos, pero con el kernel 2.2.17 ya
funcionando me han vuelto a surgir los mismos problemas que ten�a con el
2.2.12 (y que me forzaron a usar el 2.2.10).

Ayer me di� este error:

rvmsoft:~$ ls /usr/share/doc/qt2-doc/doc/
Unable to handle kernel NULL pointer dereference at virtual address
00000400
current->tss.cr3 = 0140f000, %cr3 = 0140f000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0129e3c>]
EFLAGS: 00010206
eax: 00000400   ebx: c102a9a0   ecx: 00000000   edx: 0000001a
esi: 00000000   edi: c1702035   ebp: 00000000   esp: c22dbf6c
ds: 0018   es: 0018   ss: 0018
Process ls (pid: 586, process nr: 27, stackpage=c22db000)
Stack: c1156b00 c22dbf88 00000000 c1702000 c1702000 bffff844 bffff82c
c170201b
       0000001a 9e6e9074 c012a194 c1702000 c1156b00 00000000 c22da000
0805e2bc
       c01282f6 bffff844 00000000 c22da000 0805e2bc c01087c0 bffff844
bffff7ec
Call Trace: [<c012a194>] [<c01282f6>] [<c01087c0>]
Code: 8b 10 85 d2 74 27 8b 44 24 10 50 53 ff d2 83 c4 08 85 c0 75
Violaci�n de segmento


�Alguien sabe que significan todos esos n�meros? Por cierto que todas
las veces que se ha producido este error el virtual address del que
habla es 00000400 �significa algo especial?

(Justo a la vez el klogd debi� morir, ya que lo �ltimo que aparec�a en
el /var/log/messages era Oops: 0).

Exactamente lo mismo me hab�a ocurrido al menos dos veces con el kernel
2.2.12.
En este caso el error se produce con un "ls" pero tambi�n pasa con "cd".
Por supuesto el directorio en cuesti�n est� bien (de hecho unos segundos
antes la misma orden hab�a funcionado perfectamente).
Una vez que se da este fallo cualquier intento de acceder al directorio
produce exactamente el mismo mensaje de error. La �nica soluci�n es
reiniciar.

Se podr�a pensar que es un fallo en el sistema de ficheros, pero creo
que se puede descartar porque
1) al reiniciar se puede acceder perfectamente a ese directorio
2) no ocurre siempre en el mismo directorio
3) el disco donde me ocurri� esto ayer es nuevo y formateado hace menos
de una semana con chequeo de errores (no detect� ning�n fallo)
4) me ocurri� lo mismo con el disco duro antiguo, y tambi�n con un CDROM
5) con el kernel 2.2.10 nunca me ha pasado esto

Tambi�n podr�a ser un fallo de memoria, pero se dice que el mejor test
para la memoria es compilar el kernel, y nunca he tenido ning�n problema
con ello (ning�n signal 11), y adem�s a veces he compilado otros
programas que tardan mucho m�s que el kernel (hasta 4 horas) sin
problema.
Sin embargo he de decir que el gcc de potato (2.95.2) s� me ha dado
algunos errores internos (me aparec�a un mensaje diciendo que reportara
el bug) compilando programas en C++, pero al menos en dos de los tres
casos el fallo hab�a sido m�o (por ejemplo, olvidar poner un ; en un
fichero *.h).

Revisando el /var/log/messages he visto estos mensajes que se produjeron
hace unos d�as (no s� si tendr�n algo que ver), y tambi�n con el kernel
2.2.17 en funcionamiento:

Jan  5 17:11:21 rvmsoft -- MARK --
Jan  5 17:18:27 rvmsoft kernel: VM: do_try_to_free_pages failed for
kswapd...
Jan  5 17:31:21 rvmsoft -- MARK --
Jan  5 17:51:21 rvmsoft -- MARK --
Jan  5 18:11:21 rvmsoft -- MARK --
Jan  5 18:31:21 rvmsoft -- MARK --
Jan  5 18:51:21 rvmsoft -- MARK --
Jan  5 19:11:21 rvmsoft -- MARK --
Jan  5 19:14:56 rvmsoft kernel: VM: do_try_to_free_pages failed for
kswapd...
Jan  5 19:31:21 rvmsoft -- MARK --

Por si acaso esta tarde he vuelto a compilar el kernel con el compilador
gcc 2.7.2.3, en lugar del 2.95.2. Por cierto que el m�todo que explica
la documentaci�n para compilar con el viejo gcc no funciona con el
kernel (make CC=gcc272), he tenido que renombrar el gcc a gcc.real y
hacer un enlace de gcc272 a gcc.

Durante la compilaci�n he visto que se segu�an produciendo las
advertencias que comentaba en mi mensaje anterior. Si acaso luego me
bajar� un binutils nuevo tal y como recomienda Santiago.

Por cierto que con el gcc 2.7.2.3 tarda bastante menos en compilar (45
minutos) que con el 2.95.2 (54 minutos) en mi pentium 133 (sin contar el
make modules, que son otros 15 minutos). Ah, y el kernel generado
tambi�n es un poquit�n m�s peque�o.

Lo usar� unos d�as a ver si va bien, y si no tendr� que volver al
2.2.10.

Ah, y el depmod -a que se ejecuta en el arranque �se ejecuta cuando el
kernel ya ha intentado cargar alg�n m�dulo!, llen�ndome la pantalla de
errores por tanto...

--
Ricardo Villalba
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://members.xoom.com/rvmsoft


Responder a