PLIS-PLAS escribió:SPLATTER, solo ten precauciones si tu fat es de 95nm y el ventilador zumba mucho, no creo que pase nada en tu fat que es de 65 si no recuerdo mal.
Mira el wiki.
Recuerda que esto es solo una observacion que no ha sido demostrada cientificamente o tecnicamente.
![[triston]](/images/smilies/nuevos/triste_ani2.gif "tristón")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
valf0r escribió:PLIS-PLAS escribió:SPLATTER, solo ten precauciones si tu fat es de 95nm y el ventilador zumba mucho, no creo que pase nada en tu fat que es de 65 si no recuerdo mal.
Mira el wiki.
Recuerda que esto es solo una observacion que no ha sido demostrada cientificamente o tecnicamente.
Para un completo novato, como sabes si tu fat es 95nm? Busco por los faq pero no lo veo
La mia es una fat de 40gb, aun no le he puesto nada y me esta dando miedo que salga fuego
valf0r escribió:PLIS-PLAS escribió:SPLATTER, solo ten precauciones si tu fat es de 95nm y el ventilador zumba mucho, no creo que pase nada en tu fat que es de 65 si no recuerdo mal.
Mira el wiki.
Recuerda que esto es solo una observacion que no ha sido demostrada cientificamente o tecnicamente.
Para un completo novato, como sabes si tu fat es 95nm? Busco por los faq pero no lo veo
La mia es una fat de 40gb, aun no le he puesto nada y me esta dando miedo que salga fuego
Gus_Tineo escribió:valf0r escribió:PLIS-PLAS escribió:SPLATTER, solo ten precauciones si tu fat es de 95nm y el ventilador zumba mucho, no creo que pase nada en tu fat que es de 65 si no recuerdo mal.
Mira el wiki.
Recuerda que esto es solo una observacion que no ha sido demostrada cientificamente o tecnicamente.
Para un completo novato, como sabes si tu fat es 95nm? Busco por los faq pero no lo veo
La mia es una fat de 40gb, aun no le he puesto nada y me esta dando miedo que salga fuego
Mi Fat de 40GB sonaba que daba miedo, tenía que jugar con auriculares porque se oía más que la tele. Además se calentaba muchísimo, incluso se apagaba del calor. Seguí un tutorial de Youtube poniendo una plaquita de madera en el disipador y ahora ni se escucha, y bajó una media de 20º la temperatura
[/quote]Estwald escribió:chekcoca escribió:
LOL , yo creo que también lo tengo por hay , recuerdo que estuvimos intentado que girara a menos potencia pero no se pudo
¿Pero giraba al 100% hacia dentro o hacia fuera?. Por que yo se que en ciertos modelos hay una manera de hacer que los ventiladores giren al revés para limpiar la consola o algo así y a lo mejor es eso lo que estabais activando (el test del ventilador).
De todas formas, si la gente se guarda de alguna manera la información que tiene, otros no le pueden sacar utilidad práctica. ¿Habéis pensado que no importa un pepino si gira a toda velocidad, si existe la posibilidad de poder conectarlo cuando se precise y de desconectarlo
cuando ya no haga falta?
chekcoca escribió:ahi tienes el pkg creo que era este y rulaba en 3.56 , tengo mas test guardados por si quieres echarle un ojo cualquier cosa avisame
https://mega.co.nz/#!BE0iGIbS!ECKEdxbSj ... NIwg-tp3ec
.
. Por suerte podía pasar al modo 1 pulsando un botón y ahí se ha activado el ventilador (a tope!) y ahí he podido comprobar que no es simplemente, una manera de desconectar el ventilador el modo 1, si no que se autorregulaba. La velocidad mínima es 0 y la máxima, 0xff en éste modo 2. Sandungas escribió:Muy interesante, me dan ganas de añadir esos parametros en ps3devwiki, aunque parece que ya lo tienes casi completamente identificado, cuando averigues que es la X del final por favor explicalo en algun lado y lo añadimos a ps3devwiki
Por lo que has dicho entiendo que los modos serian estos:
0, 0, x -> max
0, 1, x -> auto
0, 2, x -> manual
Lo raro es que la X este presente en los otros aunque solo se usa en el modo manual, tambien el rango (de 0x00 a 0xff) parece bastante alto
En cuanto a lo "que podria pasar" si el gameOS se cuelga... yo supongo que el syscon toma el control, pero solo es una suposicion basada en la cantidad de crashes que he visto haciendo pruebas raras con el XMB (y he visto muchos)
En la mayoria de los crashes la consola se puede apagar con el boton de on/off (y ese boton tambien esta conectado al syscon, asi que no esta completamente k.o.)... solo en unos pocos de los crashes que he visto la consola no responde al boton on/off... a esos crashes yo los considero un "crash de syscon"
Se podria hacer un programa que pusiera el ventilador al max... y luego forzase un crash... ahi se veria si el control pasa al syscon (se reduciria la velocidad porque pasaria al modo auto... que supongo que es el "por defecto")
Gracias por la info, y ten cuidado con los tests
). En cambio en 0, 2, X no permanece, por lo que se ve que es un modo independiente del syscon. . En este modo el syscon podría apagar la consola mediante la señal de alarma de temperatura, pero no hace regulación de la velocidad del ventilador (si fuera lo contrario, no serviría de nada el modo ) Estwald escribió:Por cierto, si fijas 0, 0, X con el ventilador a toda leche (independientemente del valor de X), si apagas la consola con el piloto rojo y vuelves a encenderla, sigue con el ventilador a toda leche
Psmaniaco escribió:Sinos permitiese el control del ventilador estupendo, pero si es por hardware a ver que se puede hacer.
Un saludo.
).![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
(habrá que abrir otro hilo). Estwald escribió:Psmaniaco escribió:Sinos permitiese el control del ventilador estupendo, pero si es por hardware a ver que se puede hacer.
Un saludo.
Podemos controlar el ventilador por software a nuestro gusto, gracias a la llamada esa: al menos en mi vieja FAT es así (en otros modelos, ni idea, pero en esta puedo ir aumentando la velocidad de forma progresiva, hasta que zumba como un aspirador
De momento he conseguido desbloquear la medida de temperaturas, que requería permisos ROOT, (mediante un único parche que deshabilita una rutina tocacojones), por lo que ya tenemos medidor por software liberado
Ahora lo que interesa es ver la get fan policy que mencionaba Sandungas (policy es de política) para ver que es lo que fija el sistema y así poder movernos en la horquilla de cederle al sistema el control cuando nos interese y retomarlo nosotros cuando gustemos, de forma segura.
Cuando termine de echarle un ojo en condiciones, no os preocupéis que tendréis el código fuente con los parches necesarios para habilitar las llamadas desde CFW 4.40 y así poder echarle un ojillo al tema
Pero tened un poco de paciencia, que sólo tengo dos manos
Saludos
![[bye]](/images/smilies/nuevos2/adio.gif "adios")
Sandungas escribió:Estwald escribió:Por cierto, si fijas 0, 0, X con el ventilador a toda leche (independientemente del valor de X), si apagas la consola con el piloto rojo y vuelves a encenderla, sigue con el ventilador a toda leche
Esa diferencia es bastante importante, en parte es normal que lo pueda mantener porque cuando la ps3 esta en standby el syscon esta activo (el led on/off tambien esta conectado al syscon, asi que si el led esta encendido.... el syscon esta "vivo")... aunque seguramente este en modo inactivo de bajo consumo de energia y solo responde a señales basicas
Para "resetearlo" hay que apagar la PS3 de la corriente (como en la epoca del jailbreak con los dongles usb que habia que apagar de atras)
Apagaste la PS3 de la corriente entre los tests ?... es curioso que el modo "max" lo recuerde y el "manual" no... aunque quizas esta diseñado para funcionar asi, los valores del "manual" desaparecen cuando muere gameOS y el "max" se mantiene por seguridad (o por otras razones que aun no entendemos)
Edit: en ps3devwiki hay otra syscall que te sera util, imagino que ya la habias visto, pero porsiaca:
0x199
sys_sm_get_fan_policy
int sys_sm_get_fan_policy (in:uint8, out:uint8[1], out:uint8[1], out:uint8[1], out:uint8[1])
(id, st, policy, mode, duty)
Lo mas interesante es que vienen identificados los nombres de los parametros, los 3 del final parecen comunes con la otra sycall
id = id de dispositivo
st = estado del dispositivo
policy = ni idea (no se ni traducirlo)
mode = los 3 modos que tu has identificado
duty = carga de trabajo
![[tadoramo]](/images/smilies/adora.gif "Adorando")
Estwald escribió:Psmaniaco escribió:Sinos permitiese el control del ventilador estupendo, pero si es por hardware a ver que se puede hacer.
Un saludo.
Podemos controlar el ventilador por software a nuestro gusto, gracias a la llamada esa: al menos en mi vieja FAT es así (en otros modelos, ni idea, pero en esta puedo ir aumentando la velocidad de forma progresiva, hasta que zumba como un aspirador
De momento he conseguido desbloquear la medida de temperaturas, que requería permisos ROOT, (mediante un único parche que deshabilita una rutina tocacojones), por lo que ya tenemos medidor por software liberado
Ahora lo que interesa es ver la get fan policy que mencionaba Sandungas (policy es de política) para ver que es lo que fija el sistema y así poder movernos en la horquilla de cederle al sistema el control cuando nos interese y retomarlo nosotros cuando gustemos, de forma segura.
Cuando termine de echarle un ojo en condiciones, no os preocupéis que tendréis el código fuente con los parches necesarios para habilitar las llamadas desde CFW 4.40 y así poder echarle un ojillo al tema
Pero tened un poco de paciencia, que sólo tengo dos manos
Saludos
Estwald escribió:Psmaniaco escribió:Sinos permitiese el control del ventilador estupendo, pero si es por hardware a ver que se puede hacer.
Un saludo.
Podemos controlar el ventilador por software a nuestro gusto, gracias a la llamada esa: al menos en mi vieja FAT es así (en otros modelos, ni idea, pero en esta puedo ir aumentando la velocidad de forma progresiva, hasta que zumba como un aspirador
De momento he conseguido desbloquear la medida de temperaturas, que requería permisos ROOT, (mediante un único parche que deshabilita una rutina tocacojones), por lo que ya tenemos medidor por software liberado
Ahora lo que interesa es ver la get fan policy que mencionaba Sandungas (policy es de política) para ver que es lo que fija el sistema y así poder movernos en la horquilla de cederle al sistema el control cuando nos interese y retomarlo nosotros cuando gustemos, de forma segura.
Cuando termine de echarle un ojo en condiciones, no os preocupéis que tendréis el código fuente con los parches necesarios para habilitar las llamadas desde CFW 4.40 y así poder echarle un ojillo al tema
Pero tened un poco de paciencia, que sólo tengo dos manos
Saludos
![[snif]](/images/smilies/nuevos/triste_ani1.gif "llorando")
). ![[+furioso]](/images/smilies/nuevos/furioso.gif "muy furioso")
Estwald escribió:A ver si mañana termino el tema:
De momento lo tengo así: con get fan policy he podido comprobar lo que comentaba de los cmd 0 y 1: que pasa del tercer parámetro. Contrariamente a lo que opinaba, si apagas la consola con el pilotito rojo, el modo 2 no se elimina: lo que ocurre es que el SYSCON le fija el valor de velocidad 0x4d que es un perfíl bajo de sonido y algo más alto de lo que suele poner en modo automático.
Por lo que he visto, cualquier valor por debajo de 0x33 es cambiado por el SYSCON a ese mínimo, que es claramente insuficiente y en modo 1 (el automático), asciende a 0x40, 0x4d ... cuando la CPU alcanza 74 grados. Por otro lado, si se fija el modo 2 con un valor que provoque la alarma de temperatura, el piloto se vuelve rojo, se lanza un pitido y acto seguido, en el mismo modo 2, se fija la velocidad al máximo 0xff. Así que sabemos que en caso de insuficiente caudal de aire, al menos tenemos una protección.
Con todo esto, primero he hecho una aplicación que pudiera poner cualquiera de los 3 modos y en el 2, permitiera seleccionar la velocidad del ventilador, mientras se monitorizan las temperaturas y también se muestra el resultado de get fan policy (algo parecido a lo que teníais vosotros hecho con el potenciómetro, pero obviamente, por software y sin posibilidad de regularlo desde fuera de la aplicación)
Luego ha venido la parte chunga: el payload. Lo más complicado de todo, es que para tomar la temperatura, necesito una dirección en memoria de Game OS que permita ser escrita y que pueda identificarla de forma que no se pete el sistema por acceder a una rgión de memoria sin asignar.
Al final, he elegido una syscall relacionada con la asignación de memoria: con esta consigo tener un puntero válido para poder trabajar (preservando el contenido original) y con la sys_process_exit() (syscall 22) me informo de si hemos salido de la aplicación y en ese caso, ajusto un modo por defecto (con velocidad 0x60) que es la velocidad que queda en el XMB (ahí no puedo ni monitorizar, ni hacer variación de velocidad en principio. De ahí que elija una velocidad que se que no habrá problemas).
En cuanto a los juegos y aplicaciones, esto se basa en la monitorización de usleep() y para evitar ralentizar el sistema, hago que solo uno de cada 2000 (y eso solo si coincide la ID del proceso) monitorice /ajuste la temperatura. En principio, el control lo hago en base a la temperatura de la CPU, que siempre es más alta y en mi caso he elegido una horquilla para que trabaje entre los 61 y 63 grados preferentemente (con velocidades entre 0x50 en subida y 0x60 en bajada) mientras que por debajo de esa temperatura, el mínimo es 0x4d y por encima se aumenta la velocidad muy rápidamente (alcanzando el máximo (0xff) en los 75 grados) para rebajar la temperatura en el margen de trabajo que he fijado, de forma rápida.
Obviamente, quedan cosas que pulir y testear y de eso me ocuparé mañana
Saludos
![[plas]](/images/smilies/aplauso.gif "Aplausos")
, muchisimas gracias. ![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
(Todos sabemos que no ![[jaja]](/images/smilies/nuevos2/otrasonrisa.gif "otra sonrisa")
)Estwald escribió:A ver si mañana termino el tema:
De momento lo tengo así: con get fan policy he podido comprobar lo que comentaba de los cmd 0 y 1: que pasa del tercer parámetro. Contrariamente a lo que opinaba, si apagas la consola con el pilotito rojo, el modo 2 no se elimina: lo que ocurre es que el SYSCON le fija el valor de velocidad 0x4d que es un perfíl bajo de sonido y algo más alto de lo que suele poner en modo automático.
Por lo que he visto, cualquier valor por debajo de 0x33 es cambiado por el SYSCON a ese mínimo, que es claramente insuficiente y en modo 1 (el automático), asciende a 0x40, 0x4d ... cuando la CPU alcanza 74 grados. Por otro lado, si se fija el modo 2 con un valor que provoque la alarma de temperatura, el piloto se vuelve rojo, se lanza un pitido y acto seguido, en el mismo modo 2, se fija la velocidad al máximo 0xff. Así que sabemos que en caso de insuficiente caudal de aire, al menos tenemos una protección.
Con todo esto, primero he hecho una aplicación que pudiera poner cualquiera de los 3 modos y en el 2, permitiera seleccionar la velocidad del ventilador, mientras se monitorizan las temperaturas y también se muestra el resultado de get fan policy (algo parecido a lo que teníais vosotros hecho con el potenciómetro, pero obviamente, por software y sin posibilidad de regularlo desde fuera de la aplicación)
Luego ha venido la parte chunga: el payload. Lo más complicado de todo, es que para tomar la temperatura, necesito una dirección en memoria de Game OS que permita ser escrita y que pueda identificarla de forma que no se pete el sistema por acceder a una rgión de memoria sin asignar.
Al final, he elegido una syscall relacionada con la asignación de memoria: con esta consigo tener un puntero válido para poder trabajar (preservando el contenido original) y con la sys_process_exit() (syscall 22) me informo de si hemos salido de la aplicación y en ese caso, ajusto un modo por defecto (con velocidad 0x60) que es la velocidad que queda en el XMB (ahí no puedo ni monitorizar, ni hacer variación de velocidad en principio. De ahí que elija una velocidad que se que no habrá problemas).
En cuanto a los juegos y aplicaciones, esto se basa en la monitorización de usleep() y para evitar ralentizar el sistema, hago que solo uno de cada 2000 (y eso solo si coincide la ID del proceso) monitorice /ajuste la temperatura. En principio, el control lo hago en base a la temperatura de la CPU, que siempre es más alta y en mi caso he elegido una horquilla para que trabaje entre los 61 y 63 grados preferentemente (con velocidades entre 0x50 en subida y 0x60 en bajada) mientras que por debajo de esa temperatura, el mínimo es 0x4d y por encima se aumenta la velocidad muy rápidamente (alcanzando el máximo (0xff) en los 75 grados) para rebajar la temperatura en el margen de trabajo que he fijado, de forma rápida.
Obviamente, quedan cosas que pulir y testear y de eso me ocuparé mañana
Saludos
·Mierda inservible
·"Estabilidad del sistema"
·Capado Online por un rato
Resúmen de las grandes ventajas de 4.41: Ninguna
MrMento escribió:Sorpresa!!!
http://es.playstation.com/ps3/support/s ... v-4-41%29/
Mejoras:·Mierda inservible
·"Estabilidad del sistema"
·Capado Online por un rato
Resúmen de las grandes ventajas de 4.41: Ninguna
![[buuuaaaa]](/images/smilies/nuevos/triste_ani3.gif "a lágrima viva")
ssecarlos escribió:MrMento escribió:Sorpresa!!!
http://es.playstation.com/ps3/support/s ... v-4-41%29/
Mejoras:·Mierda inservible
·"Estabilidad del sistema"
·Capado Online por un rato
Resúmen de las grandes ventajas de 4.41: Ninguna
Putadon!! he ido a actualizar el pes 2013 y me pedia actualizar a 4.41
toca esperar a cfw 4.41
no se puede hablar todavía de algo así habiendo salido un FW en el mismo día. Conozco gente que sigue aún en 3.41 y con dongle así que imagínate jajajaja 