-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
| I suggest that we all take a "reality pill" and accept that the kernel | is still only as stable as a bowl of jello, that the folks doing A really unstable kernel looks MUCH uglier that what we have got. Userspace stays up and doesn't get brain damaged. The kernel itself is stable and almost all the drivers are in a fair state. That doesn't mean 'finished', but it does not mean 'bowl of jello' either. Somewhere in the dark during suspend and resume bad things can happen, it seems there are at least two sites for trouble in the GSM code you are familiar with and Glamo, and there are probably more sources of asynchronous events that cause bad outcomes. Currently even moving printks around can change outcomes in suspend / resume. So it is realistic to say suspend / resume is unstable at the moment. | Of course Openmoko can just unilaterally do what you state, and force | developers for every distro to invest huge amounts of effort in | developing fail-safe watchdog daemons for their distros. But that would | be effort that the community would rather see invested in making the | device behave like a proper phone. Am I the only one who thinks it's | rather amazing that after two years, we still don't have reliable basic | phone functionality?! And you present a proposal to make those | developers take time away in order to write daemons to replace a small | chunk of existing and functional kernel code? This makes no sense at | all to me. It seems we agree on that anyway. For the reliability, the issues are tough but localized, and by far the worst poison is in suspend - resume area. I know you looked at it yourself and have been fooled by the sensitivity of it to small timing changes in the code, it's a tough problem. | Yes, I'm frustrated. And I know that many others in the community are | too. Listen up, Openmoko! We need some progress: suspend/resume with | that ***** glamo (WSOD); the GSM is still broken (check out #1024 and | others); batteries still go flat because nobody has coded the batt-low | stuff; the wifi cannot be powered off; and many other kernel issues that | should be worked instead! Banging the table doesn't help. There are two kinds of issue, ones where we are basically clueless (source of Glamo trouble at the moment) and ones that just need the work doing (low battery, probably wifi modularization -- the power stuff for it is actually done already just the stack won't play ball). ~From my POV, the whole kernel state was inherited, including Glamo driver, suspend / resume issues, many other problems that we have discovered and squished over the last 9 months to get the thing shipping at all. To consolidate your other thread: Glamo is at the forefront of making trouble in the new andy-2.6.26 suspend / resume stuff and I didn't figure out why. It all seems bound up with the false reset and WSOD issues... I'll expose my tree after trying to clean the distributon of code between the patches a bit in the next day or two and you can try it yourself. In terms of timing you mention, I also work on various other stuff that is not public yet and some of it has been higher priority even than this stuff. Part of it has been to set things up so that we will be in a better position for future kernel work going on, I will talk about that further when it's underway. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjglMgACgkQOjLpvpq7dMqAZwCfSCNIaEuRIS1Pbg2Tf9dTiba2 3FsAnRvRJzmm72PnQ1DojQT6gfyesWnc =DlUi -----END PGP SIGNATURE-----
