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
0400
current-tss.cr3 = 0140f000, %cr3 = 0140f000
*pde =
Oops:
CPU:0
EIP:0010:[c0129e3c]
EFLAGS: 00010206
eax: 0400 ebx: c102a9a0 ecx: edx: 001a
esi: edi: c1702035 ebp: esp: c22dbf6c
ds: 0018 es: 0018 ss: 0018
Process ls (pid: 586, process nr: 27, stackpage=c22db000)
Stack: c1156b00 c22dbf88 c1702000 c1702000 b844 b82c
c170201b
001a 9e6e9074 c012a194 c1702000 c1156b00 c22da000
0805e2bc
c01282f6 b844 c22da000 0805e2bc c01087c0 b844
b7ec
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 0400 ¿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
