usb-storage: page allocation failure. order:4, mode:0x21

[qlfecv]

Desastre total, por segunda vez el HD a la playa
Y no se porque me pasa, pero cuando me sale esto:

Código: Seleccionar todo

usb-storage: page allocation failure. order:4, mode:0x21
Mem-info:
DMA per-cpu:
cpu 0 hot: high 18, batch 3 used:16
cpu 0 cold: high 6, batch 1 used:0
DMA32 per-cpu:
cpu 0 hot: high 18, batch 3 used:13
cpu 0 cold: high 6, batch 1 used:0
Normal per-cpu: empty
HighMem per-cpu: empty
Free pages:        1800kB (0kB HighMem)
Active:25126 inactive:4606 dirty:5 writeback:0 unstable:0 free:450 slab:841 mapped:2336 pagetables:163
DMA free:1076kB min:724kB low:904kB high:1084kB active:52860kB inactive:7596kB present:65536kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 64 64 64
DMA32 free:724kB min:724kB low:904kB high:1084kB active:47644kB inactive:10828kB present:65536kB pages_scanned:123 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 1*4kB 56*8kB 29*16kB 3*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1076kB
DMA32: 1*4kB 0*8kB 1*16kB 0*32kB 1*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 724kB
Normal: empty
HighMem: empty
Swap cache: add 126, delete 119, find 0/0, race 0+0
Free swap  = 79812kB
Total swap = 80316kB
Free swap:        79812kB
32768 pages of RAM
613 free pages
955 reserved pages
841 slab pages
7757 pages shared
7 pages swap cached
ehci_hcd 0000:00:01.2: alloc_safe_buffer: could not alloc dma memory (size=45056)
ehci_hcd 0000:00:01.2: map_single: unable to map unsafe buffer c5e10000!


El disco acaba palmando, se pierde todo y tengo que reinstalar el sistema.

Por suerte como es la segunda vez que me pasa tengo una imagen del disco y es facil recuperarla.

Alguien tiene idea de que es lo que me esta pasando????

[jiauka]

ehci_hcd 0000:00:01.2: alloc_safe_buffer: could not alloc dma memory (size=45056)
ehci_hcd 0000:00:01.2: map_single: unable to map unsafe buffer c5e10000!

Los problemas de DMA (Direct Memory Access) son de memoria. Quizás una patilla mal soldada que con el calor/vibración, etc deja de hacer contacto.

Repasa los pines de la memoria 1 a 1 con 1 cutter forzardolos ligeramente hacia 1 lado, si alguno cede lo sueldas de nuevo.


have fun,

j.

[qlfecv]

Pero deberia pasar siempre,no?

[jiauka]

Parece 1 bug real, relacionado con la fragmentación de linux y el controlador DMA.

http://slugbug.nslu2-linux.org/bug.php? ... &bugid=324

http://lists.osdl.org/pipermail/bugme-n ... 07505.html

have fun,

j.

[qlfecv]

Cosas curiosas.

Intentando acotar el problema he cambiado mi bicho por el de nosfe y entonces su bicho con mi disco duro no falla .

He comprobado que la flash del bicho de nosfe y la mia son distintas, la zona de ramdisk.

Mi pregunta, una vez rebotado el bicho influye en algo lo que tenga en la flash??? o toma el control lo que hay en el disco duro???

[qlfecv]

Bueno, por fin el amigo nosfe ha conseguido un sistema para que el bicho siempre se cuelge y poder acotar el bug.

Probamos los siguientes apex de segundo nivel con distinto parametro para el kernel de memoria disponible con los siguientes resultados:

128MB@0x0 -> casca (sistema original)
64MB@0x0 -> funciona OK
96MB@0x0 -> funciona OK
100MB@0x0 -> funciona OK
112MB@0x0 -> funciona OK
124MB@0x0 -> funciona OK
125MB@0x0 -> casca con cualquier valor mayor de 124.

Aparentemente falla el ultimo bloque de la ram que es de 4MB x 16 bits, pero escribiendo directamente sobre ella no se detecta el error.

Esperaremos a que saquen algun parche para el kernel y usaremos 124 MB de ram en vez de los 128 a ver si asi funciona 100% durante todo el tiempo.

[nosferatu]

intercambiamos otra ve los bichos y

el que ahora tengo casca a 124, funciona a 112

creo que la memoria disponible no es solo lo unico vinculante.

dependera de como samba negocie con windows, o de como se realize la transferencia en esos instantes, carga de aplicaciones, etc

spongo que habra que esperar kernel nuevo.... y que jiauka tiene razon, que en determinadas operaciones incluso con 32 podria fallar.

esta claro que influye

ram // dma
fragmentacion de archivos

pero no se como

[nosferatu]

buf, a ver como se come esto:

ayer tampoco podia sambear ficheros de 300Mb del amule.
con fsck del ubuntu no me daba ningun error. (ni siquuiera forzando el checkeo con -fp
pasado el fsck en la maquina virtual (debian etch) me corrigio 5 errorees de journaling....
al volver el disco al bicho, sorpresa, el bicho quiere chequearlo, cuando normalmete despues de un chequeo exterior el contador se pone a 0

sobre el 20% del chequeo ocurrre el bug y vuelta a empezar.
no hay salida. 20% del chequeo bug y vuelta a empezar. (sabeis el chste del informatico?.

por probar: cambio el apex2 para tener 112 y mismo proceso, pero esta vez llego al 45%

por probar: cambio el apex2 para tener 64 y termina el chequeo. sale un mensaje parecido a que el "disco ha podido ser reparado pero que le es necesario rebotar" (en rojo)

despues de una pequeña cuenta atras se produce el rebote. como la flash estaba el apex128 (los demas los go_neaba desde ram) arranco normalmente con mis 128

Despues de 20 horas en marcha, y sambeando todos los ficheros que habian probocado el bug, no puedo hacer que falle de ninguna manera.

Conclusion:

* Existe el BUG
* Tiene que ver con el tamaño y fragmentacion de los ficheros
* Cuanto menos ram, menos posibilidad de que pase
* Tiene que ver con errores en el disco

Conclusion 2
ya no se reproducirlo.

[qlfecv]

Haciendo la prueba de cambio de parametros del apex he comprobado que con 128MB y 124MB no pasa el checkeo de disco.

No me he entretenido mas y no se si con menos pasara, pero parece una buena forma de verificar el bug.

[nosferatu]

Hola, hoy despues de una semana de tranquilidad cuelgue otra vez.

He creado esta nueva seccion, para clarificar...

a la espera de una solucion yo actuo asi:

Código: Seleccionar todo

desconectar y conectar (que remedio)

tune2fs -c 1 /dev/sda1
reboot
parar en el primer apex con control-C
xreceive 0x1000000  (enviar xmodem 1k) (enter)
go 0x1000000
tune2fs -c 28 /dev/sda1
reboot

es decir cargo y ejecto el apex de 64 desde ram forzando el chequeo del disco. En el ultimo reboot arranca desde la falsh que la tengo a 128...

Seria bueno postear nuestros cuelgues debido al bug (cada cuanto son) y que Ram usamos.....