new kernel ... / meaning of stable-tracking

[Andy Green]

-----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-----