Fw: SMP y FPU emulation en BCM6368

[José Vázquez Fernández]

Me olvidé de preguntaros vuestra opinión y si alguno podría generar una imagen para contrastar
usando este repo: https://github.com/Pteridium/openwrt/tree/bcm63xx-r37180
El historial de los últimos cambios es un poco chapucero
(https://github.com/Pteridium/openwrt/compare/bcm63xx-r37180) pero no da problemas al compilar.

Un saludo:

Pepe

----- Original Message -----
From: "José Vázquez Fernández" <ppvazq...@gmail.com>
To: <segurida...@googlegroups.com>
Sent: Tuesday, July 30, 2013 5:16 PM
Subject: SMP y FPU emulation en BCM6368


Poco a poco JaR229 y yo nos estamos acercando al posible origen de los fallos con los BCM6368,
pero todavía queda por determinar qué papel juega en todo esto la distro que se usa para hacer las
compilaciones. JaR creo que usa Ubuntu o Fedora, y yo Debian 6.0.x, y en las compilaciones de cada
uno aparecen problemas diferentes. A ver si lo consigo estructurar bien...
JaR:
- SMP + FPU= cuelgue al iniciar el segundo core.
- SMP= funciona.
Pepe:
- SMP + FPU= errores en rootfs_data al modificar archivos.
- Generic + FPU= lo mismo de antes.
- SMP= funciona.
- Generic= funciona.

De momento ya hemos establecido que "FPU emulation" pude ser o es parte del problema, y probando
con un HG556, que el BCM6358 no se ve afectado al activar la emulación de FPU en el kernel, pero lo
que me tiene un poco mosca es que hay resultados dispares dependiendo de la distro con la que se
compila.

Voy a hacer una prueba con un BCM6328 pero me da que el resultado va a ser el mismo que con el
router de Vodafone; también voy a echar un ojo a las revisiones disponibles del BCM6368, ya que los
VR-3025xx sueltan "Detected Broadcom 0x6368 CPU revision b2" y "CPU revision is: 0002a031 (Broadcom
BMIPS4350)".

Si con los BCM6328 funciona bien entonces ya no sé que pensar salvo un bug en los BCM6368.

Un saludo:

Pepe

P.D.: así es cómo funcionan los chinos...
http://huaweihg612hacking.files.wordpress.com/2011/11/olivertwist_thehacker.jpg


__________ Information from ESET NOD32 Antivirus, version of virus signature database 8628
(20130730) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[JaR]

Noltari me comentaba ayer por IRC

"<Noltari> al final son modificaciones que se realizan a nivel ensamblador y de registros

<Noltari> y si se toca algún registro que no se debe puede hacer que las interrupciones no lleguen bien a ambas CPUs

<jar229> el tema del FPU, creo que muy poca gente lo usa

<Noltari> no me hagas mucho caso en esto, porque está por encima de mis conocimientos"

Y si a él se le escapa ... :(

En todo caso, se podría reportar ...

Saludos.

[José Vázquez Fernández]

    Le he dado muchas vueltas, y como nuestras compilaciones sólo fallan en los 6368 me inclino a creer que es una errata en los cores.

    Hoy mismo envío un mail a openwrt explicando el fallo y las pruebas en otros routers con bmips4350. Por supuesto no descarto que el problema sea nuestro, pero como sólo el 6368 peta me inclino por la primera opción.

[Álvaro Fernández Rojas]

Sigo pensando que es un problema de SMP en todos los SOCs.
El problema es que cuando se intenta habilitar el SMP, existe una comprobación que excluye a los 6358, por lo que no inicializa ambas CPUs.
https://github.com/torvalds/linux/blob/master/arch/mips/bcm63xx/prom.c#L77
También hay una lectura de un registro para comprobar si hay dos cores en el caso de que sea un 6328, puesto que no todos tienen dos cores.
https://github.com/torvalds/linux/blob/master/arch/mips/bcm63xx/prom.c#L71

Por eso no os da ese fallo en los 6358, ya que realmente estáis trabajando sin SMP tanto si lo activais como si no.

Saludos!

[Álvaro Fernández Rojas]

No, en el caso del VR-3025x tiene un 6368, por lo que funcionan ambas CPUs.

Es s�lo en el caso del 6358 en el que est� deshabilitado.

El 01/08/2013 14:33, JaR escribi�:
> Pues vaya.
> Y cuando en un administrador de procesos momo htop te 'ense�a' los dos cores, se lo 'inventa' ?
> http://foro.seguridadwireless.net/openwrt/%28desarrollo%29-openwrt-en-comtrend-vr-3025u/msg282437/#msg282437
>
> Saludos.

[José Vázquez Fernández]

Discrepo porque probé el perfil generic (no activa el segundo core) con FPU emulation activado y tuve corrupción de datos en la partición rootfs_data que usa jffs2 como sistema de ficheros. Creo que no es fallo de smp sino de bmips4350 V3.1 que es el que usan los bcm6368.

No descarto que el culpable sea el PC o la distro con la que se hacen las compilaciones aunque me inclino por una "silicon errata".

__________ Information from ESET NOD32 Antivirus, version of virus signature database 8634 (20130801) __________

[José Vázquez]

Bueno, ya mandé dos correos a openwrt-devel, pero lo que hagan ya es
cosa de ellos.
https://lists.openwrt.org/pipermail/openwrt-devel/2013-August/020909.html
https://lists.openwrt.org/pipermail/openwrt-devel/2013-August/020942.html
Con lo poco que sé esa es la conclusión a la que llego.

Un saludo:

Pepe

[JaR]

Esperaremos noticias :)

Saludos.

[José Vázquez]

El 05/08/13, JaR <jar...@gmail.com> escribió:
> Esperaremos noticias :)
>
> Saludos.

Listo un repositorio de prueba para el BCM6368 con soporte SMP.
https://github.com/Pteridium/Attitude-Adjustment-ARV4518PWR01/commits/devel
Para descargarlo:
git clone https://github.com/Pteridium/Attitude-Adjustment-ARV4518PWR01 -b devel

No lo he probado a fondo, pero en principio parece que no da
problemas. Una vez que se vea que es estable se le añadirán algunos
detalles para dejarlo como está actualmente en Barrier Braker.

Un saludo:

Pepe

[JaR]

Estupendo :)

En cuanto pueda (ando liado con un par de routers asus que me he agenciado), hago una compilación para probarlos.

Saludos.

[dgcbueu]

 No tengo ninguna experiencia con el tema del SMP, aun ando viendo el dngd3700 con bcm6368 y el soporte básico. El caso es que estaba mirando el código fuente de Netgear para ver si podía conseguir hacer funcional la flash NAND adicional que tiene el router. Encontré algo que me llamó la atención. En el archivo

drivers/mtd/chips/cfi_cmdset_0002.c

del kernel, aparece comentada toda la sección correspondiente a "case FL_ERASING:" de la función  "get_chip", esto comparándolo con un kernel vanilla de la misma versión. A sabiendas de que en estos viejos kernels el erase_suspend tenía algún problema y por podrían haberlo comentado, también podria ser que esté comentado por el problema que tenemos de corrupción de ficheros. Nunca se sabe y por atar cabos que no sea. De momento aun no me metí en el tema de SMP, pero si alguien decide probar este parche estaría bien.

Como ya comenté el parche es supersimple solo es comentar esa sección, pero adjunto uno para que no queden dudas (hecho para AA) pero es tan simple que ni me molestaría en aplicarlo, con borrar la sección mencionada sería suficiente. 

No tengo esperanzas de que esto resuelva nada, pero hay que ir descartando cosas.

Saludos

[dgcbueu]

Bien, lo de comentar el codigó en el archivo /cfi_cmdset_0002.c no funcionó.

Ahora pregunto una cosilla. ¿Alguien probó a cambiar esto en el CFE?

Main Thread Number [0|1] : 0  

En lugar de 0 al menos en mi dgnd3700 si le pongo un 1, OpenWrt no arranca, se queda atascado cuando inicia el segundo core. Y ahora me doy cuenta porqué no era capaz de hacer nada en el hg556a cuando probé SMP en su día, que todos sabemos no funciona en bcm6358, pero es que se me quedaba pillado en el mismo sitio y ahora sé porqué.

A alguien se le ocurre por qué pasa esto?, yo creo que no debería quedarse colgado si tiene configurado el core 1 como principal, ambos cores son iguales. Solo se me ocurre que los cores tengan una identificación, y la implementación SMP identifica el core 1 para iniciarlo, pero si el core 1 ya está iniciado se queda tonto, pero esto parece una implementación chapucilla no?, o nadie se dio cuenta de algún detalle, entre otros como lo de la corrupción de ficheros..

¿Alguna idea?

[JaR]

Yo en este tema, estoy totalmente pegado, la verdad.

La verdad es que es curioso que nadie más haya reportado problemas con el tema del SMP a los desarrolladores de OpenWrt.

Aprovechando ... Feliz Año a todos :)

Saludos.

[dgcbueu]

A falta de conseguir detectar el problema, más bien estoy buscando un workaraund, digamos que quiero saltar el charco sin mojarme los pies.

Ahora mismo lo que estoy probando es a iniciar el sistema con un solo core, y luego habilitarlo al final de la carga. El problema no ocurre, pero hace falta testearlo más a fondo, como supongo que tener el router encendio sin hacer nada no es ningún test, pido a alguien que use el bcm6368 pruebe esto.

Consiste en compilar de forma habitual con el perfil SMP, pero con estas opciones puestas en el kernel

 [*] Support for hot-pluggable CPUs

y

[*] Built-in kernel command line

 (root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 maxcpus=1)

nótese que en esta opción simplemente añadimos  maxcpus=1 lo cual obliga a el sistema a iniciarse con un solo core, pero con el otro en la recámara

Además modificando el archivo del buildroot

package/base-files/files/etc/rc.local

cuyo contenido será este 

# Put your custom commands here that should be executed once

# the system init finished. By default this file does nothing.

echo 1 > /sys/devices/system/cpu/cpu1/online

exit 0

Siento no adjuntar parche, pero me temo que no se aplicaría de forma limpia en el archivo del kernel, el cual cambia según lo que tenga cada uno seleccionado del kernel. Además por algún motivo a mi los subtargets no me funcionan, tengo que hacer todo a mano. De todas hacer lo que he descrito es más simple que tocar un sonajero.

Como curiosidad decir que de esta forma cuando se pone online el segundo core, el bogomips es idéntico al del primero, mientras que cuando lo hace mientras arranca el sistema, calcula diferentes bogomips. Ahora mismo lo que voy a probar es no usar este workaround, y sí forzar el bogomips a un valor para ambos cores.

Espero respuestas de algún test :)

[JaR]

Sin darme cuenta, había respondido únicamente a danitool.

Reenvío el mensaje al grupo.

Para compilar, estoy usando el repositorio de Pteridium: https://github.com/Pteridium/Attitude-Adjustment-ARV4518PWR01 -b devel

Por cierto, cual es el fichero que hay que editar para incluir estos cambios ?

 [*] Support for hot-pluggable CPUs

y

[*] Built-in kernel command line

 (root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 maxcpus=1)

---------- Mensaje reenviado ----------
De: JaR <jar...@gmail.com>
Fecha: 4 de enero de 2014, 12:34
Asunto: Re: Fw: SMP y FPU emulation en BCM6368
Para: dgcbueu <dgc...@gmail.com>

La idea es buena, yo también lo había pensado pero no sabía si era posile (lo de iniciar con un único core), ahora veremos si funciona ...

En cuanto pueda, voy a hacer una compilación con SMP activa y tus directrices.

Ya contaré ...

Saludos.

[dani]

lo haces en el menú del kernel

make kernel_menuconfig

[dani]

o bien si quieres cambiar el archivo en cuestión, que tal vez sea más bien lo que preguntas sería en el archivo

target/linux/brcm63xx/config-3.10

dependiendo de la versión del kernel ese archivo puede tener una numeración diferente

[JaR]

Ok. 

Esta tarde me pongo a ello.

[JaR]

Probado y el tampoco se resuelve.

Curiosamente, parece que la corrupción de los nombres de los ficheros sólo ocurre en /mnt y tampoco siempre ...

La verdad, es que un tema 'mosqueante' XD

Saludos.

[dani]

No estarás usando el barrier braker de Noltari no?
https://github.com/openwrt-es/barrier-breaker-openwrt/commits/barrier-breaker_13.12_smp

todavia no dispone del fix que propongo, y además el parche que tiene

https://github.com/openwrt-es/barrier-breaker-openwrt/commit/3c7117304bdaf081c8c2f598a11015e4ebac1fcf

hace inútil el comando añadido en rc.local

[JaR]

Rectifico, la corrupción de nombres, ocurre en varios sitios :(

El 5 de enero de 2014, 17:51, JaR <jar...@gmail.com> escribió:

[JaR]

Pues no. He usado el repo de Pteridium.

Me espero entonces ... porque la verdad, me estoy volviendo un poco majara con este tema XD

El 5 de enero de 2014, 17:54, dani <dgc...@gmail.com> escribió:

No estarás usando el barrier braker de Noltari no?

https://github.com/openwrt-es/barrier-breaker-openwrt/commits/barrier-breaker_13.12_smp

todavia no dispone del fix que propongo, y además el parche que tiene

https://github.com/openwrt-es/barrier-breaker-openwrt/commit/3c7117304bdaf081c8c2f598a11015e4ebac1fcf

hace inútil el comando añadido en rc.local

El 5 de enero de 2014, 17:51, JaR <jar...@gmail.com> escribió:

[dgcbueu]

Bien descartado todo lo anterior.

Propongo un nuevo workaround, simplemente consiste en añadir iscolcpus=0 al [*] Built-in kernel command line, del menú del kernel quedando algo tal que así. 

[*] Built-in kernel command line

(root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 isolcpus=0)

El resto de opciones serán las que hay por defecto para el subtarget SMP. Ya desde el primer arranque incluso usando imágenes jffs2 (las más conflictivas), todo me funciona correctamente, y no detecto nada extraño en los nombres de ficheros.

==========================================

Lo que hace isolcpus es aislar una cpu del scheduler (programador de tareas) del kernel, con lo cual los procesos se ejecutarán en una sola cpu. Pero todavía las interrupciones serán manejadas por la otra CPU, y algunos procesos del kernel, con lo cual todavía podemos obtener ventajas del SMP con una CPU "aislada".

Si esto funciona (jar espero algún test :) ), entonces podría irse al siguiente paso que sería establecer afinidad de los procesos que nos interesen en una u otra CPU, para de esta forma balancear manualmente la carga, no sería en absoluto complicado, además normalmente siempre corremos los mismos procesos en un firmware determinado con lo cual, sería repartir por ejemplo los 2 que mayor carga tengan para ambas cpus (uno paquí otro pallí).

Saludos

Ok. 

---------- Mensaje reenviado ----------
De: JaR <ja...@gmail.com>

Fecha: 4 de enero de 2014, 12:34
Asunto: Re: Fw: SMP y FPU emulation en BCM6368

Para: dgcbueu <dg....@gmail.com>

[dani]

Las pruebas las hago en un Netgear DGND3700v1, algo similar al Comtrend que usa Noltari. Ese repositorio de Pteridim me parece bien para hacer la prueba.

Con isolcpus=0, y dando prioridad a la dcache al segundo core con el siguiente código

set_c0_brcm_cmt_ctrl(1 << 5);

 Consigo en transferencia directa con wget a /dev/null dentro del router una tasa aproximada de 18MB/s cosa que antes no era capaz de conseguir (como mucho llegaba hasta 12MB/s). Esto significa que con isolcpus todavía sacamos partido al SMP, sin necesidad de configurar nada más.

El 20 de enero de 2014, 11:35, JaR <jar...@gmail.com> escribió:

Con qué router estás haciendo tú las pruebas ?

Curiosamente, en los dos que voy usando, el vr3025un y el vr3025u, siempre tengo más problemas con el segundo ¿?

A ver si saco un rato para compilar y hacer algunos test.

Tengo pensado usar el repositorio de Pteridium

git clone https://github.com/Pteridium/Attitude-Adjustment-ARV4518PWR01 -b devel

Saludos.

[JaR]

Vale.

Y ese código dónde lo pones ?

[dani]

De momento olvídate de ese código, primero prueba únicamente isolcpus, si funciona luego pasamos al siguiente paso, que podría ser añadir ese código.

[JaR]

Me pongo a ello.

Ya iré comentando ...

Saludos.

[JaR]

Bueno, pues de momento, las pruebas paradas. La compilación resultante me deja 'frito' el vr3025un.

Porqué ? Ni idea, el cable serial usb se lo he prestado a un colega.

Voy a probar a compilar con este otro repositorio de Pteridium (a ver si hay más suerte):

git clone it://github.com/Pteridium/openwrt-1.git -b bcm63xx-r38342

Por cierto, danitool, tenías razón, la imagen que se ve en la wiki, no se correponde con este router, si no con la del vr3025u: http://wiki.openwrt.org/_detail/toh/comtrend/vr3025u_board_serial.jpg?id=toh%3Acomtrend%3Avr3025un

Aquí tienes un par de fotos, por si quieres cambiarlas:
http://www.mediafire.com/view/42f4bjugfcsn6f0/IMG_20140121_113309.jpg
http://www.mediafire.com/view/cwh9lq60igs55kc/IMG_20140121_113331.jpg

Saludos.

[dani]

El backport de Pteridium con SMP a AA había ya sido testeado?

Tenías deshabilitado kexec en el kernel?, porque eso impide que arranque con SMP.

[JaR]

Con el nuevo repositorio, ya no ha habido problemas.

Ya está instalado el firmware.

He creado unos cuantos directorios, instalado/configurado aplicaciones y de momento ... no veo corrupción de datos.

Voy a seguir testeando un poco más. Lo siguiente, será ponerlo en vr3025u (este lo tengo todo el día descargando cosas) y ver qué tal va.

Iré contando ...

Saludos.

[José Vázquez]

El 20/1/14, dani <dgc...@gmail.com> escribió:

> Las pruebas las hago en un Netgear DGND3700v1, algo similar al Comtrend que
> usa Noltari. Ese repositorio de Pteridim me parece bien para hacer la
> prueba.
>
>
>
> Con isolcpus=0, y dando prioridad a la dcache al segundo core con el
> siguiente código
>

>> *set_c0_brcm_cmt_ctrl(1 << 5);*

>
> Consigo en transferencia directa con wget a /dev/null dentro del router
> una tasa aproximada de 18MB/s cosa que antes no era capaz de conseguir
> (como mucho llegaba hasta 12MB/s). Esto significa que con isolcpus todavía
> sacamos partido al SMP, sin necesidad de configurar nada más.
>

Le he echado un ojo y va tal cual danitool dijo. Ahora vienen las preguntas:
- ¿Exactamente qué hace isolcpus? No lo tengo del todo claro, y lo
único que entendí es que es útil cuando quieres que algo se ejecute en
tiempo real, tanto programas como interrupciones, cambiando las
afinidades.
- ¿Cómo es que se consigue un aumento de rendimiento usando isolcpus=0
y poniendo la prioridad de D-cache en CPU1? Lo único que maneja esa
cpu son las softirqs, mientras que las hardirqs las maneja CPU0.

¡Enhorabuena por el hallazgo danitool!

Un saludo.

[dani]

Como bien dices las IRQs, por hardware (por software todavía no lo tengo claro), las maneja el core 0, isolcpus=0 aisla ese core, pero todavía seguirá manejando las IRQs. 

Una vez aislado, ningún proceso se ejecutará en el core 0, todos se ejecutan en el core 1, y es en este donde doy prioridad a la Dcache, con suerte la Dcache apenas necesitará uso en el core 0 (principalmente se dedicará a manejar interrupciones proceso que presupongo no necesita usar Dcache). 

Las aplicaciones que ejecutará nuestro sistema (en el core 1) sí que necesitan uso intensivo de la Dcache, y por ello doy prioridad a esta.

Como resultado tenemos, por ejemplo que si intentamos transferir en red, los dos cores se pondrán al 100 de carga de trabajo, uno manejando interrupciones y el otro ejecutando el software con prioridad para usar la Dcache.

Todo esto que comento está basado en tests, con el SMP que hay por defecto jamás fui capaz de poner ambos cores al 100% transfiriendo un archivo, siempre toda la carga va hacia el primer core, y el segundo no es capaz de exprimir más del 50%. Sin embargo con la configuración que propongo sí, y pasé de transferir a 12 MB/s a 18 MB/s.

De que es lo que hace isolcpus, simplemente hace que todos los procesos vayan al core no aislado. Pero todavía quedarán unos pocos procesos del kernel que se ejecutan en ambos cores (comprobado con taskset).

Este rollo lo suelto solo para indicar que el SMP no es una maravilla aunque eliminásemos el problema de la corrupción de ficheros. Para exprimirlo bien habrá que hacer configuraciones manuales como la que propongo. Esto vendría a ser más que un SMP, un BMP.

http://www.qnx.org/developers/docs/6.3.2/neutrino/sys_arch/smp.html#BMP

[JaR]

Siento traer malas noticias pero ... después de instalar el firmware en el vr3025u, instalar algunas aplicaciones y reiniciar, sigo teniendo la corrupción en los nombres :(

root@vr3025u:~# ls /mnt/
0g0gasas  gigis?s

Los directorios son 35gigas y 130gigas

Pero no ocurre todas las veces

[dani]

Entonces esta corrupción está ocurriendo fuera de rootfs_data no? entiendo que te ocurre en un disco duro externo con otro formato, con lo que quedaría descartado que el problema es del driver jffs2. 

Podrías probar en lugar de isolcpus=0, poner isolcpus=1?.

[JaR]

---------- Mensaje reenviado ----------
De: JaR <jar...@gmail.com>
Fecha: 22 de enero de 2014, 12:12
Asunto: Re: SMP y FPU emulation en BCM6368
Para: dani <dgc...@gmail.com>

A ver si me explico bien ...

Creo 2 directorios dentro de /mnt para montar las particiones de un disco duro

Y según le da al reiniciar (a veces sí, y otras no), les cambia el nombre a los directorios.

Lógicamente, si les ha cambiado el nombre, las particiones no se montan.

Esto mismo, venía ocurriendo en otras compilaciones, pero además, detecté que ocurría con los scripts de inicio (los alojados en /etc/init.d) y con algunos paquetes/aplicaciones instaladas a posteriori.

Y sí, probaré con una nueva compilación y el parámetro isolcpus=1

El 22 de enero de 2014, 11:28, dani <dgc...@gmail.com> escribió:

Entonces esta corrupción está ocurriendo fuera de rootfs_data no? entiendo que te ocurre en un disco duro externo con otro formato, con lo que quedaría descartado que el problema es del driver jffs2. 

Podrías probar en lugar de isolcpus=0, poner isolcpus=1?.

El 22 de enero de 2014, 9:33, JaR <jar...@gmail.com> escribió:

[JaR]

Nada, idéntico resultado :(

[dani]

Me lo temía. El caso que tanto con isolcpus=0 como isolcpus=1, la mayoría de procesos del kernel se ejecutan en ambos cores. Para aclarar cuales son, cuando hacemos el comando ps, son los que aparecen entre corchetes [ ].

Estos procesos del kernel como ya digo se ejecutan con afinidad en ambos cores 0 y 1. Y no veo manera de hacer que todos se vayan a un core, bueno, sí la hay y es desactivando una CPU pero cuando volvemos a activarla recobran afinidad por ambos cores con lo que estamos en las mismas.

Si el problema fuese de uno de esos procesos del kernel, sería cuestión de aislarlo para que solo se ejecute en un solo core. Se puede hacer desde espacio de usuario, pero una vez que arranca el sistema ya habría siempre posibilidades de que la corrupcion ya fuese causada previamente a establecer la afinidad

Habría que hacerlo desde el propio kernel, modificando código, hasta ahora solo pude aislar 2 procesos para que se vayan a un solo core. El resto no sé de que forma se lanza el proceso, hay miles de líneas de código que no entiendo.

[José Vázquez]

El 27/1/14, dani <dgc...@gmail.com> escribió:

> Me lo temía. El caso que tanto con isolcpus=0 como isolcpus=1, la mayoría
> de procesos del kernel se ejecutan en ambos cores. Para aclarar cuales son,
> cuando hacemos el comando ps, son los que aparecen entre corchetes [ ].
>
> Estos procesos del kernel como ya digo se ejecutan con afinidad en ambos
> cores 0 y 1. Y no veo manera de hacer que todos se vayan a un core, bueno,
> sí la hay y es desactivando una CPU pero cuando volvemos a activarla
> recobran afinidad por ambos cores con lo que estamos en las mismas.
>
> Si el problema fuese de uno de esos procesos del kernel, sería cuestión de
> aislarlo para que solo se ejecute en un solo core. Se puede hacer desde
> espacio de usuario, pero una vez que arranca el sistema ya habría siempre
> posibilidades de que la corrupcion ya fuese causada previamente a
> establecer la afinidad
>
> Habría que hacerlo desde el propio kernel, modificando código, hasta ahora
> solo pude aislar 2 procesos para que se vayan a un solo core. El resto no
> sé de que forma se lanza el proceso, hay miles de líneas de código que no
> entiendo.
>
>

Añadiendo algo de debug en el kernel apareció esto:

[ 6.228000] usbcore: registered new interface driver usb-storage
kmod: ran 1 iterations
[ 7.484000] jffs2: notice: (307) jffs2_build_xattr_subsystem:
complete building xattr subsystem, 1 of xdatum (0 unchecked,.
[ 7.504000] ------------[ cut here ]------------
[ 7.504000] WARNING: at lib/debugobjects.c:260 debug_print_object+0xb8/0xe4()
[ 7.504000] ODEBUG: assert_init not available (active state 0)
object type: timer_list hint: stub_timer+0x0/0x10
[ 7.504000] Modules linked in: usb_storage ohci_hcd ehci_platform
ehci_hcd sd_mod scsi_mod ext4 crc16 jbd2 mbcache usbcore nls_base
usb_common crypto_hash
[ 7.504000] CPU: 0 PID: 307 Comm: block Not tainted 3.10.28 #14
[ 7.504000] Stack : 00000000 00000000 8038b7aa 00000033 00000000
82dc0f10 802cc440 8032ff73
00000133 00000000 8038af60 82dc0f10 83820870 0045d65c
7f9c6ee0 80037ebc
80337dc0 800354c8 00000000 00000000 802cf494 82813c8c
82813c8c 802cc440
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 82813c20
...
[ 7.504000] Call Trace:
[ 7.504000] [<8002b388>] show_stack+0x48/0x70
[ 7.504000] [<800355bc>] warn_slowpath_common+0x78/0xa8
[ 7.504000] [<80035618>] warn_slowpath_fmt+0x2c/0x38
[ 7.504000] [<8018bdd4>] debug_print_object+0xb8/0xe4
[ 7.504000] [<8018ccf0>] debug_object_assert_init+0xd0/0x13c
[ 7.504000] [<80044958>] del_timer+0x20/0x7c
[ 7.504000] [<80050a04>] try_to_grab_pending+0x40/0x1c0
[ 7.504000] [<80051f94>] __cancel_work_timer+0x34/0x13c
[ 7.504000] [<8014a0d8>] jffs2_sync_fs+0x20/0x50
[ 7.504000] [<8010314c>] sync_filesystem+0x60/0xbc
[ 7.504000] [<800d96e0>] generic_shutdown_super+0x34/0xdc
[ 7.504000] [<801ceb10>] kill_mtd_super+0x14/0x30
[ 7.504000] [<80149f08>] jffs2_kill_sb+0x34/0x4c
[ 7.504000] [<800d9514>] deactivate_locked_super+0x48/0x84
[ 7.504000] [<800f60c0>] SyS_umount+0x32c/0x3a0
[ 7.504000] [<800128e8>] stack_done+0x20/0x44
[ 7.504000]
[ 7.504000] ---[ end trace f22e11b80f2bef12 ]---
mount_root: jffs2 is ready
[ 7.700000] jffs2: notice: (304) jffs2_build_xattr_subsystem:
complete building xattr subsystem, 1 of xdatum (0 unchecked,.
ifconfig: SIOCGIFFLAGS: No such device
procd: - early -

Parece que está claro que el fallo está en el driver jffs2, pero ni
idea si es debido a los parches de openwrt para jffs2, el driver del
kernel o la implementación de SMP para los BCM63XX.

Off topic: el parche adjunto mejora el rendimiento de las
transferencias por red entre un 0'5 y un 1% con la cpu cargada a tope,
así que a saber cómo va con un wget.

[dani]

En mi opinión el driver jffs2 dista de ser perfecto. Alguien se acuerda de cuando instalábamos imágenes jffs2, y de ahí a cierto tiempo el router arranncaba con CFE parado sin reconocer lo que había en la flash?. O actualmente alguna gente por motivos no muy claros, a veces arranca el router con toda la configuración perdida.

A mi en concreto me extraña que siempre indica 2 archivos huérfanos encontrados después del segundo inicio, use uno bcm6348, 6358 ó prácticamente cualquier router, y eso desde los tiempos de Backfire hasta ahora.

Sobre el parche del checksum, me gustaría saber que hace exactamente, en que condiciones se dan los unaligned_data por saber su utilidad. Para justificar el envío del parche bien a Openwrt, ó linux-mips.org.  Tal vez si se pudiesen añadir unos printk para que mostrase si se usa con mucha frecuencia daría alguna pista, o én que condiciones tira de ese código el kernel.

[José Vázquez]

El 28/1/14, dani <dgc...@gmail.com> escribió:

> En mi opinión el driver jffs2 dista de ser perfecto. Alguien se acuerda de
> cuando instalábamos imágenes jffs2, y de ahí a cierto tiempo el router
> arranncaba con CFE parado sin reconocer lo que había en la flash?. O
> actualmente alguna gente por motivos no muy claros, a veces arranca el
> router con toda la configuración perdida.
>
> A mi en concreto me extraña que siempre indica 2 archivos huérfanos
> encontrados después del segundo inicio, use uno bcm6348, 6358 ó
> prácticamente cualquier router, y eso desde los tiempos de Backfire hasta
> ahora.
>

Pues estamos bien fastidiados...
¿Y si se prueba con ubifs? Se usa básicamente para flash nand, pero
también se puede usar con las nor.
Voy a mandar el error que soltó al mailing list de openwrt a ver si a
alguien se le enciende la bombilla.

>
> Sobre el parche del checksum, me gustaría saber que hace exactamente, en
> que condiciones se dan los unaligned_data por saber su utilidad. Para
> justificar el envío del parche bien a Openwrt, ó linux-mips.org. Tal vez
> si se pudiesen añadir unos printk para que mostrase si se usa con mucha
> frecuencia daría alguna pista, o én que condiciones tira de ese código el
> kernel.
>

Esta es la explicación del problema con unaligned data en mips:
http://www.linux-mips.org/wiki/Alignment#Problems_of_the_MIPS_Unaligned_Load_Instructions
Lo que genera unaligned data son, sobre todo, los paquetes TCP, y lo
que hace ese parche es, hasta donde entiendo, alinear la cabecera del
paquete para luego hacer el checksum, ya que las cpu MIPS pierden
mucho tiempo procesando ese tipo de datos e instrucciones, mientras
que otras arquitecturas no sufren ese problema.
http://code.google.com/p/lz4/issues/detail?id=4
Código donde se usa ip_fast_csum:
http://lxr.free-electrons.com/ident?v=3.10&a=mips&i=ip_fast_csum

Un saludo.