On 21. juli 2010 10:25, Petr Vanek wrote: >> With the 2+4+2 qi, WSOD seems to happen more often. And curiously >> enough, removing power (as in pulling the battery out), doesn't help. >> It is then guaranteed to reboot into WSOD. Strange that the phone is >> capable of keeping this state over poweroff - do qi and uboot write >> state into flash? >> >> The solution is to boot into NOR flash, and then select "Poweroff" >>from the menu. After that, I get a normal reboot without the WSOD. >> Graphics indeed seems a bit faster with this qi. :-) I hope the WSOD >> problems can be fixed in the kernel and/or the xserver. It happens >> without this qi too - perhaps not as often. > > i can confirm exactly the same findings. as JaMa stated, perhaps this > will help to find the cause of WS altogether...
A WSOD was always a possibility. But in older images, it was rare. I saw it occationally with duke nukem - Duke changes resolution and orientation of the screen. The 2.6.32 kernel brought nice speedups. But WSODs happens now and then. The qi that changes glamo timing from 4+4+4 to 2+4+2 brings even more speed, and much more WSOD trouble too. At least when combined with 2.6.32, I haven't tried it with 2.6.29 or older kernels. It seems to me that the WSOD happen only when the display is turned on, or the resolution and/or orientation is changed. So I guess the programming of resolution and/or orientation is timing-sensitive. Existing code worked reasonably well with old kernels and 4+4+4 timing. But speedups break it. Maybe someone with a compiler could try adding delays between hardware operations in the modesetting code? (Preferably both the kernel modesetting, and any screen-on operation the bootloader might do. And if there is any modesetting left in Xorg these days.) Extra delays (or longer delays) should compensate for unknown timing sensitivities in the hardware. Maybe evn 1+4+2 timing can be used eventually. The video mode change is a rare operation - it won't matter much if it gets slower. Not if graphics painting operations gets faster. :-) Helge Hafting _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community