My guess about the WSOD
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
Re: My guess about the WSOD
On Friday, 23. July 2010 10:21:49 Helge Hafting wrote: 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 I had tested qi with 2+4+2 and got heaps of WSOD on new SHR-U (2.6.32): about only every 3rd boot worked (screen was white from beginning otherwise) about every 2nd display lock caused WSOD With same qi I did not get any WSOD on my other installations on the same Freerunner (Android on SD and SHR-U old (2.6.29) in NAND). I switched back to regular qi and do not see real WSODs anymore, meaning that sometimes when dimming the screen turns white but comes back immediately. With 2+4+2 it sometimes came back after suspend (too bad if you have an app running requesting CPU and thus not being able to suspend). Christian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
My guess about the WSOD
Hi, guys. I can attribute WS on boot and blank to changing version of compiler which builds kernel. Here, i have testing re: gcc_4.1.2gcc_4.4.6 2.6.34 kernel, configured for fb okWS on boot/unblank 2.6.32 shr kernel, configured for kms okWS on boot/unblank please, notice that something similar to unblank happens on rotation/mode change. but my kernels somehow lack of sound sound support (other kind of bug), all both shrs and .34, so they are unusable for daily usage (http://www.bsdmn.com/openmoko/glamo/242/shrkernel/) Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
